From owner-ietf-sasl Wed Oct 1 06:25:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPUKP084014 for ; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91DPUnA084011 for ietf-sasl-bks; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPTKP084005 for ; Wed, 1 Oct 2003 06:25:29 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1A4gyt-0006QG-76 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:27 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1A4gys-00013a-0j for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:26 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4gyr-0004C6-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:25:25 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 1 Oct 2003 15:25:25 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). > > I'm thinking "blob" is not a good word choice here. (...) > I'm thinking "blob" should be replaced with "string". But which string is the draft talking about? -- Hallvard From owner-ietf-sasl Wed Oct 1 06:49:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnjKP085367 for ; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Dnj3Q085366 for ietf-sasl-bks; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnhKP085361 for ; Wed, 1 Oct 2003 06:49:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A4hML-0001VS-TL for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A4hMK-00010R-B0 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4hMK-0004Gr-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:49:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: empty authzid in draft-ietf-sasl-plain-02.txt Date: Wed, 1 Oct 2003 15:49:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: draft-ietf-sasl-plain-02.txt says that The client leaves the authorization identity empty if it wishes the server to derive the authorization identity from the provided authentication identity. and Note that the parameters provided to the Authorize function are not prepared. so I think the pseudo-code for empty authzid should say authzid = DeriveAuthzid(authcid); and not authzid = DeriveAuthzid(pAuthcid); -- Hallvard From owner-ietf-sasl Wed Oct 1 08:44:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Fi0KP089583 for ; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Fi01P089582 for ietf-sasl-bks; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h91FhxKP089577 for ; Wed, 1 Oct 2003 08:43:59 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa23323; 1 Oct 2003 11:43 EDT Date: Wed, 01 Oct 2003 11:43:34 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 01, 2003 10:17:55 -0700 "Kurt D. Zeilenga" wrote: >> Network Working Group A. Melnikov >> Internet Draft Editor >> Document: draft-ietf-sasl-rfc2222bis-02.txt August 2003 >> Expires in six months Well, it doesn't matter now, but "expires in six months" is not acceptable; a specific date must be specified. See the "Formatting" section in 1id-guidelines.txt >> 1. Abstract Don't number the abstract. >> 4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. > > IANA should be spelled out here. > >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". Ick. IMHO this phrasing is ugly and not necessary. It appears to encourage authors of documents like SASL-GSSAPI to allocate themselves parts of the namespace without bothering to direct the IANA to reserve them. This would be a bad thing, and would indeed require that a potential future protocol designer (and/or the IANA itself) search the complete space of standards-track documents to see if the name they want to use has been reserved. IETF standards-track documents do not need the SASL spec's permission to direct the IANA to reserve parts of the namespace; thus, I don't think it's necessary to mention it at all. However, if it is mentioned, it should be in the IANA considerations section, not here, and with text like "IETF standards track documents may direct the IANA to reserve a portion of the SASL mechansim namespace and may specify different registration criteria for the reserved portion." Given the large size of the mechanism namespace, it is unfortunate that we have failed to provide for mechanism names of the form foo@domain. Delegated registration is much less work for IANA. >> Per IETF character set >> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >> these and other strings in UTF-8 [UTF-8]. > > This seems counter to [CHARSET-POLICY] as it allows a mechanism to > not support UTF-8 transfer of character data. > > [CHARSET-POLICY] says: > Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". > > Personally, I refer to this as "proxy authorization". Proxy > authentication makes it sound like the feature can be used by a > proxy to authenticate its users. The same argument can be made for "proxy authorization". We are talking about "authentication by proxy", not "authentication to a proxy". And yes, we're really talking about authorization, not authentication, but it's not really "authorization by proxy"; it's just authorization. The terminology is pretty bad. It's not clear to me that we need a name for this at all. But I'm pretty sure the phrase "proxy authentication" has been in use for a while, and to change it might cause more confusion than leaving it alone. >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. Sure, but that's not really all it's good for. It also allows jhutz@CS.CMU.EDU to log in to the IMAP server on CYRUS.ANDREW.CMU.EDU as 'jhutz', even though the server is in the ANDREW.CMU.EDU realm. And similar functionality, though not using SASL, allows me to type "jhutz@CS.CMU.EDU,maint:" at a login prompt, followed by jhutz@CS.CMU.EDU's password, and log in as the user 'maint'. >> The server SHOULD verify the correctness of a received authorization >> identity. > > "Correctness" here doesn't appear to be correct. And it should > be a MUST. I suggest: > The server SHALL fail the authentication exchange if the > authenticated client is not allowed to assume the asserted > authorization identity. s/SHALL/MUST/ >> 4.4. Character string issues >> >> Per IETF character set policy [CHARSET-POLICY], authentication >> mechanisms SHOULD encode character strings in UTF-8 [UTF-8]. > > See above note about charset-policy. And my response. It's really quite important that we get this right for authentication identities, or we risk invalidating a number of popular mechanisms because they are based on underlying authentication technology which does not use UTF-8. >> 5. Protocol profile requirements >> >> In order to use this specification, a protocol definition MUST supply >> the following information: >> >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] This >> service name is made available to the authentication mechanism. >> >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" A definition Paragraph break. >> A definition of the method by which the authentication protocol >> exchange is carried out, including how the challenges and responses >> are encoded, how the server indicates completion or failure of the >> exchange, how the client aborts an exchange, and how the exchange >> method interacts with any line length limits in the protocol. >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. This allows the >> server to avoid a round trip when using a mechanism which is defined >> to have the server send additional data along with the indication of >> successful completion. See section 6.2 of this document for further >> information. What command? Who says "the method by which the authentication protocol exchange is carried out" is a command? s/The command/The exchange method/ >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. > > I think it unwise to enter into a discussion of realms here. > Realm syntax and semantics are, for mechanisms which have realms, > mechanism specific. The mechanism specification should state how > they are to be compared. The mechanism specification should state > how they are to constructed and used in the mechanism and, where > appropriate, state any protocol profiling requirements. (Note: > I'd likely doubt any mechanism attempt to state protocol profiling > requirements as this breaks SASL's separation of profile and > mechanism). I agree. A realm is just part of the authentication identities used by certain mechanisms. It is mechanism-specific, and a discussion of realms is irrelevant to protocol profiling. >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. Absolutely not. Protocols may decide to include some concept of realm in their authorization identities, but they have no business whatsoever defining the semantics of authentication identities. That is the responsiblity of the mechanism. >> Below the term "realm" has the meaning as defined in the section 5. >> A security layer that remains in effect when a client, which already >> has authenticated and established the security layer with "Realm A", >> authenticates to "Realm B", without negotiating a new security layer, >> enables "Realm B" to make guesses about previously observed >> ciphertext using the server's SASL engine as an oracle. "Realm B" may >> observe how known cleartext is encrypted. >> >> +---------+ +---------+ >> | | | | >> | Realm B | | Realm A | >> | | | | >> +---------+ +---------+ >> | ^ | >> | : +-----------+ | >> Traffic from | : | Encryption| | Traffic from A >> B to client +-------->| end point |<-------+ to client >> : | (SSL/SASL)| >> : +-----------+ >> : | >> : | >> : +---+ >> : | | >> : | | >> : | | Encryption tunnel, e.g. SASL or SSL, >> : | | between the server > >> encrypted | | Separate tunnels to different >> traffic between | | clients. >> Realm A and client +---+ >> | >> | >> +-----------> Traffic to clients This discussion is confusing and makes no sense to me. SASL doesn't protect traffic between "realms" and clients; it protects traffic between _servers_ and clients. This needs to be reworded so it makes sense, in terms of entities known to the SASL framework. A "realm" is not such an entity; it is no more than part of the autentication identities used by some mechanisms, and has no place outside the mechainsm specification. Put another way, and ignoring the issue of "realms"; the above description makes so little sense to me that I cannot evaluate its validity or understand what attack we are trying to avoid. >> 8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. Provide the template. Do not specify how to communicate the registration to the IANA, because that may change over time and is out of scope for this document. >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. Again, too bad we didn't allow for foo@domain.com. >> 8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism > > Replace quotes with < and >, and insert a period at the end of the > sentence. > >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). > > Drop "by sending (...)". IMHO, drop the whole subsection. IANA considerations are about telling the IANA what it needs to do and be aware of with respect to this document. It's appropriate to specify the form of registration and the rules which govern whether IANA should accept a registration. It is not appropriate to specify the means used to communicate with the IANA or the RFC Editor, or to direct the IANA as to the URL at which it must provide the registration data. These things may change over time, and it is out of scope for the SASL working group (or, indeed, the IETF) to specify them. >> 8.3. Change control >> >> Once a SASL mechanism registration has been published by IANA, the >> author may request a change to its definition. The change request >> follows the same procedure as the registration request. This sounds a lot like the stringprep loophole, and it makes me nervous. >> 9.2. Informative References >> >> <> [SASL-GSSAPI] Myers, "SASL GSSAPI >> mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt, >> September 2000 >> [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest >> Authentication as a SASL Mechanism", work in progress, draft-ietf- >> sasl-rfc2831bis-XX.txt, replaces RFC 2831 I think it would be good to eliminate references to new or updated mechanisms if at all possible, since otherwise we are forced to either publish a document with incorrect or incomplete references, or wait until those documents are ready. If we keep them, use the correct reference form: [SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms" (draft-ietf-cat-sasl-gssapi-01.txt) See "References" in section 2 of ID-nits. >> [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) >> MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. Ew. I don't think this is necessary. Also, references to URL's are to be avoided, as they may change, rendering the document obsolete and confusing. See "References" in section 2 of id-nits. >> "stringprep" and Unicode security considerations apply to >> authentication identities, authorization identities and passwords. Include references to these. Put Security Considerations _before_ references, not after. >> 12. Acknowledgments >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). Except we should be dropping the definition of "realm". >> In certain situations, it is reasonable to use SASL underneath one of >> these Transport Security services. The transport service would >> secure the connection, either service would authenticate the client, >> and SASL would negotiate the authorization identity. The SASL >> negotiation would be what moves the protocol from "unauthenticated" >> to "authenticated" state. The "EXTERNAL" SASL mechanism is >> explicitly intended to handle the case where the transport service >> secures the connection and authenticates the client and SASL >> negotiates the authorization identity. >> >> When using SASL underneath a sufficiently strong Transport Security >> service, a SASL security layer would most likely be redundant. The >> client and server would thus probably want to negotiate off the use >> of a SASL security layer. Please don't say this without a _lot_ more text explaining when it is safe. A common configuration is to run SASL under TLS, using SASL for client authentication and negotation of the authorization identity. In this configuration, it is _not_ safe to skip using a SASL security layer if the client did not check the server's certificate (there is a tunnelling MitM attack), and it's not a particularly good idea even if the server cert was checked, because the client's authentication is still not bound to the encryption keys used at the TLS layer. We already have problems with people who think it is actively bad to use a SASL security layer under TLS. The result is that some insecure configurations are now widely deployed. Let's not encourage this any further. >> Appendix B. IANA considerations Uh, no. IANA considerations were section 8. Please merge them. >> The IANA is directed to modify the SASL mechanisms registry as >> follows: > > Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: It's not demanting; it's perfectly reasonable usage. The IANA works for the IETF; it is appropriate for the IETF, in the form of a standards-track document, to direct it to make changes to a registry. It is also common usage. Put the TOC at the _top_ of the document, just after the abstract. See the "Tabel of Contents" section at http://www.rfc-editor.org/policy.html -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Oct 1 11:20:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKNKP095438 for ; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IKNSw095437 for ietf-sasl-bks; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKMKP095432 for ; Wed, 1 Oct 2003 11:20:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 740CF151D9B; Wed, 1 Oct 2003 14:20:02 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> From: Sam Hartman Date: Wed, 01 Oct 2003 14:20:02 -0400 In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 01 Oct 2003 10:17:55 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an >> authentication protocol exchange. This consists of a series of >> server challenges and client responses, the contents of which >> are specific to and defined by the mechanism. Kurt> Can't the client challenge the server as well? I always thought that in SASL, the challenge was defined to be the message from the server to the client even if it didn't serve that purpose in a security sense. --Sam From owner-ietf-sasl Wed Oct 1 11:46:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkIKP096361 for ; Wed, 1 Oct 2003 11:46:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IkHGh096360 for ietf-sasl-bks; Wed, 1 Oct 2003 11:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkGKP096354 for ; Wed, 1 Oct 2003 11:46:16 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h91IkF5t031925; Wed, 1 Oct 2003 14:46:15 -0400 Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: Message-ID: References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> 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: On Wed, 1 Oct 2003, Sam Hartman wrote: > Kurt> Can't the client challenge the server as well? > > I always thought that in SASL, the challenge was defined to be the > message from the server to the client even if it didn't serve that > purpose in a security sense. I agree. Indeed, in 6.1 we refer to an "initial client response" even though it could, in fact, be an initial challenge from client to server. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Oct 2 18:41:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fwKP025631 for ; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h931fwa0025630 for ietf-sasl-bks; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fvKP025624 for ; Thu, 2 Oct 2003 18:41:57 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h931fxlg022341 for ; Fri, 3 Oct 2003 01:41:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 03 Oct 2003 06:41:43 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: References: 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: Simon raised this issue to me privately... but I think it needs broader discussion (given that it is a technical issue). At 02:19 PM 10/2/2003, Simon Josefsson wrote: >* The document doesn't mandate any specific action when the client > send an invalid string (e.g., one that is rejected by string > processing). That is, what should the implementation do if the message it receives is malformed? I note that this issue is likely not unique to ANONYMOUS. So, maybe it should be dealt with in base SASL specification. I'm thinking a malformed message should be treated as a protocol error in the application protocol. Comments? Kurt From owner-ietf-sasl Fri Oct 3 00:39:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dpKP091053 for ; Fri, 3 Oct 2003 00:39:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h937dpbV091052 for ietf-sasl-bks; Fri, 3 Oct 2003 00:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dmKP091031 for ; Fri, 3 Oct 2003 00:39:48 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h937dlJV076012; Fri, 3 Oct 2003 01:39:47 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 03 Oct 2003 01:39:46 -0600 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Message-ID: <2147483647.1065145186@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > At 02:19 PM 10/2/2003, Simon Josefsson wrote: >> * The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing) [...] > That is, what should the implementation do if the message it receives > is malformed? In the absence of a very compelling reason to do otherwise, the application should immediately fail the transaction. "Be liberal in what you accept" has no place here. However, I'm more concerned about protocol parser state machines getting out of sync (see the recent spate of -- again -- ASN.1 parser bugs) than applications misinterpreting bogus realm strings. > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. [...] > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. [Son-of-]2222 is a framework document, so I'm not sure if we can mandate that sort of behaviour in it. But that cannot stop us from suggesting some extremely rude behaviour towards authors of deviant software in the Security Considerations section. --lyndon From owner-ietf-sasl Fri Oct 3 08:54:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FsFKP027698 for ; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FsFn3027697 for ietf-sasl-bks; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Fs8KP027684 for ; Fri, 3 Oct 2003 08:54:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 3 Oct 2003 16:53:55 +0100 Message-ID: <3F7D9B91.7060906@isode.com> Date: Fri, 03 Oct 2003 16:53:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've started with the easy (editorial) stuff and I will reply to other comments after the weekend. Kurt D. Zeilenga wrote: >Attached are my raw review notes... mostly editorial, >clarifications, and such. I do raise (as Hallvard did) >some concerns with the realm text. I'll try to pull >that issue (and maybe a couple of other issues) out as >separate threads. > >Kurt > > >> >>1. Abstract >> >> SASL provides a method for adding authentication support with an >> optional security layer to connection-based protocols. >> >> > >SASL needs to be spelled out here (first use in Abstract). > Done. >> It also >> describes a structure for authentication mechanisms. The result is >> an abstraction layer between protocols and authentication mechanisms >> such that any SASL-compatible authentication mechanism can be used >> with any SASL-compatible protocol. >> >> This document describes how a SASL authentication mechanism is >> structured, how a protocol adds support for SASL, defines the >> protocol for carrying a security layer over a connection, and defines >> the EXTERNAL SASL authentication mechanism. >> >>... >> >>2.2. Conventions used in this document >> >> In examples, "C:" and "S:" indicate lines sent by the client and >> server respectively. >> >> The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" >> in this document are to be interpreted as defined in "Key words for >> use in RFCs to Indicate Requirement Levels" [KEYWORDS]. >> > >Add U+ convent description (see SASLprep). > > > Done. >>... >> >>4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. >> >> > >IANA should be spelled out here. > Ok. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". >> >> The "sasl-mech" rule below defines the syntax of a SASL mechanism >> name. This uses the augmented Backus-Naur Form (BNF) notation as >> > >s/augmented Backus-Naur Form (BNF)/Augmented Backus-Naur Form (ABNF)/ > Done. >> specified in [ABNF] and the ABNF core rules as specified in Appendix >> A of the ABNF specification [ABNF]. >> >> >> sasl-mech = 1*20mech-char >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase letters, >> ; digits, "-" and "_" >> >> >> >> >> >> >>A. Melnikov FORMFEED[Page 3] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. >> >> > >Can't the client challenge the server as well? > Rob has already answered this question. > ... > >> After receiving a challenge, a client mechanism may issue a response >> or abort the exchange. The protocol's profile specifies how each of >> these is then represented over the connection. >> >> > >Indicate here that mechanisms may also involve challenges to >the server by the client. > > See Rob's reply. >>... >> >> An authorization identity is a string of zero or more ISO 10646 >> [ISO-10646] coded characters. The NUL (U+0000) character is not >> permitted in authorization identities. The meaning of an >> authorization identity of the empty string (zero length) is defined >> below in this section. The authorization identity is used by the >> server as the primary identity for making access policy decisions. >> >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> >> > >I'm thinking "blob" is not a good word choice here. > > Blob \Blob\ (bl[o^]b), n. [See {Bleb}.] > 1. Something blunt and round; a small drop or lump of > something viscid or thick; a drop; a bubble; a blister. > --Wright. > > 2. (Zo["o]l.) A small fresh-water fish ({Uranidea > Richardsoni}); the miller's thumb. > >>From WordNet (r) 2.0 [wn]: > > blob > n : an indistinct shapeless form > v : make a spot or mark onto; "The wine spotted the tablecloth" > [syn: {spot}, {fleck}, {blot}] > [also: {blobbing}, {blobbed}] > > >You could have meant BLOB (Binary Large OBject), but this seems not to >fit as well. > >I'm thinking "blob" should be replaced with "string". > I would rather use "data". >> While some legacy >> mechanisms are incapable of transmitting an authorization identity >> other than the empty string, >> >> > >I know of mechanisms which do not transmit an authorization identity... >but are there ones which only allow transfers of empty authorization >identity strings? > No, I am not aware of any such mechanism >> newly defined mechanisms are expected to >> be capable of carrying the entire Unicode repertoire (with the >> exception of the NUL character). An authorization identity of the >> empty string and and an absent authorization identity MUST be treated >> >> > >s/and and/and/ > Yes, already fixed in my diff ;-). >> as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an >> >> >> >>A. Melnikov FORMFEED[Page 4] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> authorization identity is allowed to be absent, but one is >> transferred, it SHOULD NOT be an empty string). >> >> > >Suggest this be reworded: > However, mechanisms SHOULD NOT allow both. That is, a mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. > > Done (I didn't like the original either, but couldn't think of anything better). >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. >> >> The server makes an implementation defined policy decision as to >> whether the authentication identity is permitted to have the access >> privileges of the authorization identity and whether the >> authorization identity is permitted to receive service. If it is >> not, the server indicates failure of the authentication protocol >> exchange. >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >> > >I suggest rewording this: > As a client might not have the same information as the > server, clients SHOULD NOT derive authorization identities > from authentication identities. Instead, clients SHOULD > provide no (or empty) authorization identity when the user > has not provided an authorization identity. > Ok. >>... >> >> In this example, the client is proxy >> authenticating, sending the authorization id "fred". The server has >> determined the client's identity through IPsec and has a security >> policy that permits that identity to proxy authenticate as any other >> identity. >> >> To the protocol profile, the four octet sequence "fred" is an opaque >> binary blob. The SASL protocol profile for SMTP specifies that >> server challenges and client responses are encoded in BASE64; the >> BASE64 encoding of "fred" is "ZnJlZA==". >> >> > >s/binary blob/string/ > I've changed this to "data" instead, as above. >>... >> >> S: 220 smtp.example.com ESMTP server ready >> C: EHLO jgm.example.com >> S: 250-smtp.example.com >> S: 250 AUTH DIGEST-MD5 EXTERNAL >> C: AUTH EXTERNAL ZnJlZA== >> S: 235 Authentication successful. >> >>8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. >> >> >> >> >>A. Melnikov FORMFEED[Page 11] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. >> >> While the registration procedures do not require it, authors of SASL >> mechanisms are encouraged to seek community review and comment >> whenever that is feasible. Authors may seek community review by >> posting a specification of their proposed mechanism as an internet- >> draft. SASL mechanisms intended for widespread use should be >> standardized through the normal IETF process, when appropriate. >> >>8.1. Comments on SASL mechanism registrations >> >> Comments on registered SASL mechanisms should first be sent to the >> "owner" of the mechanism. Submitters of comments may, after a >> reasonable attempt to contact the owner, request IANA to attach their >> comment to the SASL mechanism registration itself. If IANA approves >> of this the comment will be made accessible in conjunction with the >> SASL mechanism registration itself. >> >>8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism >> >> > >Replace quotes with < and >, and insert a period at the end of the >sentence. > > Already done. >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). >> >> > >Drop "by sending (...)". > Done. >>... >> >>9. References >> >>9.1. Normative References >> >> [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: >> ABNF", RFC 2234, November 1997 >> >> [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and >> Languages", RFC 2277, January 1998 >> >> [GSSAPI] Linn, "Generic Security Service Application Program >> Interface, Version 2, Update 1", RFC 2743, January 2000 >> >> [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - >> Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. >> >> > >For consistency (all other references use tags not associated with >their document numbers), I suggest replacing the tag [ISO-10646] >with [UCS]. > > I frankly doubt that this make it any better. >> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate >> Requirement Levels", RFC 2119, March 1997 >> >> [Stringprep] P. Hoffman, M. Blanchet, "Preparation of >> Internationalized Strings ("stringprep")", RFC 3454, December 2002. >> >> [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names >> and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. >> >> [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work >> in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, >> Janyary 1998 >> >>... >> >>12. Acknowledgments >> >> This document is a revision of RFC 2222 written by John G. Myers >> . He also wrote the major part of this >> document. >> >> > >Drop John's e-mail address here. I suggest replacing the second >sentence with: > He also contributed significantly to this revision. > Ok. >> Thank you to Magnus Nystrom for the ASCII picture used in section >> 6.3. >> > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Ok. >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). >> >> Contributions of many members of the SASL mailing list are gratefully >> acknowledged. >> >> > >s/mailing list/working group/ > A lot of contribution was done before we had a working group. (Not that it worth arguing about anyway.) >>... >> >>Appendix B. IANA considerations >> >> The IANA is directed to modify the SASL mechanisms registry as >> follows: >> >> > >Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: > > Ok. Alexey From owner-ietf-sasl Fri Oct 3 11:00:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0FKP035504 for ; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93I0FPK035503 for ietf-sasl-bks; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0EKP035498 for ; Fri, 3 Oct 2003 11:00:14 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BA80C151D9B; Fri, 3 Oct 2003 13:59:57 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> From: Sam Hartman Date: Fri, 03 Oct 2003 13:59:57 -0400 In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 03 Oct 2003 06:41:43 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> I'm thinking a malformed message should be treated as a Kurt> protocol error in the application protocol. Kurt> Comments? This seems reasonable during the authentication phase, but I think we may need to say something more specific about security layers. From owner-ietf-sasl Mon Oct 6 16:16:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGTKP077980 for ; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NGTaG077979 for ietf-sasl-bks; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGSKP077974 for ; Mon, 6 Oct 2003 16:16:28 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NGT5t009824 for ; Mon, 6 Oct 2003 19:16:29 -0400 Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: SASL Initial Response? (fwd) 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: Here are some of Mark's comments on RFC2222bis: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- ---------- Forwarded message ---------- Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski Cc: RL 'Bob' Morgan , IMAP Extensions WG Subject: Re: SASL Initial Response? On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree. I also suspect an example or two could help the appropriate > sections of 2222bis. But further discussion of this should probably move > to the ietf-sasl list. I'm not on the ietf-sasl list, so would appreciate this being passed on. I guess that I should be at the SASL session in Minneapolis (assuming I go there which seems likely). Examples are always helpful. Section 6.1 of 2222bis should give examples of AUTH PLAIN in SMTP both with and without initial client data. Similar examples should appear in the specification for the PLAIN mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!) *and* in the specifications for POP3 SASL and SMTP SASL. > Obviously. But currently it seems that the primary reason that we don't > have an initial SASL response in IMAP is concerns over clarity of the > SASL specification. Actually, the primary reason was compatibility with the past; IMAP SASL is older than SASL. I'm willing to go along with it as a server-optional extension *IF* the problems with the current client-optional server-mandatory initial client data POP3/SMTP SASL are fixed. Since implementation of initial client data will be server-optional in IMAP, it will be more complex than in POP3/SMTP. This is because it's mandatory to implement in POP3/SMTP servers. > If fixing *that* specification still isn't good enough, I'm totally > willing to supply text in the draft for the IMAP extention to the effect > of "pay careful attention to the fact that initial responses are > *optional*," even to the point of making it a Security Consideration. We will need that text, and much more. > And indeed, any IMAP server that didn't get this right would immediately > have a large number of old-style clients fail to work against it anyway, > since it is an extention and not part of the base protocol. It's not just IMAP servers we have to worry about. It's also IMAP clients. We already have clients which fail to interoperate with a server that does not have a particular extension and/or declare such servers to be "broken." The offenders know who they are. We have to concern ourselves about the possibility of clients that think that initial data is mandatory to implement in the server (since it is mandatory in POP3 and SMTP). Thus, the situation is *worse* with IMAP than with POP3 or SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Mon Oct 6 16:15:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFhKP077954 for ; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NFh8e077953 for ietf-sasl-bks; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFfKP077944 for ; Mon, 6 Oct 2003 16:15:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NFe5t009820; Mon, 6 Oct 2003 19:15:40 -0400 Date: Mon, 6 Oct 2003 19:15:41 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> 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: I am moving this discussion to the ietf-sasl list, since it seems to have wandered somewhat from a discussion of IMAP's specific case. Background for members of the IETF SASL list: This was part of a discussion in the IMAPEXT working group about the creation of an initial client response extention for IMAP. Currently, the argument against creating such an extention is that "implementors get client-initial-send wrong" (Specifically, servers get it wrong when clients choose to not perform the optional initial send). Mark, as this is your argument, please correct me if I have summarized it incorrectly. On Mon, 6 Oct 2003, Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > > > The most common offense is to implement PLAIN and LOGIN as the same thing, > > > thus giving LOGIN challenges to PLAIN with no initial response. > > That's inexcusable, since they are clearly NOT the same thing, and PLAIN > > has always had a standardized SPEC. Obviously we can't make people read > > the specs correctly, all we can do is make them clear and unambiguous. > > Agreed completely. However, multiple commercial implementations have done > this blunder. > > > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > > Somtimes you also find extra CRLFs in the responses. > > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > > take a look. > > It's not ambiguous, but you have to read three separate documents (RFCs > 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in > SMTP. For POP3, you just need to read 2222 and 2595. > > There is no single document, and *NO* examples, that explains this. RFC > 2554 is a bit better in talking about empty challenges than 2595 (see > first paragraph of page 3, RFC 2554) but without the context of RFC 2222 > it makes no sense. Isn't it typical that a SASL implementor should need to look at 3 documents however? The one for their protocol, the one for the mechanism that interests them, and RFC2222 or its replacement. My personal reading of 2554 is that it could use a lot of rework anyway, and I'm toying with writing an update to it right now. Such an update would include examples. > > > Over and over again, I get told "just make Pine send the initial > > > challenge"; in other words, that the initial challenge is mandatory. But > > > the SASL specification does not say that; and the idea of inflicting the > > > non-interoperable brokenness of POP/SMTP on IMAP repels me. > > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead > > of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become > > problematic because the initial response truely is optional. > > Actually, I would like the SHOULD to become a MAY, and it be emphasized > that servers MUST implement the correct empty challenge behavior. > > However, a MUST is preferable to the status quo, which is a de jure SHOULD > but (at least according to certain individuals) a de facto MUST. I don't see a strong technical reason for reducing the requirement for SHOULD to MAY (reducing the round trips used should be encouraged). I do see a strong argument for making it abundantly clear that servers MUST implement the correct omitted-challenge behavior (to be distinguished from an empty challenge -- "" is not the same as NIL) > > I will do this. Just to be clear, we are only talking about > > client-first mechanisms in which the client chooses to not send an > > initial response, correct? > > Correct. SMTP is the worst case, since you have to read three RFCs to > work out how to implement PLAIN in SMTP. > > Note that there are no examples. The examples situation should be fixed. I don't think that we can expect SASL implementors to (in the general case) have to read only two RFCs, especially as we are breaking all of the mechanisms into their own documents. I will be forwarding your other message along to the SASL list momentarily. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Oct 6 16:49:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnEKP079404 for ; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NnEaN079403 for ietf-sasl-bks; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnDKP079396 for ; Mon, 6 Oct 2003 16:49:13 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDC2028637; Mon, 6 Oct 2003 16:49:13 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDSS006277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 16:49:13 -0700 Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing 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: On Mon, 6 Oct 2003, Rob Siemborski wrote: > Currently, the argument against > creating such an extention is that "implementors get client-initial-send > wrong" (Specifically, servers get it wrong when clients choose to not > perform the optional initial send). Mark, as this is your argument, > please correct me if I have summarized it incorrectly. Yes, that is an incorrect summary. The argument against creating such an extension is that the current specifications for SASL in POP3 and SMTP (which permit client-initial-send) are complex, and as a result many POP3/SMTP servers are not handling client-initial-send properly when the client does not provide an initial response. Consequently, I do not believe that IMAP should be extended to provide client-initial-send until after the specifications are clarified. This is especially the case because IMAP will be a *more* complex case than POP3/SMTP because client-initial-send is mandatory to implement in POP3/SMTP servers but must be optional (due to compatibility with the installed base) in IMAP servers. Thus, the interoperability matrix with IMAP is 4 possible configurations instead of 2 with POP3/SMTP. The one-line summary: Before making it more complex, fix the existing complexity > Isn't it typical that a SASL implementor should need to look at 3 > documents however? The one for their protocol, the one for the mechanism > that interests them, and RFC2222 or its replacement. Empirical data suggests that this requires considerably more care than currently exists among implementors. An understanding of the correct server behavior for "AUTH PLAIN" in SMTP requires reading three documents. > My personal reading of 2554 is that it could use a lot of rework anyway, > and I'm toying with writing an update to it right now. Such an update > would include examples. Excellent; I'll be glad to help you. > I don't see a strong technical reason for reducing the requirement for > SHOULD to MAY (reducing the round trips used should be encouraged). I do > see a strong argument for making it abundantly clear that servers MUST > implement the correct omitted-challenge behavior (to be distinguished from > an empty challenge -- "" is not the same as NIL) I see it as a matter of semantics. Too many people see a SHOULD as an excuse to overlook a MUST. > The examples situation should be fixed. I don't think that we can expect > SASL implementors to (in the general case) have to read only two RFCs, > especially as we are breaking all of the mechanisms into their own > documents. I fear that it is a lot to expect them to read *one* RFC, much less grasp concepts that only come through by reading three. We seem to be in a world where protocol engines are written by empirical tests and a cursory glance at the examples in RFCs. It is a helpful exercise to go through the steps to figure out what is the correct server response to "AUTH PLAIN" in SMTP. You have to start with 2554, then 2595, then 2222, then back to 2554, then back to 2595. You have to remember certain statements in each of these documents which make no apparent sense until you read certain equally-obscure statements in the other documents. And you have to put this all together. I went through this exercise with someone who I knew to be of above-average intelligence. It took some time before he grasped it. That told me that the documents have a problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Tue Oct 7 11:29:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IToKP039969 for ; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97ITo82039968 for ietf-sasl-bks; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97ITmKP039958 for ; Tue, 7 Oct 2003 11:29:49 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97ITjo5001254 for ; Tue, 7 Oct 2003 14:29:45 -0400 (EDT) Message-ID: <3F8306B8.3010207@oceana.com> Date: Tue, 07 Oct 2003 14:32:24 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00 Last Call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we did not receive any negative feedback (or positive, for that matter) and Mark, Rob Siemborski and I feel that the current doc accurately describes the existing deployed implementation, I intend ask the IETF to Last Call it shortly. If you have any comments on the existing doc, please send them soon. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 11:36:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaNKP040195 for ; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97IaNbC040194 for ietf-sasl-bks; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaLKP040189 for ; Tue, 7 Oct 2003 11:36:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97IaGo5001378; Tue, 7 Oct 2003 14:36:16 -0400 (EDT) Message-ID: <3F83083F.10600@oceana.com> Date: Tue, 07 Oct 2003 14:38:55 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steven F Siirila CC: SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> In-Reply-To: <20031007180404.GA16933@earth.tc.umn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steven F Siirila wrote: > In reading section 2.2: > > 2.2. Server side of authentication protocol exchange > > The server issues the string "User Name" in challenge, and receives a > client response. This response is recorded as the authorization > identity. The server then issues the string "Password" in challenge, > and receives a client response. This response is recorded as the > authorization authenticator. The server must verify that the > authorization authenticator permits login as the authorization > identity. > > Note: There is at least one widely deployed client which requires > that the challenge strings transmitted by the server be "Username:" > and "Password:" respectively. For this reason, server > implementations MAY send these challenge strings instead of those > listed above. > > Why is the string "User name" chosen as the suggested challenge to be sent > by the server instead of "Username:", considering that second paragraph? > Are there other clients out there that expect "User name" as a challenge > string? Note that the current Cyrus SASL (V2) returns "Username:" and > "Password:". The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). The wording in the draft is a compromise between the authors. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 14:50:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97LoFKP047316 for ; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97LoFOf047315 for ietf-sasl-bks; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Lo9KP047305 for ; Tue, 7 Oct 2003 14:50:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 7 Oct 2003 22:49:34 +0100 Message-ID: <3F8334ED.80504@isode.com> Date: Tue, 07 Oct 2003 22:49:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre , Jeremie Miller CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG wrote: >The IESG has received a request from the Extensible Messaging and Presence >Protocol WG to consider the following document: > >- 'XMPP Core ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-09. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt > I would like to raise several SASL related issues in XMPP document. (Sorry for crosspost and sorry for being late with reviewing this.) 1). > 7. The initiating entity MUST provide an authzid during SASL > negotiation. The authzid-value MUST be a valid JID of the form > (i.e., a domain identifier only) for servers and of the > form (i.e., node identifier, domain > identifier, and resource identifier) for clients. The initiating > entity MAY process the authzid-value in accordance with the rules > defined in Addressing Scheme (Section 3) before providing it to > the receiving entity, but is NOT REQUIRED to do so; however, the > receiving entity MUST verify that the authzid-value provided by > the initiating entity conforms to the rules defined therein. Not all SASL mechanisms are capable of transmitting authorization identity, so this requirement might be problematic. Also, the revision of RFC 2222 says that the client must not specify authorization-id unless it wants to impersonate some other entity: As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. So, the text should be reworded reflect that an authorization identity is optional and that if one is provided, it is in the form described above. 2). > This series of challenge/response pairs continues until one of three > things happens: > > 1. The initiating entity aborts the handshake by sending an > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > namespace to the receiving entity. Upon receiving the > element, the receiving entity MUST terminate the TCP connection. I think the requirement to drop TCP connection is unreasonable here. There are several valid reasons why the client may retry failed authentication: 1). User typed in a wrong password, the client should retry the same SASL mechanism a reasonable number of times. 2). The client invoked a SASL mechanism that reported that it can't be used because of misconfiguration (e.g. kerberos configuration file is missing). The client than sends to the server and tries another mechanism. 3). > 3. The receiving entity reports success of the handshake by sending > a element qualified by the > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > entity; this element MAY optionally contain character data (in > SASL terminology "additional data with success"). Upon receiving > the element, the initiating entity MUST initiate a new > stream by sending an opening XML stream header to the receiving > entity (it is not necessary to send a closing > element first, since the receiving entity and initiating entity > MUST consider the original stream to be closed upon sending or > receiving the element). Upon receiving the new stream > header from the initiating entity, the receiving entity MUST > respond by sending a new XML stream header to the initiating > entity, along with any remaining available features (but NOT > including the STARTTLS feature or any authentication mechanisms) > or an empty features element (to signify that no additional > features are available); note that any such additional features > are not defined herein, and MUST be defined by the relevant > extension to XMPP. Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a successful SASL authentication. Some of them require that the client compares the list of the advertised mechanism with the one before the authentication. This is done to prevent man-in-the-middle attacks when an attacker removes strong SASL mechanisms from the list of supported mechanisms. (Whether this check is useful in practice is another matter. I am not sure whether anybody implements it). 4). There was a recent discussion on the bugtraq mailing list about handling invalid base64 data. It turned out that different implementations handle this differently, for example: 1). Ignore invalid characters 2). Treat an invalid character as the end of the base64 encoded data (and ignore the rest) 3). Truncate base64 encoded data before the invalid character. In particular there was a discussion regarding the padding character ('=') in the middle of a base64 data. I suggest that some text about this be added to the Security considerations sections. For example: Both the client and the server should verify the received base64 data and reject (and not ignore) any characters not explicitly allowed by the base64 alphabet [BASE64] and should reject any sequence of base64 characters that contains the pad ('=') character not as the last character of the (e.g. "=AAA" or "BBBB=CCC"). [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. (You might decide to relax this for XMPP and to allow spaces and/or CRLFs anywhere in the data.) 5). >6.3 SASL Errors > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. Do you mean invalid base64 encoding here or something else? 6). >6.3 SASL Errors > > The following SASL-related error conditions are defined: > > o -- The receiving entity acknowledges an > element sent by the initiating entity; sent in response to the > element. > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. or with initial challenge data. Example: SASL PLAIN mechanism. > o -- The mechanism chosen by the initiating > entity may be used only if the stream is already encrypted; sent > in response to the element. > > o -- The authzid provided by the initiating > entity is invalid, either because it is incorrectly formatted or > because the initiating entity does not have permissions to > authorize that ID; sent in response to a element. or with initial challenge data. > o -- The initiating entity did not provide a > mechanism or requested a mechanism that is not supported by the > receiving entity; sent in response to the element. > > o -- The realm provided by the initiating entity > (in mechanisms that support the concept of a realm) does not match > one of the hostnames served by the receiving entity; sent in > response to a element. or with initial challenge data. > o -- The mechanism requested by the initiating > entity is weaker than server policy permits for that initiating > entity; sent in response to the element. or with initial challenge data. > o -- The authentication failed because the > initiating entity did not provide valid credentials (this includes > the case of an unknown username); sent in response to a element. or with initial challenge data. 7). >12.4 Order of Layers > > The order of layers in which protocols MUST be stacked is as follows: > > 1. TCP > > 2. TLS > > 3. SASL > > 4. XMPP > > The rationale for this order is that TCP is the base connection layer > used by all of the protocols stacked on top of TCP, TLS is often > provided at the operating system layer, SASL is often provided at the > application layer, and XMPP is the application itself. This should be referenced in "6.4 SASL Definition" section, because it is related to the XMPP profile of SASL. Cheers, Alexey From owner-ietf-sasl Tue Oct 7 15:04:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4RKP047888 for ; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97M4R4U047887 for ietf-sasl-bks; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4QKP047881 for ; Tue, 7 Oct 2003 15:04:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h97M4Mlg071146; Tue, 7 Oct 2003 22:04:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 03:04:05 -0700 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: draft-murchison-sasl-login-00 Last Call Cc: Steven F Siirila , SASL mailing list , Mark Crispin In-Reply-To: <3F83083F.10600@oceana.com> References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> 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: Ken, This use of MAY is a bit problematic. MAY items are suppose to be truly optional (see RFC 2119). As servers using the alternative protocol tokens won't interoperate with client not expecting those alternatives, this item isn't. Likely this can be addressed by (more explicitly) limiting the applicability of the option. Kurt At 11:38 AM 10/7/2003, Ken Murchison wrote: >Steven F Siirila wrote: > >>In reading section 2.2: >>2.2. Server side of authentication protocol exchange >> The server issues the string "User Name" in challenge, and receives a >> client response. This response is recorded as the authorization >> identity. The server then issues the string "Password" in challenge, >> and receives a client response. This response is recorded as the >> authorization authenticator. The server must verify that the >> authorization authenticator permits login as the authorization >> identity. >> Note: There is at least one widely deployed client which requires >> that the challenge strings transmitted by the server be "Username:" >> and "Password:" respectively. For this reason, server >> implementations MAY send these challenge strings instead of those >> listed above. >>Why is the string "User name" chosen as the suggested challenge to be sent >>by the server instead of "Username:", considering that second paragraph? >>Are there other clients out there that expect "User name" as a challenge >>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>"Password:". > >The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). > >The wording in the draft is a compromise between the authors. > >-- >Kenneth Murchison Oceana Matrix Ltd. >Software Engineer 21 Princeton Place >716-662-8973 x26 Orchard Park, NY 14127 >--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 16:12:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NCmKP051035 for ; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NCmoY051034 for ietf-sasl-bks; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NClKP051017 for ; Tue, 7 Oct 2003 16:12:47 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97NCao5011151; Tue, 7 Oct 2003 19:12:40 -0400 (EDT) Message-ID: <3F834860.6050807@oceana.com> Date: Tue, 07 Oct 2003 19:12:32 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Steven F Siirila , SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > Ken, > > This use of MAY is a bit problematic. MAY items are suppose to be > truly optional (see RFC 2119). As servers using the > alternative protocol tokens won't interoperate with client not > expecting those alternatives, this item isn't. > > Likely this can be addressed by (more explicitly) limiting the > applicability of the option. I'll let Mark argue for the continued use of MAY. FWIW, I wanted to make the challenge strings used by M$ products a SHOULD and those originally intended by c-client a MAY. Mark is against making c-client [semi-]uncompliant, which I can also agree with. Cyrus SASL uses the M$ challenges and we are not aware of any products which fail to work with these strings, since clients other than M$ correctly ignore the contents of the challenges. Mark, Rob and myself struggled with this issue a lot. >>Steven F Siirila wrote: >> >> >>>In reading section 2.2: >>>2.2. Server side of authentication protocol exchange >>> The server issues the string "User Name" in challenge, and receives a >>> client response. This response is recorded as the authorization >>> identity. The server then issues the string "Password" in challenge, >>> and receives a client response. This response is recorded as the >>> authorization authenticator. The server must verify that the >>> authorization authenticator permits login as the authorization >>> identity. >>> Note: There is at least one widely deployed client which requires >>> that the challenge strings transmitted by the server be "Username:" >>> and "Password:" respectively. For this reason, server >>> implementations MAY send these challenge strings instead of those >>> listed above. >>>Why is the string "User name" chosen as the suggested challenge to be sent >>>by the server instead of "Username:", considering that second paragraph? >>>Are there other clients out there that expect "User name" as a challenge >>>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>>"Password:". >> >>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). >> >>The wording in the draft is a compromise between the authors. >> >>-- >>Kenneth Murchison Oceana Matrix Ltd. >>Software Engineer 21 Princeton Place >>716-662-8973 x26 Orchard Park, NY 14127 >>--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 16:52:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NqLKP052559 for ; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NqLck052558 for ietf-sasl-bks; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from web103.bizmail.yahoo.com (web103.bizmail.yahoo.com [216.136.172.120]) by above.proper.com (8.12.9/8.12.8) with SMTP id h97NqJKP052551 for ; Tue, 7 Oct 2003 16:52:19 -0700 (PDT) (envelope-from syy@gama-tech.com) Message-ID: <20031007234715.54450.qmail@web103.bizmail.yahoo.com> Received: from [218.102.39.129] by web103.bizmail.yahoo.com via HTTP; Tue, 07 Oct 2003 16:47:15 PDT Date: Tue, 7 Oct 2003 16:47:15 -0700 (PDT) From: SY Yip Subject: linkage to data security To: ietf-sasl@imc.org 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: Hi All I'm new to this list. Just wonder if ietf-sasl addresses the linkage of authentication to data security. Meaning, a user logs on to a system, the system is able to use the user identity to determine data access security from LDAP or RDBMS. Today most applications can authenticate users but they use system id to connect to LDAP or RDBMS. As a result, they can't link the login ID to Data Access. Much appreciated for any help. Regards sy yip Gama Technology From owner-ietf-sasl Tue Oct 7 18:24:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OUKP055551 for ; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h981OUx6055550 for ietf-sasl-bks; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OSKP055545 for ; Tue, 7 Oct 2003 18:24:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUmw007879; Tue, 7 Oct 2003 18:24:30 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUx1021400; Tue, 7 Oct 2003 18:24:30 -0700 Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F834860.6050807@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> 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: On Tue, 7 Oct 2003, Ken Murchison wrote: > FWIW, I wanted to make the challenge strings used by M$ products a > SHOULD and those originally intended by c-client a MAY. Mark is against > making c-client [semi-]uncompliant, which I can also agree with. Especially since c-client is the first, reference, and most widely deployed implementation of the LOGIN mechanism; and was written by its inventor. I think that c-client's needs are more important that the evil empire's, and that it would be reprehensible to change specifications to match a broken implementation in evil empireware. I have never encountered the reported problems with evil empireware. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Tue Oct 7 21:37:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bIKP062198 for ; Tue, 7 Oct 2003 21:37:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h984bIKP062197 for ietf-sasl-bks; Tue, 7 Oct 2003 21:37:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bFKP062190 for ; Tue, 7 Oct 2003 21:37:17 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h984bHlg074914; Wed, 8 Oct 2003 04:37:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008090509.03ad6350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 09:37:00 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org In-Reply-To: References: 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: Hallvard, This wording concerns me a bit too. I think we need to have one registry which lists all "public" mechanisms. Hence, I suggest the text be reworded to allow a standard track RFC to establish additional registration requirements for portions of the name space (or "families of names"). That is, the SASL-GSSAPI specification can establish additional requirements for GSSAPI mechanisms. However, SASL-GSSAPI cannot (without updating the base specification) remove requirements established by the base specification. Also, I think having the text belongs only in the IANA Considerations section. Section 4 should just say SASL mechanism names must be registered with the IANA in accordance with Section 8 of this document. Section 8 should include both the guidelines for IANA to follow (for individual names and for families of names) and procedures for those requesting registration. (I suggest having two subsections "Guidelines for IANA" and "Registration Procedures". Kurt At 01:48 PM 9/30/2003, Hallvard B Furuseth wrote: >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? From owner-ietf-sasl Tue Oct 7 22:28:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SnKP070098 for ; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h985Sn0O070096 for ietf-sasl-bks; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SlKP070085 for ; Tue, 7 Oct 2003 22:28:48 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h985Splg075247; Wed, 8 Oct 2003 05:28:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 10:28:30 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: 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: At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >draft-ietf-sasl-plain-02.txt says that > > The client leaves > the authorization identity empty if it wishes the server to derive the > authorization identity from the provided authentication identity. > >and > > Note that the parameters provided to the Authorize function are not > prepared. > >so I think the pseudo-code for empty authzid should say > authzid = DeriveAuthzid(authcid); >and not > authzid = DeriveAuthzid(pAuthcid); I think the current psuedo-code is correct, the first quoted text is misleading. The word "provided" should be deleted as it implies the provided representation (as opposed to prepared representation of the provided authentication identity). Also, I recommend the following text be added immediately above the paragraph which ends with "that string MUST be prepared before generation of the hash." When the no authorization identity is provided, the server SHALL derive the authorization identity from the prepared representation of the provided authentication identity string. This ensures that the derivation of different representations of the authentication identity produce the same authorization identity. Kurt From owner-ietf-sasl Tue Oct 7 23:54:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986spKP098288 for ; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h986spsu098287 for ietf-sasl-bks; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986soKP098275 for ; Tue, 7 Oct 2003 23:54:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h986smlg075769; Wed, 8 Oct 2003 06:54:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 11:54:31 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: ietf-sasl@imc.org In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> 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: My main gripe here is that the I-D implied incorrectly that the IETF character set policy RECOMMENDs protocols be able to use UTF-8 when the police that protocols are REQUIRED to be able to use UTF-8. I think both these "Per IETF character set policy" statements should be deleted. Inserting a note like shown below might be appropriate. > The character encoding scheme used (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols) for > transmitting an authorization identity over protocol is > specified in each authentication mechanism (with the > authentication mechanism's blob being further > restricted/encoded by the protocol profile). At 08:43 AM 10/1/2003, Jeffrey Hutzelman wrote: >>> Per IETF character set >>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>> these and other strings in UTF-8 [UTF-8]. >> >>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>not support UTF-8 transfer of character data. >>[CHARSET-POLICY] says: >> Protocols MUST be able to use the UTF-8 charset, which consists of >> the ISO 10646 coded character set combined with the UTF-8 character >> encoding scheme, as defined in [10646] Annex R (published in >> Amendment 2), for all text. > >It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. > Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. > >So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". From owner-ietf-sasl Wed Oct 8 04:52:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqMKP041254 for ; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98BqMs2041253 for ietf-sasl-bks; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqGKP041248 for ; Wed, 8 Oct 2003 04:52:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 12:52:14 +0100 Message-ID: <3F83FA6D.1030909@isode.com> Date: Wed, 08 Oct 2003 12:52:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sorry about coming with these comments so late. I have just discovered >the SASL list, and there was a lot to read:-) >Feel free to ignore comments that have already been discussed. > >>4. Authentication mechanisms >> >> SASL mechanisms are named by >> >> > >ASCII > > > >> strings, >> (...) >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase >> >> > >ASCII > Ok. >>letters, >> ; digits, "-" and "_" >> >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; >> >> > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > IMHO, this was the intent. I will try to clarify this. >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, >> > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? > Does it matter in this section? >>4.2. Authorization identities and proxy authentication >> >> (...) >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> >> > ^^^^ > >What's a blob? I don't think it's 'something ill-defined or amorphous', >like the dictionary says:-) > I've changed this to "data". >>4.3. Security layers >> >> If use of a security layer is negotiated by the authentication >> protocol exchange, the security layer is applied to all subsequent >> data sent over the connection >> > >... until another security layer or no security layer is negotiated. > >[Added according to section 6.3.] > > > Done. >> In >> order to avoid noninteroperability due to differing normalizations, >> when a mechanism specifies that a string authentication identity or >> password used as input to a cryptographic function (or used for >> comparison) it SHOULD specify that the string first be prepared using >> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >> [StringPrep]. This should be done by both the client (upon getting >> user input or retrieving a value from configuration) and by the >> server (upon receiving the value from the client). >> >> > >What's the point of this duplicate preparation? Why not do it only >at the server side? > > Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] >> > >Nitpick: I think the period should be after [GSSAPI]. > Fixed. >> This >> service name is made available to the authentication mechanism. >> >> > >There should be no paragraph break here. > Fixed. >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" >> >> > >Instead, a paragraph break here. (And a trailing '.'.) > > Fixed. >> A definition >> of the command to initiate the authentication protocol exchange. >> >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. >> >> > >I suggest you rename "an optional challenge" to "optional data", or >put "challenge" in quotes. > > Ok. >> A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics. >> >> > >Add a paragraph break here, since the following is a new item. Remove >"A protocol profile MUST specify" to just make the following a new item >in the list of things that must be specified. > > > >> A protocol profile MUST specify the >> form of the authorization identity (as it is protocol specific, as >> >> I would rather not do this, as this is a single logic item. > > > >>6.3. Multiple authentications >> >> Unless otherwise stated by the protocol's profile, only one >> successful SASL negotiation may occur in a protocol session. >> >> > >This should be mentioned in the "Protocol profile requirements" section. > I agree. >>7.1. Formal syntax >> >> initial-response = *( UTF8-char-no-null ) >> >> > >Why is initial-response required to be UTF-8 when the character encoding >scheme of the rest of the exchange is left to the specifications of the >individual mechanisms? I would think that either initial-response >merely "SHOULD" be UTF-8, like the rest of the exchange. > This is specific to EXTERNAL. I've changed "initial-response" to "extern-init-resp" in order to avoid confusion. > > > >And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >top. > > I've added a sentence about this in the introduction section. Alexey > > From owner-ietf-sasl Wed Oct 8 05:06:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6RKP042074 for ; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98C6RTI042073 for ietf-sasl-bks; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6PKP042068 for ; Wed, 8 Oct 2003 05:06:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:06:21 +0100 Message-ID: <3F83FDBB.70702@isode.com> Date: Wed, 08 Oct 2003 13:06:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Proxy authentication (was WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt) References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Because there are too many issues raised I will be starting a separate thread for each] Kurt D. Zeilenga wrote: >> During the authentication protocol exchange, the mechanism performs >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, and negotiates the use of a >> mechanism-specific security layer. If the use of a security layer is >> agreed upon, then the mechanism must also define or negotiate the >> maximum security layer buffer size that each side is able to receive. >> >>4.2. Authorization identities and proxy authentication >> > > >See note below regarding the term "proxy authentication". > > > ... >> The identity derived from the client's authentication credentials is >> known as the "authentication identity". With any mechanism, >> transmitting an authorization identity of the empty string directs >> the server to derive an authorization identity from the client's >> authentication identity. >> >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". >> >> > >Personally, I refer to this as "proxy authorization". Proxy >authentication makes it sound like the feature can be used by a >proxy to authenticate its users. > > > Jeffrey Hutzelman wrote: >>> If the authorization identity transmitted during the authentication >>> protocol exchange is not the empty string, this is typically referred >>> to as "proxy authentication". >> >> Personally, I refer to this as "proxy authorization". Proxy >> authentication makes it sound like the feature can be used by a >> proxy to authenticate its users. > > The same argument can be made for "proxy authorization". We are > talking about "authentication by proxy", not "authentication to a > proxy". And yes, we're really talking about authorization, not > authentication, but it's not really "authorization by proxy"; it's > just authorization. > > The terminology is pretty bad. It's not clear to me that we need a > name for this at all. But I'm pretty sure the phrase "proxy > authentication" has been in use for a while, and to change it might > cause more confusion than leaving it alone. So, I will leave it as is. Alexey From owner-ietf-sasl Wed Oct 8 05:38:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcaKP043368 for ; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98CcaCQ043367 for ietf-sasl-bks; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcZKP043356 for ; Wed, 8 Oct 2003 05:38:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:38:34 +0100 Message-ID: <3F840549.3040101@isode.com> Date: Wed, 08 Oct 2003 13:38:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>> 5. Protocol profile requirements >>> >>> In order to use this specification, a protocol definition MUST supply >>> the following information: >>> >>> A service name, to be selected from the IANA registry of "service" >>> elements for the GSSAPI host-based service name form. [GSSAPI] This >>> service name is made available to the authentication mechanism. >>> >>> The registry is available at the URL >>> "http://www.iana.org/assignments/gssapi-service-names" A definition >> > Paragraph break. Yes, this is already fixed in my copy. >>> A definition of the method by which the authentication protocol >>> exchange is carried out, including how the challenges and responses >>> are encoded, how the server indicates completion or failure of the >>> exchange, how the client aborts an exchange, and how the exchange >>> method interacts with any line length limits in the protocol. >>> >>> The command SHOULD have a method for the server to include an >>> optional challenge with a success notification. This allows the >>> server to avoid a round trip when using a mechanism which is defined >>> to have the server send additional data along with the indication of >>> successful completion. See section 6.2 of this document for further >>> information. >> > What command? Who says "the method by which the authentication > protocol exchange is carried out" is a command? s/The command/The > exchange method/ Yes. >>> 8.3. Change control >>> >>> Once a SASL mechanism registration has been published by IANA, the >>> author may request a change to its definition. The change request >>> follows the same procedure as the registration request. >> > This sounds a lot like the stringprep loophole, and it makes me nervous. Can you be more specific in what do you want to be changed. Would you rather reference the SASL WG as the Change Controller? >>> In certain situations, it is reasonable to use SASL underneath one of >>> these Transport Security services. The transport service would >>> secure the connection, either service would authenticate the client, >>> and SASL would negotiate the authorization identity. The SASL >>> negotiation would be what moves the protocol from "unauthenticated" >>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>> explicitly intended to handle the case where the transport service >>> secures the connection and authenticates the client and SASL >>> negotiates the authorization identity. >>> >>> When using SASL underneath a sufficiently strong Transport Security >>> service, a SASL security layer would most likely be redundant. The >>> client and server would thus probably want to negotiate off the use >>> of a SASL security layer. >> > > Please don't say this without a _lot_ more text explaining when it is > safe. A common configuration is to run SASL under TLS, using SASL for > client authentication and negotation of the authorization identity. > In this configuration, it is _not_ safe to skip using a SASL security > layer if the client did not check the server's certificate (there is a > tunnelling MitM attack), and it's not a particularly good idea even if > the server cert was checked, because the client's authentication is > still not bound to the encryption keys used at the TLS layer. > > We already have problems with people who think it is actively bad to > use a SASL security layer under TLS. The result is that some insecure > configurations are now widely deployed. Let's not encourage this any > further. Should I just drop this paragraph? >>> The IANA is directed to modify the SASL mechanisms registry as >>> follows: >> >> >> Please reword this to be not so demanding. For example, >> It is requested that IANA update the SASL mechanisms registry >> as follows: > > > It's not demanting; it's perfectly reasonable usage. The IANA works > for the IETF; it is appropriate for the IETF, in the form of a > standards-track document, to direct it to make changes to a registry. > It is also common usage. I've already changed this to be "nicer" to IANA ;-). > Put the TOC at the _top_ of the document, just after the abstract. > See the "Tabel of Contents" section at > http://www.rfc-editor.org/policy.html This is editorial and I don't want to spend time doing this at this stage. I am going to sort this out with the RFC editor directly. Alexey From owner-ietf-sasl Wed Oct 8 06:33:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXCKP046247 for ; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DXCSS046246 for ietf-sasl-bks; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXBKP046240 for ; Wed, 8 Oct 2003 06:33:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:33:05 +0100 Message-ID: <3F841210.7030700@isode.com> Date: Wed, 08 Oct 2003 14:33:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >My main gripe here is that the I-D implied incorrectly that >the IETF character set policy RECOMMENDs protocols be able >to use UTF-8 when the police that protocols are REQUIRED >to be able to use UTF-8. > >I think both these "Per IETF character set policy" statements >should be deleted. Inserting a note like shown below might >be appropriate. > > >> The character encoding scheme used >> >> >(see [CHARSET-POLICY]for IETF policy regarding character sets in IETF protocols) > > > >> for transmitting an authorization identity over protocol is >> specified in each authentication mechanism (with the >> authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> I've changed the first reference as you suggested, and the last to: Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). > > >>>> Per IETF character set >>>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>>> these and other strings in UTF-8 [UTF-8]. >>>> >>>> >>>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>>not support UTF-8 transfer of character data. >>>[CHARSET-POLICY] says: >>> Protocols MUST be able to use the UTF-8 charset, which consists of >>> the ISO 10646 coded character set combined with the UTF-8 character >>> encoding scheme, as defined in [10646] Annex R (published in >>> Amendment 2), for all text. >>> >>> >>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. >>Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. >> >>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> >> From owner-ietf-sasl Wed Oct 8 06:44:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiNKP046617 for ; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DiNVd046616 for ietf-sasl-bks; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiJKP046606 for ; Wed, 8 Oct 2003 06:44:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h98DiBo5027156; Wed, 8 Oct 2003 09:44:11 -0400 (EDT) Message-ID: <3F84154B.7080006@oceana.com> Date: Wed, 08 Oct 2003 09:46:51 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 7 Oct 2003, Ken Murchison wrote: > >>FWIW, I wanted to make the challenge strings used by M$ products a >>SHOULD and those originally intended by c-client a MAY. Mark is against >>making c-client [semi-]uncompliant, which I can also agree with. > > > Especially since c-client is the first, reference, and most widely > deployed implementation of the LOGIN mechanism; and was written by its > inventor. I'm not going to argue numbers, but I'm guessing that there are a significant number of deployed Outlook clients. ;) > I think that c-client's needs are more important that the evil empire's, > and that it would be reprehensible to change specifications to match a > broken implementation in evil empireware. Your comment seems somewhat self serving, but I also find it distasteful to have to cater to M$. The problem is that LOGIN was never a standard, and M$ took it and did their (incorrect) own thing. Since the cat is already out of the bag, and I don't think we can get M$ to change their code, we have to deal with it. > I have never encountered the reported problems with evil empireware. This is probably because c-client isn't used in any SMTP server code (at least AFAIK). AFAIK, the challenge strings are only an issue with Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a SHOULD/MUST for SMTP server code only. I don't think this will make c-client noncompliant, will it? We probably need more input from others on the list, since Mark and I are just rehashing discussions that we've already had. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Oct 8 06:59:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx1KP047180 for ; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Dx1Gc047179 for ietf-sasl-bks; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx0KP047174 for ; Wed, 8 Oct 2003 06:59:00 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:59:01 +0100 Message-ID: <3F841823.6010502@isode.com> Date: Wed, 08 Oct 2003 14:58:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have an impression that there are two many little things to change so that we will need a new Last Call anyway. Is my perception correct? If it is, I will issue a new revision shortly. Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): 1). IANA considerations and registering a familily of SASL mechanisms. 2). Clarification on replacing a security layer 3). Realm 4). Other minor editorial issues. Alexey From owner-ietf-sasl Wed Oct 8 06:58:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwCKP047147 for ; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DwCW6047146 for ietf-sasl-bks; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwBKP047141 for ; Wed, 8 Oct 2003 06:58:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:58:10 +0100 Message-ID: <3F8417F0.6000407@isode.com> Date: Wed, 08 Oct 2003 14:58:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>7. The EXTERNAL mechanism >> >> The mechanism name associated with external authentication is >> "EXTERNAL". >> >> The client sends an initial response with the UTF-8 encoding of the >> authorization identity. The form of the authorization identity is >> further restricted by the application-level protocol's SASL profile. >> >> The server uses information, external to SASL, to determine whether >> the client is authorized to authenticate as the authorization >> identity. >> >> > >It may be appropriate to note that the client can make no >assumptions as what information the server uses in determining >client authorization. E.g., just because TLS was established, >doesn't mean the server will use TLS-provided information. > > Done. The new text reads: The system providing this external information may be, for example, IPSec or TLS. However, the client can make no assumptions as to what information the server can use in determining client authorization. E.g., just because TLS was established, doesn't mean that the server will use the information provided by TLS. >>7.2. Example >> >> The following is an example of an EXTERNAL authentication in the SMTP >> protocol [SMTP-AUTH]. >> >> > >Replace [SMTP-AUTH] with an informative reference to the SMTP base >specification. Insert [SMTP-AUTH] after the word "profile" below. > Done. Alexey From owner-ietf-sasl Wed Oct 8 07:19:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98EJnKP048151 for ; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98EJnH8048149 for ietf-sasl-bks; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98EJiKP048140 for ; Wed, 8 Oct 2003 07:19:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa18273; 8 Oct 2003 10:19 EDT Date: Wed, 08 Oct 2003 10:19:29 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <3F840549.3040101@isode.com> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 08, 2003 13:38:33 +0100 Alexey Melnikov wrote: >>>> 8.3. Change control >>>> >>>> Once a SASL mechanism registration has been published by IANA, the >>>> author may request a change to its definition. The change request >>>> follows the same procedure as the registration request. >>> >> This sounds a lot like the stringprep loophole, and it makes me nervous. > > Can you be more specific in what do you want to be changed. No. Perhaps I'm being paranoid, but the concern is that if mechanism FOO gets registered and implemented, no one should be able to come along later and change FOO to mean some other, non-compatible mechanism. Maybe it's not worth worrying about.. In any case, no, I can't be more specific; I don't know what change could make this better, and I don't think I was really asking for one. It just makes me nervous. > Would you rather reference the SASL WG as the Change Controller? No, especially since the SASL WG will likely conclude within the foreseeable future. >>>> In certain situations, it is reasonable to use SASL underneath one of >>>> these Transport Security services. The transport service would >>>> secure the connection, either service would authenticate the client, >>>> and SASL would negotiate the authorization identity. The SASL >>>> negotiation would be what moves the protocol from "unauthenticated" >>>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>>> explicitly intended to handle the case where the transport service >>>> secures the connection and authenticates the client and SASL >>>> negotiates the authorization identity. >>>> >>>> When using SASL underneath a sufficiently strong Transport Security >>>> service, a SASL security layer would most likely be redundant. The >>>> client and server would thus probably want to negotiate off the use >>>> of a SASL security layer. >>> >> >> Please don't say this without a _lot_ more text explaining when it is >> safe. A common configuration is to run SASL under TLS, using SASL for >> client authentication and negotation of the authorization identity. >> In this configuration, it is _not_ safe to skip using a SASL security >> layer if the client did not check the server's certificate (there is a >> tunnelling MitM attack), and it's not a particularly good idea even if >> the server cert was checked, because the client's authentication is >> still not bound to the encryption keys used at the TLS layer. >> >> We already have problems with people who think it is actively bad to >> use a SASL security layer under TLS. The result is that some insecure >> configurations are now widely deployed. Let's not encourage this any >> further. > > Should I just drop this paragraph? Yeah, IMHO it would be reasonable to just drop the paragraph starting "When using SASL underneath..." >> Put the TOC at the _top_ of the document, just after the abstract. >> See the "Tabel of Contents" section at >> http://www.rfc-editor.org/policy.html > > This is editorial and I don't want to spend time doing this at this stage. > I am going to sort this out with the RFC editor directly. Fair enough. From owner-ietf-sasl Wed Oct 8 08:35:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZKKP051880 for ; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98FZKF7051879 for ietf-sasl-bks; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZJKP051870 for ; Wed, 8 Oct 2003 08:35:19 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZBaZ018004; Wed, 8 Oct 2003 08:35:11 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZB5b002839; Wed, 8 Oct 2003 08:35:11 -0700 Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F84154B.7080006@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> 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: On Wed, 8 Oct 2003, Ken Murchison wrote: > > Especially since c-client is the first, reference, and most widely > > deployed implementation of the LOGIN mechanism; and was written by its > > inventor. > I'm not going to argue numbers, but I'm guessing that there are a > significant number of deployed Outlook clients. ;) Even if Outlook may be more widespread, there are millions of deployed Pine clients (we have the numbers). c-client is more than just client code; it's also the engine behind UW imapd and ipop3d. UW imapd is the most widely deployed IMAP server. > Your comment seems somewhat self serving, Well, I could say the same for many comments from ... Let's not go here. > but I also find it distasteful > to have to cater to M$. > The problem is that LOGIN was never a standard, > and M$ took it and did their (incorrect) own thing. LOGIN was not documented because I followed the rules. IESG said "no more plaintext password authentication mechanisms." IESG didn't offer any wiggle room the way. Politics allowed PLAIN to be snuck through but not LOGIN (which preceeded PLAIN by 3 1/2 years). If you're going to cater to Microsoft's bugs, then much of IMAP needs to be thrown out because of broken behavior in their software. Microsoft should be made to fix their bugs instead. I would like to see the security people redefine TLS so that that the maximum payload is 5 bytes less than 16K (rather than 16K), since Microsoft requires that. > This is probably because c-client isn't used in any SMTP server code (at > least AFAIK). AFAIK, the challenge strings are only an issue with > Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a > SHOULD/MUST for SMTP server code only. I don't think this will make > c-client noncompliant, will it? I am working an an SMTP server. I don't think that an SMTP-only kludge to accomodate a bug is appropriate when there is another alternative (that is, PLAIN). The correct answer is that if Outlook has problems using LOGIN, then it can always use PLAIN. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Wed Oct 8 09:24:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOxKP055202 for ; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98GOxTG055201 for ietf-sasl-bks; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOvKP055196 for ; Wed, 8 Oct 2003 09:24:58 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 17:24:57 +0100 Message-ID: <3F843A58.20103@isode.com> Date: Wed, 08 Oct 2003 17:24:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org, Peter Saint-Andre Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>>> When using SASL underneath a sufficiently strong Transport Security >>>>> service, a SASL security layer would most likely be redundant. The >>>>> client and server would thus probably want to negotiate off the use >>>>> of a SASL security layer. >>>> >>> Please don't say this without a _lot_ more text explaining when it is >>> safe. A common configuration is to run SASL under TLS, using SASL for >>> client authentication and negotation of the authorization identity. >>> In this configuration, it is _not_ safe to skip using a SASL security >>> layer if the client did not check the server's certificate (there is a >>> tunnelling MitM attack), and it's not a particularly good idea even if >>> the server cert was checked, because the client's authentication is >>> still not bound to the encryption keys used at the TLS layer. >>> >>> We already have problems with people who think it is actively bad to >>> use a SASL security layer under TLS. The result is that some insecure >>> configurations are now widely deployed. Let's not encourage this any >>> further. >> >> Should I just drop this paragraph? > > Yeah, IMHO it would be reasonable to just drop the paragraph starting > "When using SASL underneath..." Done. Alexey From owner-ietf-sasl Wed Oct 8 10:40:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HelKP059213 for ; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HelkI059212 for ietf-sasl-bks; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HejKP059207 for ; Wed, 8 Oct 2003 10:40:46 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id E3F3C63EB6; Wed, 8 Oct 2003 12:40:46 -0500 (CDT) Date: Wed, 8 Oct 2003 12:40:46 -0500 From: Peter Saint-Andre To: xmppwg@jabber.org Cc: Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031008174046.GB31898@jabber.org> References: <3F8334ED.80504@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8334ED.80504@isode.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Oct 07, 2003 at 10:49:33PM +0100, Alexey Melnikov wrote: > I would like to raise several SASL related issues in XMPP document. > (Sorry for crosspost and sorry for being late with reviewing this.) No apologies necessary -- your feedback is appreciated. > 1). > > 7. The initiating entity MUST provide an authzid during SASL > > negotiation. The authzid-value MUST be a valid JID of the form > > (i.e., a domain identifier only) for servers and of the > > form (i.e., node identifier, domain > > identifier, and resource identifier) for clients. The initiating > > entity MAY process the authzid-value in accordance with the rules > > defined in Addressing Scheme (Section 3) before providing it to > > the receiving entity, but is NOT REQUIRED to do so; however, the > > receiving entity MUST verify that the authzid-value provided by > > the initiating entity conforms to the rules defined therein. > > Not all SASL mechanisms are capable of transmitting authorization > identity, so this requirement might be problematic. > > Also, the revision of RFC 2222 says that the client must not specify > authorization-id unless it wants to impersonate some other entity: > > As a client might not have the same information as the server, > clients SHOULD NOT themselves try to derive authorization identities > from authentication identities when clients could instead transmit an > authorization identity of the empty string. > > So, the text should be reworded reflect that an authorization identity > is optional and that if one is provided, it is in the form described above. My understanding from an earlier thread on the XMPP WG list was that providing the authorization identity in this manner was the approach preferred by the SASL community. I think the fundamental issue here is that for XMPP clients, the authorization identity is a "full JID" (i.e., node@host/resource) that is asserted by the connecting client, not derived by the server. Perhaps this usage is not consistent with the definition of authorization identity in RFC 2222? We'd have to look at the implications of this for client assertion of a full JID (perhaps this should be defined only in draft-ietf-xmpp-im). > 2). > > > This series of challenge/response pairs continues until one of three > > things happens: > > > > 1. The initiating entity aborts the handshake by sending an > > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > > namespace to the receiving entity. Upon receiving the > > element, the receiving entity MUST terminate the TCP connection. > > I think the requirement to drop TCP connection is unreasonable here. > There are several valid reasons why the client may retry failed > authentication: > 1). User typed in a wrong password, the client should retry the same > SASL mechanism a reasonable number of times. > 2). The client invoked a SASL mechanism that reported that it can't be > used because of misconfiguration (e.g. kerberos configuration file is > missing). The client than sends to the server and tries another > mechanism. This seems reasonable. I think we were attempting to ensure that the connecting entity could not abuse the opened TCP connection for an unspecified period of time. > 3). > > > 3. The receiving entity reports success of the handshake by sending > > a element qualified by the > > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > > entity; this element MAY optionally contain character data (in > > SASL terminology "additional data with success"). Upon receiving > > the element, the initiating entity MUST initiate a new > > stream by sending an opening XML stream header to the receiving > > entity (it is not necessary to send a closing > > element first, since the receiving entity and initiating entity > > MUST consider the original stream to be closed upon sending or > > receiving the element). Upon receiving the new stream > > header from the initiating entity, the receiving entity MUST > > respond by sending a new XML stream header to the initiating > > entity, along with any remaining available features (but NOT > > including the STARTTLS feature or any authentication mechanisms) > > or an empty features element (to signify that no additional > > features are available); note that any such additional features > > are not defined herein, and MUST be defined by the relevant > > extension to XMPP. > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > successful SASL authentication. > Some of them require that the client compares the list of the advertised > mechanism with the one before the authentication. > This is done to prevent man-in-the-middle attacks when an attacker > removes strong SASL mechanisms from the list of supported mechanisms. > (Whether this check is useful in practice is another matter. I am not > sure whether anybody implements it). OK, I'll look at what those other protocols require, and how they word the requirement. It seems good to have this check in place. > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. Thanks for the suggested text. > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) I see no strong reason to relax the requirement just for XMPP. > 5). > >6.3 SASL Errors > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > Do you mean invalid base64 encoding here or something else? It could be invalid base64 encoding, but we were thinking especially that the decoded response is not consistent with the challenge format required by the selected SASL mechanism. > 6). > > >6.3 SASL Errors > > > > The following SASL-related error conditions are defined: > > > > o -- The receiving entity acknowledges an > > element sent by the initiating entity; sent in response to the > > element. > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > or with initial challenge data. Example: SASL PLAIN mechanism. > > > o -- The mechanism chosen by the initiating > > entity may be used only if the stream is already encrypted; sent > > in response to the element. > > > > o -- The authzid provided by the initiating > > entity is invalid, either because it is incorrectly formatted or > > because the initiating entity does not have permissions to > > authorize that ID; sent in response to a element. > > or with initial challenge data. > > > o -- The initiating entity did not provide a > > mechanism or requested a mechanism that is not supported by the > > receiving entity; sent in response to the element. > > > > o -- The realm provided by the initiating entity > > (in mechanisms that support the concept of a realm) does not match > > one of the hostnames served by the receiving entity; sent in > > response to a element. > > or with initial challenge data. > > > o -- The mechanism requested by the initiating > > entity is weaker than server policy permits for that initiating > > entity; sent in response to the element. > > or with initial challenge data. > > > o -- The authentication failed because the > > initiating entity did not provide valid credentials (this includes > > the case of an unknown username); sent in response to a > element. > > or with initial challenge data. I've fixed these in my working copy. > 7). > > >12.4 Order of Layers > > > > The order of layers in which protocols MUST be stacked is as follows: > > > > 1. TCP > > > > 2. TLS > > > > 3. SASL > > > > 4. XMPP > > > > The rationale for this order is that TCP is the base connection layer > > used by all of the protocols stacked on top of TCP, TLS is often > > provided at the operating system layer, SASL is often provided at the > > application layer, and XMPP is the application itself. > > This should be referenced in "6.4 SASL Definition" section, because it > is related to the XMPP profile of SASL. Fixed in my working copy. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From owner-ietf-sasl Wed Oct 8 10:49:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HnfKP059704 for ; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HneC2059703 for ietf-sasl-bks; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HndKP059698 for ; Wed, 8 Oct 2003 10:49:40 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id C891F151D9B; Wed, 8 Oct 2003 13:49:38 -0400 (EDT) To: Ken Murchison , "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> From: Sam Hartman Date: Wed, 08 Oct 2003 13:49:38 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 8 Oct 2003 08:35:11 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: It seems like you may want to document clearly the interoperability concern. Mention specific products as examples if it makes your text more clear. Just make sure your claims are accurate. From owner-ietf-sasl Wed Oct 8 10:57:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv3KP060293 for ; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Hv3p5060292 for ietf-sasl-bks; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv2KP060286 for ; Wed, 8 Oct 2003 10:57:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Huulg081187; Wed, 8 Oct 2003 17:56:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 22:56:38 -0700 To: iesg@ietf.org From: "Kurt D. Zeilenga" Subject: Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, SASL WG In-Reply-To: <3F8334ED.80504@isode.com> References: <3F8334ED.80504@isode.com> 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: To the IESG, I concur with Alexey's recent comments regarding XMPP's SASL Profile. I have a few addition concerns regarding this profile. The scope of my review was, due to time constraints, was limited to the profile. I not sure why the documents says that SASL and TLS security layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), but this recommendation is, I believe, flawed. There are numerous use cases where implementations SHOULD establish additional layers. For example, establishing additional SASL layers may prevent certain kinds of tunneling man-in-the-middle attacks. The requirement that initiating receiving entity drop all knowledge it learned before negotiating SASL layers (rule 5) is too broad. This could be viewed as requiring the implement to forget knowledge it gained previously in a secure manner (such as an externally established lower level (IPSEC or TLS) identity information). Likewise for rule 6. For rule 8, a normative reference to the base64 encoding algorithm should be provided. I am also concerned by the use of the term "stream encryption" in the document as this doesn't imply, in my eyes, "stream integrity". It's unclear to me which imperatives imply when encryption, integrity, and/or in combination with other security services which TLS provides. Additionally, I would like to note that the document suffers from a number of nits. As I only did a casual scan, this list is likely no where near complete. I suggest that XMMP WG members be asked to do a more careful review for nits. Acronym not spelled out in title: XMMP Citiation in abstract Used old citation style (numeric tags instead of mnemonic tags) Acronyms not spelled out on first use in Abstract: XML Table of contents too long Acronyms not spelled out on first use in body: XML, JID Confusing upper casing of words: COULD Odd use of 2119 keywords: "MAY optionally" From owner-ietf-sasl Wed Oct 8 11:25:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPvKP062655 for ; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98IPvQb062654 for ietf-sasl-bks; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPuKP062648 for ; Wed, 8 Oct 2003 11:25:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h98IOf5t013327; Wed, 8 Oct 2003 14:24:41 -0400 Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT) From: Rob Siemborski To: Peter Saint-Andre cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) In-Reply-To: <20031008174046.GB31898@jabber.org> Message-ID: References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> 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: On Wed, 8 Oct 2003, Peter Saint-Andre wrote: > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > > successful SASL authentication. > > Some of them require that the client compares the list of the advertised > > mechanism with the one before the authentication. This claim isn't true. SMTP has a MAY for this, the other protocols don't express an opinion one way or the other. I know some IMAP and POP implementations remove the capability after a successful authentication (to indicate that the AUTHENTICATE/AUTH command is no longer valid) > > This is done to prevent man-in-the-middle attacks when an attacker > > removes strong SASL mechanisms from the list of supported mechanisms. > > (Whether this check is useful in practice is another matter. I am not > > sure whether anybody implements it). > > OK, I'll look at what those other protocols require, and how they word > the requirement. It seems good to have this check in place. I'm not sure its terribly useful, since the real way to prevent this MitM attack is that a client should not use a mechanism that does not support its minimum security requirements, not find out after the fact that you have an active attacker. I will also be posting IDs within the next few days that are revisions to RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be useful to look at (hopefully they will be clearer). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 8 12:10:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAuKP064383 for ; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JAuvd064382 for ietf-sasl-bks; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAmKP064372 for ; Wed, 8 Oct 2003 12:10:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:10:25 +0100 Message-ID: <3F84611F.9020601@isode.com> Date: Wed, 08 Oct 2003 20:10:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>2). >> >> >>> This series of challenge/response pairs continues until one of three >>> things happens: >>> >>> 1. The initiating entity aborts the handshake by sending an >>> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' >>> namespace to the receiving entity. Upon receiving the >>> element, the receiving entity MUST terminate the TCP connection. >>> >>> >>I think the requirement to drop TCP connection is unreasonable here. >>There are several valid reasons why the client may retry failed >>authentication: >>1). User typed in a wrong password, the client should retry the same >>SASL mechanism a reasonable number of times. >>2). The client invoked a SASL mechanism that reported that it can't be >>used because of misconfiguration (e.g. kerberos configuration file is >>missing). The client than sends to the server and tries another >>mechanism. >> >> > >This seems reasonable. I think we were attempting to ensure that the >connecting entity could not abuse the opened TCP connection for an >unspecified period of time. > Closing connection or refusing to perform any tasks after a certain number of failures are two common implementation practice in SMTP and other protocols. I think you should mention them, but don't require everyone to implement them. >>3). >> >> >>> 3. The receiving entity reports success of the handshake by sending >>> a element qualified by the >>> 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating >>> entity; this element MAY optionally contain character data (in >>> SASL terminology "additional data with success"). Upon receiving >>> the element, the initiating entity MUST initiate a new >>> stream by sending an opening XML stream header to the receiving >>> entity (it is not necessary to send a closing >>> element first, since the receiving entity and initiating entity >>> MUST consider the original stream to be closed upon sending or >>> receiving the element). Upon receiving the new stream >>> header from the initiating entity, the receiving entity MUST >>> respond by sending a new XML stream header to the initiating >>> entity, along with any remaining available features (but NOT >>> including the STARTTLS feature or any authentication mechanisms) >>> or an empty features element (to signify that no additional >>> features are available); note that any such additional features >>> are not defined herein, and MUST be defined by the relevant >>> extension to XMPP. >>> >>> >>Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a >>successful SASL authentication. >>Some of them require that the client compares the list of the advertised >>mechanism with the one before the authentication. >>This is done to prevent man-in-the-middle attacks when an attacker >>removes strong SASL mechanisms from the list of supported mechanisms. >>(Whether this check is useful in practice is another matter. I am not >>sure whether anybody implements it). >> >> > >OK, I'll look at what those other protocols require, and how they word >the requirement. It seems good to have this check in place. > I don't have a strong feeling about this. I am just emphasizing the difference between other protocols and XMPP in this case. A security person should comment on this. >>4). There was a recent discussion on the bugtraq mailing list about >>handling invalid base64 data. It turned out that different >>implementations handle >>this differently, for example: >>... >> >>(You might decide to relax this for XMPP and to allow spaces and/or >>CRLFs anywhere in the data.) >> >> > >I see no strong reason to relax the requirement just for XMPP. > This is fine. I was just thinking about a base64 encoder that enforces a line length limit and will insert CRLF automatically. >>5). >> >> >>>6.3 SASL Errors >>> >>> o -- The data provided by the initiating entity >>> could not be processed, e.g. because does not adhere to the >>> protocol for the requested mechanism; sent in response to the >>> element. >>> >>> >>Do you mean invalid base64 encoding here or something else? >> >> > >It could be invalid base64 encoding, but we were thinking especially >that the decoded response is not consistent with the challenge format >required by the selected SASL mechanism. > > Challenge format is specific to a SASL mechanism. As far as the protocol using SASL is concerned, invalid SASL mechanism format is not different from "authentication failure". An error from a SASL mechanism is different from an error resulting in inability to decode base64 data. These errors happen at different layers, so they should have different error tags. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 8 12:32:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JW1KP065291 for ; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JW1Zi065290 for ietf-sasl-bks; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JVxKP065282 for ; Wed, 8 Oct 2003 12:31:59 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> Date: Wed, 08 Oct 2003 20:31:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 8 13:21:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL8KP066772 for ; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98KL8Dg066771 for ietf-sasl-bks; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL7KP066766 for ; Wed, 8 Oct 2003 13:21:07 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id A832AAC0A; Wed, 8 Oct 2003 13:28:14 -0700 (PDT) To: xmppwg@jabber.org Cc: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 13:28:14 -0700 In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Kurt D. Zeilenga" writes: > I concur with Alexey's recent comments regarding XMPP's SASL > Profile. I have a few addition concerns regarding this profile. > The scope of my review was, due to time constraints, was limited > to the profile. > > I not sure why the documents says that SASL and TLS security > layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this recommendation is, I believe, flawed. There are numerous use > cases where implementations SHOULD establish additional layers. > For example, establishing additional SASL layers may prevent > certain kinds of tunneling man-in-the-middle attacks. Could you describe some of them? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 13:46:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk3KP067429 for ; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kk3Xn067428 for ietf-sasl-bks; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk2KP067421 for ; Wed, 8 Oct 2003 13:46:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Kk3lg082611; Wed, 8 Oct 2003 20:46:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 01:45:45 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> 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: At 04:52 AM 10/8/2003, Alexey Melnikov wrote: >>> In >>> order to avoid noninteroperability due to differing normalizations, >>> when a mechanism specifies that a string authentication identity or >>> password used as input to a cryptographic function (or used for >>> comparison) it SHOULD specify that the string first be prepared using >>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>> [StringPrep]. This should be done by both the client (upon getting >>> user input or retrieving a value from configuration) and by the >>> server (upon receiving the value from the client). >>> >> >>What's the point of this duplicate preparation? Why not do it only >>at the server side? >> >Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. Alexey, the current text suggests that client (1) prep the value before sending, the server then preps it (2) again (before comparing it to the store value, which also should be prep'ed (3) either before storing it or before each compare). We need to REQUIRE that mechanisms specify how character strings are to be prepared for comparison and RECOMMEND that they use SASLprep for simple user names and passwords. We should not suggest that mechanisms should do both (1) and (2). (1) and (3) OR (2) or (3) are sufficient to ensure proper matching. Kurt From owner-ietf-sasl Wed Oct 8 13:53:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr5KP067641 for ; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kr5X1067639 for ietf-sasl-bks; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr3KP067634 for ; Wed, 8 Oct 2003 13:53:04 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h98Kr0js010724 for ; Wed, 8 Oct 2003 15:53:00 -0500 Received: from att.com (unknown[135.210.35.140](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031008205022gw100lr6v3e> (Authid: tony); Wed, 8 Oct 2003 20:50:22 +0000 Message-ID: <3F84792B.1000301@att.com> Date: Wed, 08 Oct 2003 16:52:59 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011022 Netscape6/6.2 X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: xmppwg@jabber.org CC: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> In-Reply-To: <3F8334ED.80504@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: White space and CRLFs were specifically allowed in the original MIME base64 specification because of: line length limitations in the underlying protocols gateways that would add or subtract white space willy-nilly it was useful being able to work with base64 data in small chunks when doing development and debugging The first two issues don't apply here, but the last one certainly still does. So I'd recommend that whitespace and CRLFs be ignored. Tony Hansen tony@att.com Alexey Melnikov wrote: > The IESG wrote: > >> The IESG has received a request from the Extensible Messaging and >> Presence Protocol WG to consider the following document: >> >> - 'XMPP Core ' >> as a Proposed Standard > > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. > > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) From owner-ietf-sasl Wed Oct 8 14:02:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L25KP068097 for ; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98L25rp068096 for ietf-sasl-bks; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L24KP068091 for ; Wed, 8 Oct 2003 14:02:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98L26lg082716; Wed, 8 Oct 2003 21:02:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 02:01:48 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: SASL WG In-Reply-To: <3F841823.6010502@isode.com> References: <3F841823.6010502@isode.com> 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: At 06:58 AM 10/8/2003, Alexey Melnikov wrote: >I have an impression that there are two many little things to change so that we will need a new Last Call anyway. >Is my perception correct? Yes. Given the large number of issues, I prefer to give you as fairly wide latitude to make the changes you believe are appropriate. Once a new I-D is ready, we'll then ask the WG to review the I-D to see consensus supports the changes made and the document as a whole. >If it is, I will issue a new revision shortly. Great! >Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): >1). IANA considerations and registering a familily of SASL mechanisms. You might look at BCP 64 (RFC 3383) guidelines for OID descriptors and families of OID descriptors as an example. >2). Clarification on replacing a security layer I would like to hear folks comments on the appropriateness of uninstalling layers after a failed subsequent exchange. >3). Realm I have not yet heard any arguments to keep the realm text. Kurt From owner-ietf-sasl Wed Oct 8 15:04:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4ZKP070106 for ; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98M4YaP070105 for ietf-sasl-bks; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4XKP070100 for ; Wed, 8 Oct 2003 15:04:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98M4Xlg083031; Wed, 8 Oct 2003 22:04:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009030341.02bc0108@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:04:16 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> 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: At 07:19 AM 10/8/2003, Jeffrey Hutzelman wrote: >>Would you rather reference the SASL WG as the Change Controller? > >No, especially since the SASL WG will likely conclude within the foreseeable future. The IESG should have change control mechanisms registered by Standards Action. Kurt From owner-ietf-sasl Wed Oct 8 16:14:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEKKP072462 for ; Wed, 8 Oct 2003 16:14:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NEKZN072458 for ietf-sasl-bks; Wed, 8 Oct 2003 16:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEIKP072453 for ; Wed, 8 Oct 2003 16:14:19 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NEETO017641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:14:17 -0400 (EDT) Message-ID: <3F849A43.6020508@columbia.edu> Date: Wed, 08 Oct 2003 19:14:11 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090408090503010507000209" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090408090503010507000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >To the IESG, > >I concur with Alexey's recent comments regarding XMPP's SASL >Profile. I have a few addition concerns regarding this profile. >The scope of my review was, due to time constraints, was limited >to the profile. > >I not sure why the documents says that SASL and TLS security >layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >but this recommendation is, I believe, flawed. There are numerous use >cases where implementations SHOULD establish additional layers. >For example, establishing additional SASL layers may prevent >certain kinds of tunneling man-in-the-middle attacks. > > The "security" is specific to the SASL encryption and integrity protection; not authentication. Clearly, SASL authentication might be used to help detect a man-in-the-middle attack. If you are arguing that SASL encryption/integrity protection should be used on top of TLS encryption/integrity protection, the only reason for doing so is that you do not trust the TLS encryption/integrity protection. I do not see where the man-in-the-middle attack would be coming from? >The requirement that initiating receiving entity drop all knowledge >it learned before negotiating SASL layers (rule 5) is too broad. >This could be viewed as requiring the implement to forget knowledge >it gained previously in a secure manner (such as an externally >established lower level (IPSEC or TLS) identity information). >Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are actively providing encryption/integrity protection. In this situation, it is known that TLS is not in use. I doubt it is known whether or not IPSec is in use for the entire communication path. Therefore, all information obtained prior to the establishment of encryption/integrity protection must be considered suspect. I believe the problem is one of language. Can we replace all references to "security layer" to read "data protection layer"? >I am also concerned by the use of the term "stream encryption" >in the document as this doesn't imply, in my eyes, "stream >integrity". It's unclear to me which imperatives imply when >encryption, integrity, and/or in combination with other security >services which TLS provides. > > I agree. We are not concerned with Stream Encryption but Data Protection. Replace "Stream Encryption" with "Data Protection" throughout. I have not completed a security review of these documents as yet. I am simply responding to Kurt's comments. Jeffrey Altman --------------ms090408090503010507000209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMTQxMVowIwYJKoZIhvcNAQkEMRYEFPSFDtAa4rTl gsvSQ23L6JnMGdqZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAJL99vPLNN9ZLX+NXMt5FZ6G8loGh zTc412pdHSq2PnQWkH/IRwbLb0riGgm1FIUPx85msJgIxHlbzuioX670UivRi5esVZJitT0H MMa6NtTc2+Mt391srr4T0QdhglgJUaZ0181nhm1dQzwNZmZ8A+JGWtbWqeceyg7axT2lOg32 rNFAiemS+i9C1kUiROICpXwjiqYg2qvXH2rV3ffKrYHfeTG9KWBZRWgqlcYDO2hMDQz+oa1b VknnzdTZXeiq7KgH2CJZMqfpuqYUPBudNSZ+ny9ojGxucpmuHkvxuG4+UApPCup8VBfVcO1e bJIzwCN9mbE7YEi3mPCCqeFYLQAAAAAAAA== --------------ms090408090503010507000209-- From owner-ietf-sasl Wed Oct 8 16:09:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9rKP072180 for ; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98N9rG4072179 for ietf-sasl-bks; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9qKP072174 for ; Wed, 8 Oct 2003 16:09:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98N9qlg083607; Wed, 8 Oct 2003 23:09:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:41:49 -0700 To: EKR From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> 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: At 01:28 PM 10/8/2003, Eric Rescorla wrote: >"Kurt D. Zeilenga" writes: >> I concur with Alexey's recent comments regarding XMPP's SASL >> Profile. I have a few addition concerns regarding this profile. >> The scope of my review was, due to time constraints, was limited >> to the profile. >> >> I not sure why the documents says that SASL and TLS security >> layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >> but this recommendation is, I believe, flawed. There are numerous use >> cases where implementations SHOULD establish additional layers. >> For example, establishing additional SASL layers may prevent >> certain kinds of tunneling man-in-the-middle attacks. >Could you describe some of them? XMPP's TLS profile allows establishment of TLS even though the implementation's certificate verification has failed: If the above methods fail, the certificate SHOULD be presented to a human (e.g., an end user or server administrator) for approval; if presented, the receiver MUST deliver the entire certificate chain to the human, who SHOULD be given the option to store the Root CA certificate (not the service or End Entity certificate) and to not be queried again regarding acceptance of the certificate for some reasonable period of time. Given the likelihood that the end user will inappropriately accept the certificate, attackers can easily insert a TLS-protected machine in the middle. Given this, it is quite reasonable for implementors to offer (and deployers to demand) additional safeguards. Kurt From owner-ietf-sasl Wed Oct 8 16:37:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbmKP073194 for ; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NbmRc073193 for ietf-sasl-bks; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbkKP073181 for ; Wed, 8 Oct 2003 16:37:47 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NbegG021882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:37:44 -0400 (EDT) Message-ID: <3F849FC1.1080104@columbia.edu> Date: Wed, 08 Oct 2003 19:37:37 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600070607010700010909" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050600070607010700010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 01:28 PM 10/8/2003, Eric Rescorla wrote: > > >>"Kurt D. Zeilenga" writes: >> >> >>>I concur with Alexey's recent comments regarding XMPP's SASL >>>Profile. I have a few addition concerns regarding this profile. >>>The scope of my review was, due to time constraints, was limited >>>to the profile. >>> >>>I not sure why the documents says that SASL and TLS security >>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>but this recommendation is, I believe, flawed. There are numerous use >>>cases where implementations SHOULD establish additional layers. >>>For example, establishing additional SASL layers may prevent >>>certain kinds of tunneling man-in-the-middle attacks. >>> >>> >>Could you describe some of them? >> >> > >XMPP's TLS profile allows establishment of TLS even though the >implementation's certificate verification has failed: > If the above methods fail, the certificate SHOULD be presented > to a human (e.g., an end user or server administrator) for > approval; if presented, the receiver MUST deliver the entire > certificate chain to the human, who SHOULD be given the option > to store the Root CA certificate (not the service or End Entity > certificate) and to not be queried again regarding acceptance of > the certificate for some reasonable period of time. > >Given the likelihood that the end user will inappropriately >accept the certificate, attackers can easily insert a >TLS-protected machine in the middle. Given this, it is quite >reasonable for implementors to offer (and deployers to demand) >additional safeguards. > >Kurt > > If the policy requirement of the deployers is to not accept the risk that the end user will accept certificate chains which cannot be verified by algorithmic means, then the policy should fail the certificate validation without presenting the certificates to the end user. The TLS session at that point must be aborted. At this point the TCP session must be closed. When XMPP attempts to reconnect, it must not attempt to establish a TLS session and in turn must attempt to negotiate a SASL mechanism which provides encryption/integrity protection. There is zero benefit to negotiating both TLS and SASL encryption/integrity protection. Btw, if it is possible for SASL to validate the TLS Client and Server Finished messages as computed by both the client and server, this can be performed during SASL authentication to detect a man-in-the-middle attack. This is the process which is used in TELNET START-TLS when combined with TELNET AUTH. Jeffrey Altman --------------ms050600070607010700010909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMzczN1owIwYJKoZIhvcNAQkEMRYEFL7qB6VLKFhA xcvIVRWzNb7OwJiYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAnbQCkWQGl0WeHwIi1zvOG7Gx2LK0 ITzK27cRdxMy9nvy5ZRMW8oYxUNoMghWjAqwvsMnoBFkeUUnqCajwU/KCcAasU7liZAus95p i4pAt8ja4O0+i8YimxPJCW1AryYsTXHdZJOD8ejXrQEOpCd6ZoTWnBjC1YWsWqg+ru4VI+ip M1oLJ+97Xs0F7EAoTP92Bjmog47ugTVtMsGvHcWFqWZk7kes5jsIKNrdjRqQKDtcgiCC+84T XtnAL05PH1JgG953sq8ABwtddTCwG6uzJlsPv5tiZxTI7HwBzhHhOjesSTYh9BushM9KTDeM nIiXLVE/XvBpjhV7Fwa+woXzqAAAAAAAAA== --------------ms050600070607010700010909-- From owner-ietf-sasl Wed Oct 8 17:25:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990PAKP074524 for ; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990PAcl074523 for ietf-sasl-bks; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990P8KP074518 for ; Wed, 8 Oct 2003 17:25:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h990P1lg084317; Thu, 9 Oct 2003 00:25:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008172120.03d58f10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 17:24:30 -0700 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: <3F849FC1.1080104@columbia.edu> References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> <3F849FC1.1080104@columbia.edu> 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: At 04:37 PM 10/8/2003, Jeffrey Altman wrote: >Kurt D. Zeilenga wrote: > >>At 01:28 PM 10/8/2003, Eric Rescorla wrote: >> >> >>>"Kurt D. Zeilenga" writes: >>> >>> >>>>I concur with Alexey's recent comments regarding XMPP's SASL >>>>Profile. I have a few addition concerns regarding this profile. >>>>The scope of my review was, due to time constraints, was limited >>>>to the profile. >>>> >>>>I not sure why the documents says that SASL and TLS security >>>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>>but this recommendation is, I believe, flawed. There are numerous use >>>>cases where implementations SHOULD establish additional layers. >>>>For example, establishing additional SASL layers may prevent >>>>certain kinds of tunneling man-in-the-middle attacks. >>>> >>>Could you describe some of them? >>> >> >>XMPP's TLS profile allows establishment of TLS even though the >>implementation's certificate verification has failed: >> If the above methods fail, the certificate SHOULD be presented >> to a human (e.g., an end user or server administrator) for >> approval; if presented, the receiver MUST deliver the entire >> certificate chain to the human, who SHOULD be given the option >> to store the Root CA certificate (not the service or End Entity >> certificate) and to not be queried again regarding acceptance of >> the certificate for some reasonable period of time. >> >>Given the likelihood that the end user will inappropriately >>accept the certificate, attackers can easily insert a >>TLS-protected machine in the middle. Given this, it is quite >>reasonable for implementors to offer (and deployers to demand) >>additional safeguards. >> >>Kurt >If the policy requirement of the deployers is to not accept the risk >that the end user will accept certificate chains which cannot be verified >by algorithmic means, The policy might be to mitigate the risk that users won't do the appropriate checks by requiring an additional layer of security. >There is zero benefit to negotiating both TLS and SASL encryption/integrity >protection. I disagree. Multiple layer defenses have benefits. Kurt From owner-ietf-sasl Wed Oct 8 17:47:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990lmKP075378 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990lmFa075377 for ietf-sasl-bks; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990llKP075371 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D663F151D9B; Wed, 8 Oct 2003 20:47:49 -0400 (EDT) To: xmppwg@jabber.org Cc: "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> From: Sam Hartman Date: Wed, 08 Oct 2003 20:47:49 -0400 In-Reply-To: <3F849A43.6020508@columbia.edu> (Jeffrey Altman's message of "Wed, 08 Oct 2003 19:14:11 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: Do we actually need to have this argument here? I tend to agree with Kurt but it's not clear that having this discussion will actually influence the draft. Jeff, do you see anything wrong with allowing a SASL security layer and TLS to be used in conjunction? If I'm reading your argument right, you have not actually presented any argument against this configuration, you have just argued that Kurt's reason for wanting to do so is not correct. From owner-ietf-sasl Wed Oct 8 20:40:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993euKP080566 for ; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h993eudj080565 for ietf-sasl-bks; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993etKP080554 for ; Wed, 8 Oct 2003 20:40:55 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 20:49:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h993ejXg001235; Wed, 8 Oct 2003 20:40:46 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 20:45:24 -0700 From: "Joseph Salowey" To: "'EKR'" , Cc: , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 20:40:43 -0700 Message-ID: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 03:45:24.0730 (UTC) FILETIME=[C59D05A0:01C38E17] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 1:28 PM > To: xmppwg@jabber.org > Cc: iesg@ietf.org; SASL WG > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > "Kurt D. Zeilenga" writes: > > I concur with Alexey's recent comments regarding XMPP's > SASL Profile. > > I have a few addition concerns regarding this profile. The > scope of my > > review was, due to time constraints, was limited to the profile. > > > > I not sure why the documents says that SASL and TLS security layers > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this > > recommendation is, I believe, flawed. There are numerous use cases > > where implementations SHOULD establish additional layers. > For example, > > establishing additional SASL layers may prevent certain kinds of > > tunneling man-in-the-middle attacks. > Could you describe some of them? > If the TLS tunnel is only server authenticated and the client supports a particular SASL method (perhaps even in a different protocol)that provides mutual authentication both inside and outside a TLS tunnel there is a vulnerability. In this case if only the message protection of TLS is used you cannot be sure that the client endpoint of the TLS tunnel is the same client endpoint that the server authenticated with SASL. To mitigate this problem you can: - Use the protection from the inner SASL method - Have the SASL authentication mechanism authenticate the TLS Session ID or some similar parameter - Require different credentials be used by a SASL mechanism when operating inside or outside a TLS tunnel. Joe > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > From owner-ietf-sasl Wed Oct 8 21:13:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DVKP081670 for ; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994DVOc081669 for ietf-sasl-bks; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DUKP081664 for ; Wed, 8 Oct 2003 21:13:30 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 151AEAC09; Wed, 8 Oct 2003 21:20:35 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 21:20:35 -0700 In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > -----Original Message----- > > From: owner-ietf-sasl@mail.imc.org > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > Sent: Wednesday, October 08, 2003 1:28 PM > > To: xmppwg@jabber.org > > Cc: iesg@ietf.org; SASL WG > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > "Kurt D. Zeilenga" writes: > > > I concur with Alexey's recent comments regarding XMPP's > > SASL Profile. > > > I have a few addition concerns regarding this profile. The > > scope of my > > > review was, due to time constraints, was limited to the profile. > > > > > > I not sure why the documents says that SASL and TLS security layers > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > but this > > > recommendation is, I believe, flawed. There are numerous use cases > > > where implementations SHOULD establish additional layers. > > For example, > > > establishing additional SASL layers may prevent certain kinds of > > > tunneling man-in-the-middle attacks. > > Could you describe some of them? > > > > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. How's that again? Please explain the network topology you're considering here. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 22:10:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995ARKP084945 for ; Wed, 8 Oct 2003 22:10:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995AQCr084944 for ietf-sasl-bks; Wed, 8 Oct 2003 22:10:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995APKP084936 for ; Wed, 8 Oct 2003 22:10:25 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h995AAHU013767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 01:10:16 -0400 (EDT) Message-ID: <3F84EDAE.1060801@columbia.edu> Date: Thu, 09 Oct 2003 01:10:06 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey CC: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060502010409050807070001" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060502010409050807070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > >Ok. I might be misunderstanding something, here is a summary: > >A client C that is willing to use SASL mechanism X both inside and >outside a TLS tunnel. >A server S that supports a server authenticated TLS tunnel and then >authenticates the client using SASL mechanism X within the tunnel. >An attacker M who can act as a TLS client and a SASL server for >mechanism X. > >The network topology/deployment must allow for M to trick C into trying >to authenticate to him using SASL Mechanism X (without TLS) while M >simultaneously establishes a TLS connection with S. > >M establishes a TLS session with S >M tricks C into trying to authenticate to him using SASL mechanism X >without TLS protection (these first steps could happen in the reverse >order) >M forwards the SASL exchange from C to S and vice versa. >The SASL authentication will succeed and S will believe that the >endpoint of the TLS tunnel is C instead of M (For some mechanisms M may >have to spoof S's address in order for the authentication to complete). >M can disconnect from C and continue sending messages to S. >S thinks the messages from M originate from C. > >Joe > > > As far as I am aware, the endpoints negotiating the TLS tunnel are identical to endpoints negotiating SASL. Both TLS and SASL are negotiated as part of the same connect/accept operation. Jeffrey Altman --------------ms060502010409050807070001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTA1MTAwNlowIwYJKoZIhvcNAQkEMRYEFO1axPFRmWNP 67RIy8XDMKetb+FYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEADXQ1FtqhFe5OdSd/cDovPQGISHaw BLzXgvYSVukAr/0cgPQJJxMdLnR0GGyH52tV30C7C1cTL7KKAZ4RXtrhejAIUQzshGbBkCa8 wCqMV7nFKEX92ETM1BLM40FF5DEjs9f3BBgCedi9yDHuKte9XVniF7NkOVZ9sUZ3uqmrzKGO vTk70+sDgyCcL+qMrA+iXdaQJqhVZc3LXS0BsqsQ+MNvOPn4NfGjjmaLXM/Gh8k8/32cq2HL Wu5kPgOE9w4bKD5/Zb+wdy4zd8oJgG+wM940Nx3OBvBd9D+nfwaBNMqqDE6N210vzAb9+MW0 4gW8gFmh+G1Zl61qVK4tJDoZTgAAAAAAAA== --------------ms060502010409050807070001-- From owner-ietf-sasl Wed Oct 8 21:53:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rdKP082836 for ; Wed, 8 Oct 2003 21:53:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994rc4k082835 for ietf-sasl-bks; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rcKP082829 for ; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:01:43 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h994rXJs005754; Wed, 8 Oct 2003 21:53:33 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 21:58:12 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 21:53:32 -0700 Message-ID: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 04:58:12.0976 (UTC) FILETIME=[F14A7700:01C38E21] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 9:21 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > > -----Original Message----- > > > From: owner-ietf-sasl@mail.imc.org > > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > > Sent: Wednesday, October 08, 2003 1:28 PM > > > To: xmppwg@jabber.org > > > Cc: iesg@ietf.org; SASL WG > > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > > > > > "Kurt D. Zeilenga" writes: > > > > I concur with Alexey's recent comments regarding XMPP's > > > SASL Profile. > > > > I have a few addition concerns regarding this profile. The > > > scope of my > > > > review was, due to time constraints, was limited to the profile. > > > > > > > > I not sure why the documents says that SASL and TLS security > > > > layers > > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > > but this > > > > recommendation is, I believe, flawed. There are numerous use > > > > cases > > > > where implementations SHOULD establish additional layers. > > > For example, > > > > establishing additional SASL layers may prevent certain kinds of > > > > tunneling man-in-the-middle attacks. > > > Could you describe some of them? > > > > > > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > How's that again? Please explain the network topology you're > considering here. > Ok. I might be misunderstanding something, here is a summary: A client C that is willing to use SASL mechanism X both inside and outside a TLS tunnel. A server S that supports a server authenticated TLS tunnel and then authenticates the client using SASL mechanism X within the tunnel. An attacker M who can act as a TLS client and a SASL server for mechanism X. The network topology/deployment must allow for M to trick C into trying to authenticate to him using SASL Mechanism X (without TLS) while M simultaneously establishes a TLS connection with S. M establishes a TLS session with S M tricks C into trying to authenticate to him using SASL mechanism X without TLS protection (these first steps could happen in the reverse order) M forwards the SASL exchange from C to S and vice versa. The SASL authentication will succeed and S will believe that the endpoint of the TLS tunnel is C instead of M (For some mechanisms M may have to spoof S's address in order for the authentication to complete). M can disconnect from C and continue sending messages to S. S thinks the messages from M originate from C. Joe From owner-ietf-sasl Wed Oct 8 22:09:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959NKP084730 for ; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9959Nlx084729 for ietf-sasl-bks; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959MKP084719 for ; Wed, 8 Oct 2003 22:09:22 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 22:16:31 -0700 In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 22:19:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JtKP086958 for ; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995Jtea086956 for ietf-sasl-bks; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JsKP086904 for ; Wed, 8 Oct 2003 22:19:54 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:28:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h995JncZ023880; Wed, 8 Oct 2003 22:19:49 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 22:24:28 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 22:19:47 -0700 Message-ID: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 05:24:28.0752 (UTC) FILETIME=[9C86CD00:01C38E25] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 10:17 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > How's that again? Please explain the network topology you're > > > considering here. > > > > > > > Ok. I might be misunderstanding something, here is a summary: > > > > A client C that is willing to use SASL mechanism X both inside and > > outside a TLS tunnel. A server S that supports a server > authenticated > > TLS tunnel and then authenticates the client using SASL mechanism X > > within the tunnel. An attacker M who can act as a TLS client and a > > SASL server for mechanism X. > > > > The network topology/deployment must allow for M to trick C into > > trying to authenticate to him using SASL Mechanism X (without TLS) > > while M simultaneously establishes a TLS connection with S. > > > > M establishes a TLS session with S > > M tricks C into trying to authenticate to him using SASL mechanism X > > without TLS protection (these first steps could happen in > the reverse > > order) > > M forwards the SASL exchange from C to S and vice versa. > > The SASL authentication will succeed and S will believe that the > > endpoint of the TLS tunnel is C instead of M (For some > mechanisms M may > > have to spoof S's address in order for the authentication > to complete). > > M can disconnect from C and continue sending messages to S. > > S thinks the messages from M originate from C. > > Yes, this will work. But here's the thing: > > This only works if the client would have been prepared to do > this weak mechanism over a non-TLS connection. Generally the > client knows when it expects to do TLS and when it doesn't. > Agreed. If the client only uses this mechanism over TLS then this is not a problem. How easy this is to enforce depends upon the deployment environment, it may be reasonable to assume for XMPP (I'm not very familiar with XMPP). I'm not completely sure, but with some mechanisms using the same mechanism without TLS in a different protocol may lead to the same problem (If the mechanism does not authenticate the protocol/service context). Joe From owner-ietf-sasl Wed Oct 8 23:24:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OvKP009626 for ; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h996OvRV009624 for ietf-sasl-bks; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OsKP009606 for ; Wed, 8 Oct 2003 23:24:56 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h996OaMV011034; Wed, 8 Oct 2003 23:24:36 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id h996PrH25214; Wed, 8 Oct 2003 23:25:53 -0700 (PDT) Message-Id: <200310090625.h996PrH25214@katroo.Sendmail.COM> To: "Joseph Salowey" From: Philip Guenther Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard In-reply-to: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> References: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> Date: Wed, 08 Oct 2003 23:22:20 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: >> -----Original Message----- >> From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On ... >> This only works if the client would have been prepared to do >> this weak mechanism over a non-TLS connection. Generally the >> client knows when it expects to do TLS and when it doesn't. > >Agreed. If the client only uses this mechanism over TLS then this is >not a problem. How easy this is to enforce depends upon the deployment >environment, it may be reasonable to assume for XMPP (I'm not very >familiar with XMPP). I'm not completely sure, but with some mechanisms >using the same mechanism without TLS in a different protocol may lead to >the same problem (If the mechanism does not authenticate the >protocol/service context). For those who don't watch the ietf-announce list or didn't have their interest perked by the announcement, a discussion of this problem in the context of EAP can be found in: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt The Compound Authentication Binding Problem ... Abstract There are several motivations for using compound authentication methods using tunnels, but man-in-the-middle attacks are possible in certain circumstances when they are used, without cryptographically binding the methods together. At the time of writing this document, several protocols being proposed within the IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP. This document studies the problems and suggests potential solutions to mitigate them. (I have nothing to do with this document; it just seems extremely relevant and fairly thorough on the point under discussion. Perhaps SASL over TLS should be added to the list in the quoted abstract?) Philip Guenther guenther@sendmail.com From owner-ietf-sasl Thu Oct 9 02:51:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p8KP057701 for ; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h999p8l1057700 for ietf-sasl-bks; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p2KP057689 for ; Thu, 9 Oct 2003 02:51:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 10:50:55 +0100 Message-ID: <3F852F7D.7030206@isode.com> Date: Thu, 09 Oct 2003 10:50:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> Content-Type: multipart/alternative; boundary="------------030505020004070308000607" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030505020004070308000607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>2). Clarification on replacing a security layer >> >> > >I would like to hear folks comments on the appropriateness of >uninstalling layers after a failed subsequent exchange. > This is not the issue. What you are talking about violates SASL spec. The issues is whether to keep the old security layer or remove it a). in protocols that allow for reauthentication (e.g. LDAP and HTTP) b). after a second or subsequent successful reauthentication. Alexey --------------030505020004070308000607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
2). Clarification on replacing a security layer
    

I would like to hear folks comments on the appropriateness of
uninstalling layers after a failed subsequent exchange.
This is not the issue. What you are talking about violates SASL spec.

The issues is whether to keep the old security layer or remove it
a). in protocols that allow for reauthentication (e.g. LDAP and HTTP)
b). after a second or subsequent successful reauthentication.

Alexey

--------------030505020004070308000607-- From owner-ietf-sasl Thu Oct 9 03:36:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaLKP060119 for ; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99AaLRu060118 for ietf-sasl-bks; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaIKP060113 for ; Thu, 9 Oct 2003 03:36:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 11:35:31 +0100 Message-ID: <3F8539F1.3020106@isode.com> Date: Thu, 09 Oct 2003 11:35:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman CC: xmppwg@jabber.org, "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> In-Reply-To: <3F849A43.6020508@columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Altman wrote: >> The requirement that initiating receiving entity drop all knowledge >> it learned before negotiating SASL layers (rule 5) is too broad. >> This could be viewed as requiring the implement to forget knowledge >> it gained previously in a secure manner (such as an externally >> established lower level (IPSEC or TLS) identity information). >> Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are > actively providing encryption/integrity protection. In this > situation, it is known that TLS is not in use. I doubt it is known > whether or not IPSec is in use for the entire communication path. > Therefore, all information obtained prior to the establishment of > encryption/integrity protection must be considered suspect. > > I believe the problem is one of language. Can we replace all > references to "security layer" to read "data protection layer"? "security layer" is a SASL term, so changing it to something else will cause additional confusion. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Thu Oct 9 07:34:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYsKP069730 for ; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYsZQ069729 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKQ069717 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:36 +0100 Message-ID: <3F848CD6.9010804@isode.com> Date: Wed, 08 Oct 2003 23:16:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: SASL WG Subject: Replacing a SASL security layer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>> Below the term "realm" has the meaning as defined in the section 5. >>> A security layer that remains in effect when a client, which already >>> has authenticated and established the security layer with "Realm A", >>> authenticates to "Realm B", without negotiating a new security layer, >>> enables "Realm B" to make guesses about previously observed >>> ciphertext using the server's SASL engine as an oracle. "Realm B" may >>> observe how known cleartext is encrypted. >>> >>> +---------+ +---------+ >>> | | | | >>> | Realm B | | Realm A | >>> | | | | >>> +---------+ +---------+ >>> | ^ | >>> | : +-----------+ | >>> Traffic from | : | Encryption| | Traffic from A >>> B to client +-------->| end point |<-------+ to client >>> : | (SSL/SASL)| >>> : +-----------+ >>> : | >>> : | >>> : +---+ >>> : | | >>> : | | >>> : | | Encryption tunnel, e.g. SASL or >>> SSL, >>> : | | between the server >> >>> encrypted | | Separate tunnels to different >>> traffic between | | clients. >>> Realm A and client +---+ >>> | >>> | >>> +-----------> Traffic to clients >> > > This discussion is confusing and makes no sense to me. SASL doesn't > protect traffic between "realms" and clients; it protects traffic > between _servers_ and clients. This needs to be reworded so it makes > sense, in terms of entities known to the SASL framework. A "realm" is > not such an entity; it is no more than part of the autentication > identities used by some mechanisms, and has no place outside the > mechainsm specification. > > Put another way, and ignoring the issue of "realms"; the above > description makes so little sense to me that I cannot evaluate its > validity or understand what attack we are trying to avoid. Ignore for a moment any relationship of realm to DIGEST-MD5, GSSAPI or any other SASL mechanism. Let's use the definition I have in the document: Conceptually, realm is the name of a collection of user's accounts. Realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication mechanisms and/or authorization database. For example, a proxy/frontend can use different realms for different servers/backends it represents. So, each "realm" ("a protection space") is served by a separate server (proxy example above) or a separate process/plugin (frontend-backend example). Does it make more sense now? Alexey From owner-ietf-sasl Thu Oct 9 07:34:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYrKP069723 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYra7069722 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKP069717 for ; Thu, 9 Oct 2003 07:34:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:35 +0100 Message-ID: <3F848A1A.6020006@isode.com> Date: Wed, 08 Oct 2003 23:05:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , Jeffrey Hutzelman , Hallvard B Furuseth CC: SASL WG Subject: SASL Realms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. (...) The realm value is a case- >> insensitive string, generally assigned by the origin server, which >> >> > It seems to me it is not rfc2222bis' business to define realms as > case-insensitive. The mechanism definitions can do that. I think > rfc2222bis should only say that it usually is case-insensitive, or > maybe say that it "SHOULD" be. As it is, a mechanism can define a > "case- sensitive realm" if it wants to anyway, provided it confuses > the issue by calling it something else than a "realm". Kurt D. Zeilenga wrote: >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. >> >> > >I think this SHOULD is not appropriate. First, interoperability is >not harmed by protocol profiles not providing such guidance. Secondly, >realms should be viewed as part of multi-component authentication >identity form. That is, in DIGEST-MD5, the authentication identity >is composed of two parts, the user's name (username) and the user's >realm (realm). Having profiles overload the semantics of the >any component of the authentication identity breaks the separation >of mechanism and profile. > > Jeffrey Hutzelman wrote: >>> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >>> of realm. >> >> >> I think it unwise to enter into a discussion of realms here. >> Realm syntax and semantics are, for mechanisms which have realms, >> mechanism specific. The mechanism specification should state how >> they are to be compared. The mechanism specification should state >> how they are to constructed and used in the mechanism and, where >> appropriate, state any protocol profiling requirements. (Note: >> I'd likely doubt any mechanism attempt to state protocol profiling >> requirements as this breaks SASL's separation of profile and >> mechanism). > > I agree. A realm is just part of the authentication identities used > by certain mechanisms. It is mechanism-specific, and a discussion of > realms is irrelevant to protocol profiling. Ok, the reason why I've added this text in the first place is because a lot of protocol implementors misunderstand what the realm is and is not. Unfortunately the original text in the DIGEST-MD5 document is too vague to be useful. Recent discussion on LDAP mailing list proves this. I was trying to clarify this, but your are right that the text doesn't belong to the base SASL specification. I will be adding a section to DIGEST-MD5 that tries to give some examples of realm usage. >>> A protocol profile SHOULD provide a guidance how realms are to be >>> constructed and used in the protocol and MAY further restrict its >>> syntax and protocol-specific semantics. >> > Absolutely not. Protocols may decide to include some concept of realm > in their authorization identities, but they have no business > whatsoever defining the semantics of authentication identities. That > is the responsibility of the mechanism. Alexey From owner-ietf-sasl Thu Oct 9 08:09:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9CKP070984 for ; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99F9CC1070983 for ietf-sasl-bks; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9BKP070976 for ; Thu, 9 Oct 2003 08:09:11 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99F8SVo025764; Thu, 9 Oct 2003 08:08:28 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99F8R2o010016; Thu, 9 Oct 2003 09:08:27 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99F4WQx021341; Thu, 9 Oct 2003 08:04:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99F4UFL021340; Thu, 9 Oct 2003 08:04:30 -0700 (PDT) Date: Thu, 9 Oct 2003 08:04:30 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009150430.GD17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. > > To mitigate this problem you can: > > - Use the protection from the inner SASL method > - Have the SASL authentication mechanism authenticate the TLS Session ID > or some similar parameter > - Require different credentials be used by a SASL mechanism when > operating inside or outside a TLS tunnel. Why does this sound really familiar? Ah, because one solution is to "bind" one layer (SASL) to the key exchange and negotiation of the other (TLS) to prove that there's no MITM at the lower layer (TLS) - which, of course, relies on an MITM's inability to make the key exchange/nego look the same on both side of the lower layer channel. In the GSS-API we call this channel bindings. Perhaps SASL should have The second solution you give is an attempt at doing just this sort of binding. Unfortunately, a TLS MITM can make the TLS session ID be the same on both sides of the tunnel - that's because in TLS the server assigns the session ID which, in turn, is not bound or required to be bound in any way to the TLS key exchange / negotiation. So you can't use TLS session IDs as channel bindings. Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 08:37:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FboKP072070 for ; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FboXr072069 for ietf-sasl-bks; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FbnKP072063 for ; Thu, 9 Oct 2003 08:37:49 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 08:38:44 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h99FbcYb003490; Thu, 9 Oct 2003 08:37:39 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Oct 2003 08:42:18 -0700 From: "Joseph Salowey" To: "'Nicolas Williams'" Cc: "'EKR'" , , , "'SASL WG'" Subject: RE: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Date: Thu, 9 Oct 2003 08:37:37 -0700 Message-ID: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 15:42:18.0614 (UTC) FILETIME=[EBE2D960:01C38E7B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Thursday, October 09, 2003 8:05 AM > To: Joseph Salowey > Cc: 'EKR'; xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: SASL channel bindings (was Re: [xmppwg] Last Call: > 'XMPP Core' to Proposed Standard) > > > On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > > > To mitigate this problem you can: > > > > - Use the protection from the inner SASL method > > - Have the SASL authentication mechanism authenticate the > TLS Session > > ID or some similar parameter > > - Require different credentials be used by a SASL mechanism when > > operating inside or outside a TLS tunnel. > > Why does this sound really familiar? Ah, because one > solution is to "bind" one layer (SASL) to the key exchange > and negotiation of the other > (TLS) to prove that there's no MITM at the lower layer (TLS) > - which, of course, relies on an MITM's inability to make the > key exchange/nego look the same on both side of the lower > layer channel. [Joe] Yes, this is all too familiar > > In the GSS-API we call this channel bindings. Perhaps SASL > should have > > The second solution you give is an attempt at doing just this > sort of binding. > > Unfortunately, a TLS MITM can make the TLS session ID be the > same on both sides of the tunnel - that's because in TLS the > server assigns the session ID which, in turn, is not bound or > required to be bound in any way to the TLS key exchange / > negotiation. So you can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice (although in would probably work in the case outlined, it will fail if the attacker can trick the client into accepting it as a valid TLS endpoint, but this is a different problem). In any case SASL might benefit from channel bindings, although one has to be careful with channel bindings (for example binding to addresses tends to cause problems). Maybe it is possible to temporarily turn on SASL integrity services to authenticate binding information. I don't think that SASL intends for the security layer to be removed after it starts, but I didn't find a place in the draft where it explicitly forbids it. If it is allowed then applications which negotiate TLS can use this binding technique. > Cheers, > > Nico > -- > From owner-ietf-sasl Thu Oct 9 08:44:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiWKP072767 for ; Thu, 9 Oct 2003 08:44:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FiVDM072766 for ietf-sasl-bks; Thu, 9 Oct 2003 08:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiUKP072760 for ; Thu, 9 Oct 2003 08:44:30 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99FiCHU024300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 11:44:14 -0400 (EDT) Message-ID: <3F85824A.5050806@columbia.edu> Date: Thu, 09 Oct 2003 11:44:10 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000703080003050300080103" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000703080003050300080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > >>If the TLS tunnel is only server authenticated and the client supports a >>particular SASL method (perhaps even in a different protocol)that >>provides mutual authentication both inside and outside a TLS tunnel >>there is a vulnerability. In this case if only the message protection >>of TLS is used you cannot be sure that the client endpoint of the TLS >>tunnel is the same client endpoint that the server authenticated with >>SASL. >> >>To mitigate this problem you can: >> >>- Use the protection from the inner SASL method >>- Have the SASL authentication mechanism authenticate the TLS Session ID >>or some similar parameter >>- Require different credentials be used by a SASL mechanism when >>operating inside or outside a TLS tunnel. >> >> > >Why does this sound really familiar? Ah, because one solution is to >"bind" one layer (SASL) to the key exchange and negotiation of the other >(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of >course, relies on an MITM's inability to make the key exchange/nego look >the same on both side of the lower layer channel. > >In the GSS-API we call this channel bindings. Perhaps SASL should have > >The second solution you give is an attempt at doing just this sort of >binding. > >Unfortunately, a TLS MITM can make the TLS session ID be the same on >both sides of the tunnel - that's because in TLS the server assigns the >session ID which, in turn, is not bound or required to be bound in any >way to the TLS key exchange / negotiation. So you can't use TLS session >IDs as channel bindings. > >Cheers, > >Nico > > The channel binding would be made utilizing the TLS Client and Server Finished Messages. If both the client and server concatenate those messages in a well defined order, they can then attempt to verify that both the client and server have the same bytes. This is how TELNET AUTH binds to TLS when STARTTLS is used. The benefit of this is that we would get mutual authentication from SASL which would allow TLS to be used in anonymous-DH mode completely removing the need to have or validate X.509 certificates. Unfortunately, SASL does not have this functionality at the current time. I very much think it should. If it did, this entire discussion of the use of SASL Security Layers on top of TLS could just go away. I completely understand why the SASL folks want to be able to use a SASL Security Layer on top of TLS when they do not have the ability to bind to lower layers. Unfortunately, if SASL Security Layers are always to be used then I believe that TLS should never be negotiated. To do so adds nothing to the strength of the security of the session, increases the complexity, wastes CPU cycles, and spreads FUD regarding the trustworthiness of TLS. The lack of trust is not caused by TLS, but by the inability of SASL to verify a previously known shared secret between two parties. Jeffrey Altman Jeffrey Altman --------------ms000703080003050300080103 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTE1NDQxMFowIwYJKoZIhvcNAQkEMRYEFD2f/UNQ//7B jVMPyxGXkRLLUiiFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAv64q4pAT7kLCPtc/XIZuvm9jPAZ5 I792NJQ4KNAMn6BNdU1VGVm3ViBfqPRc7GqFo34dojUmhqxVj3epCWIVccmLQZeRsAWE/u46 eq/KF965kuSCsflGLFIWjGJWGK+e5hUtGSGTrzkeHVcWDxXkeobEtn393sdAwSq2tOj8N8Ef VHVOf6JWd76GWpGvOW4bk/NWAQg40BU2IWxrlc/e5uHht+ki+0UGJxqJyaVJpom6WpU2CQhq Mb74UgCxM4Z4nTI2rTfEgKwjMAsiMbXd3WCRspazsBmc0xpziVqAdL9fwDk4BZSePWwhYBal 0lD91cM4x9tHcsVXPtMpXPBopQAAAAAAAA== --------------ms000703080003050300080103-- From owner-ietf-sasl Thu Oct 9 09:19:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074402 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GJZlr074401 for ietf-sasl-bks; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074396 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99GIqVo006146; Thu, 9 Oct 2003 09:18:52 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GIp58014068; Thu, 9 Oct 2003 10:18:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GEuQx021373; Thu, 9 Oct 2003 09:14:56 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GEtZZ021372; Thu, 9 Oct 2003 09:14:55 -0700 (PDT) Date: Thu, 9 Oct 2003 09:14:55 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009161455.GF17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <20031009150430.GD17088@binky.central.sun.com> <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote: Nico> Why does this sound really familiar? Ah, because one solution is Nico> to "bind" one layer (SASL) to the key exchange and negotiation of Nico> the other (TLS) to prove that there's no MITM at the lower layer Nico> (TLS) - which, of course, relies on an MITM's inability to make Nico> the key exchange/nego look the same on both side of the lower Nico> layer channel. > [Joe] Yes, this is all too familiar > > > Nico> In the GSS-API we call this channel bindings. Perhaps SASL should Nico> have [I meant to say "Perhaps SASL should have a channel bindings facility."] Nico> Unfortunately, a TLS MITM can make the TLS session ID be the same Nico> on both sides of the tunnel - that's because in TLS the server Nico> assigns the session ID which, in turn, is not bound or required to Nico> be bound in any way to the TLS key exchange / negotiation. So you Nico> can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice > (although in would probably work in the case outlined, it will fail if > the attacker can trick the client into accepting it as a valid TLS > endpoint, but this is a different problem). > > In any case SASL might benefit from channel bindings, although one has > to be careful with channel bindings (for example binding to addresses > tends to cause problems). Maybe it is possible to temporarily turn on > SASL integrity services to authenticate binding information. I don't > think that SASL intends for the security layer to be removed after it > starts, but I didn't find a place in the draft where it explicitly > forbids it. If it is allowed then applications which negotiate TLS can > use this binding technique. It's probably not possible to add a channel bindings facility to SASL at this point, but it should be possible to describe how applications should do channel binding with SASL, more or less as you describe. And as you point out, the traditional use of GSS-API channel bindings to bind to network addresses causes problems, and, I might add, isn't really secure. Therefore we need to generally address channel bindings for the channels one might like to bind to: - What to use as channel bindings for SSHv2? Easy, the SSHv2 session ID! - What to use as channel bindings for TLS? TLS defines no suitable value. So one may have to be constructed (e.g., hash of all TLS session setup messages). - What to use as channel bindings for IKEv1 IPsec? Don't. IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding to the previous or original IKE_SA - so that when the IKE_SA expires so do the bindings. - What to use as channel bindings for IKEv2 IPsec? IKEv2 rekeying does bind the new SA to the previous one, so binding to IPsec SAs negotiated with IKEv2 is ok, but we need to define the what to use as the channel bindings. I've asked the IPSEC WG to define a value for use as channel bindings, but so far they are ignoring me. Ultimately, the same octets of which signatures are exchanged in the AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft) can be used as channel bindings, or, rather, a hash thereof. - What to use as channel bindings for Kerberos V-protected tunnels? Again, nothing useful for this is provided in RFC1510. But who wants this? :) Still something could be defined (e.g., a hash of the AP exchange messages). - What to use as channel bindings for GSS-API-protected tunnels? Same thing. I'd propose: the ret_flags of the context and a hash of the byte-wise concatenation of the context tokens used to initialize the context, in order. - What to use as channel bindings for SASL-protected tunnels? Again, same thing... Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 09:29:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GTpKP074978 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GTpid074977 for ietf-sasl-bks; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GToKP074969 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h99GT4X0024940; Thu, 9 Oct 2003 09:29:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GT42o017514; Thu, 9 Oct 2003 10:29:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GP8Qx021381; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GP8iN021380; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Date: Thu, 9 Oct 2003 09:25:07 -0700 From: Nicolas Williams To: Jeffrey Altman Cc: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009162507.GG17088@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> <3F85824A.5050806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F85824A.5050806@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 11:44:10AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > >The second solution you give is an attempt at doing just this sort of > >binding. > > > >Unfortunately, a TLS MITM can make the TLS session ID be the same on > >both sides of the tunnel - that's because in TLS the server assigns the > >session ID which, in turn, is not bound or required to be bound in any > >way to the TLS key exchange / negotiation. So you can't use TLS session > >IDs as channel bindings. > > The channel binding would be made utilizing the TLS Client and Server > Finished Messages. If both the client and server concatenate those > messages in a well defined order, they can then attempt to verify that > both the client and server have the same bytes. This is how TELNET AUTH > binds to TLS when STARTTLS is used. The benefit of this is that we > would get mutual authentication from SASL which would allow TLS to be > used in anonymous-DH mode completely removing the need to have or > validate X.509 certificates. Yeah - I offer as much in the post I just followed up with. This sort of thing is extremely valuable. The NFSv4 WG is quite interested in channel bindings as a way to offload session cryptographic protection from RPCSEC_GSS/GSS-API to IPsec and others. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt (The I-D will be updated soon, I hope, and will include much improved text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well nonces and an additional 1/2 round-trip for the CCM-* pseudo- mechanisms' context tokens so as to make their context tokens un-replayable independently of the underlying, real mechanisms' context tokens' replayability.) > Unfortunately, SASL does not have this functionality at the current > time. I very much think it should. If it did, this entire discussion > of the use of SASL Security Layers on top of TLS could just go away. The discussion of what to use as channel bindings to TLS would still have to be had, though you point out that TELNET already solves that particular problem in a way that others could leverage. But that still leaves other channels to discuss (e.g., IPsec) - see my other followup to Joe. > I completely understand why the SASL folks want to be able to use a SASL > Security Layer on top of TLS when they do not have the ability to bind > to lower layers. Unfortunately, if SASL Security Layers are always to > be used then I believe that TLS should never be negotiated. To do so > adds nothing to the strength of the security of the session, increases > the complexity, wastes CPU cycles, and spreads FUD regarding the > trustworthiness of TLS. The lack of trust is not caused by TLS, but by > the inability of SASL to verify a previously known shared secret between > two parties. I agree. But note that SASL doesn't have to "verify a previously ..." - it just has to verify a value, public or not, that could not be made the same for both parties by an MITM at the lower layer. Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 15:18:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIIZA094244 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99MIIG3094243 for ietf-sasl-bks; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from server.kniep.nl (node-c-9223.a2000.nl [62.194.146.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIFZA094229 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from dick@kniep.nl) Received: from server.kniep.nl (localhost [127.0.0.1]) by server.kniep.nl (Postfix) with ESMTP id 4055D3342F9 for ; Thu, 9 Oct 2003 18:22:10 -0400 (EDT) Subject: Sasl problems From: Dick Kniep To: SASL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Oct 2003 00:22:09 +0200 Message-Id: <1065738130.31142.2.camel@server.kniep.nl> Mime-Version: 1.0 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi List, This is my first post on the sasl list, I am no guru on SASl, so please be gentle. We have installed a Kolab server (groupware with Sasl, postfix, cyrus imap etc.) Install went smoothly, but we cannot log on. I have posted to the kolab mailinglist, but got no answer whatsoever. So, next is my original post to the kolab mailinglist. If anyone can help, please do so. Since the original occurrance of the error, I have tried to remove the user 'dick' completely from the system, defining it again etc. All to no avail. ++++ Original message to Kolab mailinglist ++++ We have a strange phenomenon where we cannot get access to the server. We have entered a userid in the management module. This works OK (or so it seems) Next we try to login, but then we get a message that the userid is not authorized. The password is correct. When we look in the logs of SASL the following messages are shown: -------------------------- Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth failure: [user=dick] [service=imap] [realm=] [mech=ldap] -------------------------- It says that there are more definitions of the user 'dick'. If that is the case how can we verify that? If not what could be the problem than???? Please help Kind regards, D. Kniep From owner-ietf-sasl Thu Oct 9 15:38:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc2ZA094765 for ; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Mc2Am094764 for ietf-sasl-bks; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc1ZA094759 for ; Thu, 9 Oct 2003 15:38:01 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 79992151D9B; Thu, 9 Oct 2003 18:38:03 -0400 (EDT) To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> From: Sam Hartman Date: Thu, 09 Oct 2003 18:38:03 -0400 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> (Nicolas Williams's message of "Thu, 9 Oct 2003 08:04:30 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey Nicolas> wrote: >> If the TLS tunnel is only server authenticated and the client >> supports a particular SASL method (perhaps even in a different >> protocol)that provides mutual authentication both inside and >> outside a TLS tunnel there is a vulnerability. In this case if >> only the message protection of TLS is used you cannot be sure >> that the client endpoint of the TLS tunnel is the same client >> endpoint that the server authenticated with SASL. >> >> To mitigate this problem you can: >> >> - Use the protection from the inner SASL method - Have the SASL >> authentication mechanism authenticate the TLS Session ID or >> some similar parameter - Require different credentials be used >> by a SASL mechanism when operating inside or outside a TLS >> tunnel. Nicolas> Why does this sound really familiar? Ah, because one Nicolas> solution is to "bind" one layer (SASL) to the key Nicolas> exchange and negotiation of the other (TLS) to prove that Nicolas> there's no MITM at the lower layer (TLS) - which, of Nicolas> course, relies on an MITM's inability to make the key Nicolas> exchange/nego look the same on both side of the lower Nicolas> layer channel. Nicolas> In the GSS-API we call this channel bindings. Perhaps Nicolas> SASL should have I wish SASL had this feature a lot. It's clearly out of scope for both the XMPP working group and for the SASL working group. From owner-ietf-sasl Thu Oct 9 16:42:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng4ZA098040 for ; Thu, 9 Oct 2003 16:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Ng3EW098039 for ietf-sasl-bks; Thu, 9 Oct 2003 16:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng2ZA098034 for ; Thu, 9 Oct 2003 16:42:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h99Ng4lg044945; Thu, 9 Oct 2003 23:42:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009163323.0388c3b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 16:41:32 -0700 To: Dick Kniep From: "Kurt D. Zeilenga" Subject: Re: Sasl problems Cc: SASL WG In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> References: <1065738130.31142.2.camel@server.kniep.nl> 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: Dick, As list is reserved for discussions regarding standardization of SASL, your post is off-topic. You should instead direct your post to a forum which supports the particular software you are using. I note that Cyrus SASL mailing list information can be found at . Thanks, Kurt (SASL WG co-chair) At 03:22 PM 10/9/2003, Dick Kniep wrote: >Hi List, > >This is my first post on the sasl list, I am no guru on SASl, so please >be gentle. > >We have installed a Kolab server (groupware with Sasl, postfix, cyrus >imap etc.) Install went smoothly, but we cannot log on. I have posted to >the kolab mailinglist, but got no answer whatsoever. So, next is my >original post to the kolab mailinglist. If anyone can help, please do >so. > >Since the original occurrance of the error, I have tried to remove the >user 'dick' completely from the system, defining it again etc. All to no >avail. > >++++ Original message to Kolab mailinglist ++++ > >We have a strange phenomenon where we cannot get access to the server. > >We have entered a userid in the management module. This works OK (or so >it seems) Next we try to login, but then we get a message that the >userid is not authorized. The password is correct. When we look in the >logs of SASL the following messages are shown: > >-------------------------- > >Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or >more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). >Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth >failure: [user=dick] [service=imap] [realm=] [mech=ldap] > >-------------------------- > >It says that there are more definitions of the user 'dick'. >If that is the case how can we verify that? >If not what could be the problem than???? > >Please help > >Kind regards, >D. Kniep From owner-ietf-sasl Thu Oct 9 16:56:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu4ZA098325 for ; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Nu4uF098324 for ietf-sasl-bks; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu3ZA098315 for ; Thu, 9 Oct 2003 16:56:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h99Ntvo5020961; Thu, 9 Oct 2003 19:56:00 -0400 (EDT) Message-ID: <3F85F58C.3000905@oceana.com> Date: Thu, 09 Oct 2003 19:55:56 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dick Kniep CC: SASL WG Subject: Re: Sasl problems References: <1065738130.31142.2.camel@server.kniep.nl> In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrong list. This list is for discussion of the design of SASL and its mechanisms, not the implementations. Try: cyrus-sasl@lists.andrew.cmu.edu and/or info-cyrus@lists.andrew.cmu.edu Dick Kniep wrote: > Hi List, > > This is my first post on the sasl list, I am no guru on SASl, so please > be gentle. > > We have installed a Kolab server (groupware with Sasl, postfix, cyrus > imap etc.) Install went smoothly, but we cannot log on. I have posted to > the kolab mailinglist, but got no answer whatsoever. So, next is my > original post to the kolab mailinglist. If anyone can help, please do > so. > > Since the original occurrance of the error, I have tried to remove the > user 'dick' completely from the system, defining it again etc. All to no > avail. > > ++++ Original message to Kolab mailinglist ++++ > > We have a strange phenomenon where we cannot get access to the server. > > We have entered a userid in the management module. This works OK (or so > it seems) Next we try to login, but then we get a message that the > userid is not authorized. The password is correct. When we look in the > logs of SASL the following messages are shown: > > -------------------------- > > Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or > more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). > Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth > failure: [user=dick] [service=imap] [realm=] [mech=ldap] > > -------------------------- > > It says that there are more definitions of the user 'dick'. > If that is the case how can we verify that? > If not what could be the problem than???? > > Please help > > Kind regards, > D. Kniep > > > > > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 9 19:53:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r8ZA003688 for ; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A2r828003687 for ietf-sasl-bks; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r3ZA003682 for ; Thu, 9 Oct 2003 19:53:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9A2r1lg046810; Fri, 10 Oct 2003 02:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 19:52:29 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Replacing a SASL security layer Cc: Jeffrey Hutzelman , SASL WG In-Reply-To: <3F848CD6.9010804@isode.com> References: <3F848CD6.9010804@isode.com> 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: A concern here is that a number of application profiles specify (and developers have implemented) SASL layers such that established layers cannot be deinstalled except to install new layers. Changing this now will naturally introduce some interoperability, so we need to be sure that the change is well justified. I wonder if it might be better to not to change the protocol but, instead, just document the security consideration. Kurt From owner-ietf-sasl Fri Oct 10 02:45:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jrZA081146 for ; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9jrOC081145 for ietf-sasl-bks; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jlZA081138 for ; Fri, 10 Oct 2003 02:45:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 10 Oct 2003 10:45:40 +0100 Message-ID: <3F867FC1.90704@isode.com> Date: Fri, 10 Oct 2003 10:45:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >A concern here is that a number of application profiles >specify (and developers have implemented) SASL layers such >that established layers cannot be deinstalled except to install >new layers. > I am only aware of one protocol that might do that: LDAP. > Changing this now will naturally introduce some >interoperability, so we need to be sure that the change is well >justified. > I don't believe anybody implements this right anyway (please, do let me know if I am right). > I wonder if it might be better to not to change the >protocol but, instead, just document the security consideration. > I would like to allow new protocols to allow to deinstall the security layer when none is negotiated. RFC 2222 prohibits this. IMHO, it is fine if an existing protocol doesn't do that (and documents the issue in Security considerations), but there is no point of forcing brokeness on new protocols. Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Fri Oct 10 02:46:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kEZA081162 for ; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9kECt081160 for ietf-sasl-bks; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-12.noos.net [212.198.2.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kCZA081154 for ; Fri, 10 Oct 2003 02:46:13 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 9850079 invoked by uid 0); 10 Oct 2003 09:45:46 -0000 Received: (qmail 8715980 invoked by uid 0); 9 Oct 2003 07:19:39 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with SMTP for ; 9 Oct 2003 07:19:39 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 6E11663FD9; Thu, 9 Oct 2003 00:10:03 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by hades.jabber.org (Postfix) with ESMTP id 1E90F63D7C for ; Thu, 9 Oct 2003 00:09:27 -0500 (CDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> From: Eric Rescorla In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org X-Reply-To: EKR List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Oct 2003 22:16:31 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg From owner-ietf-sasl Fri Oct 10 08:41:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfMZA098198 for ; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AFfMuC098197 for ietf-sasl-bks; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-02.noos.net [212.198.2.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfKZA098189 for ; Fri, 10 Oct 2003 08:41:21 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 3714922 invoked by uid 0); 10 Oct 2003 15:40:43 -0000 Received: (qmail 3205723 invoked by uid 0); 8 Oct 2003 19:32:14 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for ; 8 Oct 2003 19:32:14 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 51F8863FB6; Wed, 8 Oct 2003 14:32:09 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hades.jabber.org (Postfix) with ESMTP id 2461763FB0; Wed, 8 Oct 2003 14:31:36 -0500 (CDT) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre Cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 20:31:34 +0100 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg From owner-ietf-sasl Mon Oct 13 08:45:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjII7037188 for ; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFjIM5037187 for ietf-sasl-bks; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjGI7037180 for ; Mon, 13 Oct 2003 08:45:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9DFjH5t022347 for ; Mon, 13 Oct 2003 11:45:17 -0400 Date: Mon, 13 Oct 2003 11:45:17 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: rfc2254bis/rfc2554bis 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: I'd like to point members of this working group at the following two documents which are intended as revisions to the SMTP/POP3 SASL profiles: draft-siemborski-rfc1734bis-00.txt draft-siemborski-rfc2554bis-00.txt The aims here are to clarify the specifications to result in fewer interoperability problems. The two big concerns that I am aware of being how implementations deal with client-send-first and (in the case of SMTP) servers rejecting the AUTH= parameter to MAIL FROM when the session is not authenticated. I will be updating these drafts to point at rfc2222bis in their first revision. I'd also like to hear any other comments. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Oct 13 10:19:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJLI7039891 for ; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DHJLZk039890 for ietf-sasl-bks; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJKI7039885 for ; Mon, 13 Oct 2003 10:19:20 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJL7R019978 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJLX0023277 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHJK0I013308 for ; Mon, 13 Oct 2003 13:19:20 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHJJs4000506; Mon, 13 Oct 2003 13:19:19 -0400 Date: Mon, 13 Oct 2003 13:19:19 -0400 Message-Id: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Greg Hudson To: ietf-sasl@imc.org Subject: Some implementor's notes Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm writing these notes in hopes that they will provide insight on possible barriers to SASL's adoption. When I created the custom Subversion protocol, I decided to use SASL for authentication because I liked the concept and because I dislike the properties of X.509 certificates, which (via TLS) are the only real alternative that I know of. I started out by implementing ANONYMOUS and EXTERNAL myself, since those are trivial. I figured for the real meat, I would use a library, since in an ideal world applications have no business implementing authentication systems. Unfortunately, I'm finding the Cyrus library unsuitable (I'll detail the reasons for this at the end, since it's implementation-specific) and I can't use the gsasl library in Subversion since it is covered by the GPL. So, since there have been a lot of calls for password authentication, I thought maybe I would implement one of the shared-secret systems without stream protection; Subversion's utility libraries already include an MD5 implementation, so I figured I wouldn't need to introduce any complicated pieces of code. First, I looked into CRAM-MD5. It doesn't authenticate the server and it doesn't leave the window open for stream protection, but those issues aren't critical. I found the following sources of hidden complexity: * The processing of the secret (pad to 64 bytes or digest and then pad to 64 bytes) is clunky and has no value in an MD5 context as far as I know. * I find it important to avoid storing passwords in clear text, since people often use the same password for multiple systems. To accomplish this, you need an MD5 implementation which supports saving intermediate states. * The current draft mandates the use of RFC 3454, a 91-page RFC I don't understand and which does not look trivial to implement. I'm sure there are real issues with internationalized usernames and passwords, but the blow-up in complexity seems astounding. Faced with these problems and a general sense of guilt at the idea of implementing a weak system, I turned to DIGEST-MD5. I found that while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the digests, it comes with a burdensome level of complexity which is unrelated to its conceptual security properties. In particular: * It introduces the concepts of realms, subsequent authentication, and authorization IDs, none of which seem to be important functionality for a generic shared-secret authentication scheme, and all of which could (I think) be handled out of band. Fortunately, it's not too difficult to avoid supporting those features. * Messages are composed of key-value pairs which do not obey a consistent syntax for the value, so parsing them is hard. (I'm not convinced that Cyrus's implementation is correct, particularly for skipping over auth-param values.) * Length-counted strings would be easier to parse than quoted strings while remaining human-readable. * Implicit allowance for linear whitespace has no intrinsic value and renders implementations more complicated and error-prone. * It is not specified whether the serv-type, host, and digest-uri values are required. (Cyrus treats digest-uri as required but not the other two, probably because it's not specified what you should do with an unspecified digest-uri when computing the digests.) It is not made clear what security value, if any, these parameters have; to "detect accidental connection to the incorrect server" is not an important function for an authentication scheme. * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems like a very burdensome requirement to place on the protocol for the sake of a very implementation-specific convenience. One can avoid this complexity by not supporting UTF-8, but that in itself is unfortunate. Most of this complexity is there to provide wire similarity between DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling justification for requiring a tenfold expansion in code size over what would be required to compute the digests and do basic parsing. Because of this complexity, I am likely to go back to CRAM-MD5, ignoring the RFC 3454 requirement in the current draft. I'm not sure what SASL can do at this point to reduce the implementation burdens, but I have to say that I am sorely disappointed. When one is designing a security system, one should compromise simplicity only in the name of security. As promised, here are my major issues with the Cyrus SASL implementation: * As I've discussed before, if you're a library invoking the SASL library, there's no way to ensure thread-safety while remaining compatible with other libraries invoking SASL. * The getopt interface seems to be a barrier to successfully documenting or internationalizing an application's configuration system. * The API does not successfully hide the complexity of the underlying mechanisms, such as digest-md5's realms. (By "hide" here I don't mean the API shouldn't support them, but that you should have to go to extra effort to use them, instead of having to go to extra effort to ignore them.) * The secrets database is kept in a database format which depends on the build of the library. If you go from one build to another (say, by upgrading versions of Red Hat) and the new build uses a different database, your server stops working and you get a cryptic error. That seems totally unacceptable, and I wonder how existing users of the library are dealing with it. * The secrets database keeps secrets in plain text, which I find unacceptable due to the amount of password-sharing users do. From owner-ietf-sasl Mon Oct 13 11:11:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBEI7042435 for ; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DIBElS042434 for ietf-sasl-bks; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBDI7042429 for ; Mon, 13 Oct 2003 11:11:13 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DIBAo8025711 for ; Mon, 13 Oct 2003 14:11:14 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DI61Fp029761 for ; Mon, 13 Oct 2003 14:06:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHxtjW004447 for ; Mon, 13 Oct 2003 13:59:56 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHxrL6000520; Mon, 13 Oct 2003 13:59:53 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: ietf-sasl@imc.org In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066067993.30290.58.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 13:59:53 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 13:19, Greg Hudson wrote: > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) Whoops, this was based on a misreading of the syntax for auth-param (I read it as being "auth-param=token=value" instead of just "token=value"). So, ignore that point. From owner-ietf-sasl Mon Oct 13 13:41:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf7I7047402 for ; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DKf7xo047401 for ietf-sasl-bks; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf6I7047395 for ; Mon, 13 Oct 2003 13:41:06 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9DKf0P5036838; Mon, 13 Oct 2003 14:41:01 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Mon, 13 Oct 2003 14:41:00 -0600 From: Lyndon Nerenberg To: Greg Hudson , ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <2147483647.1066056060@[192.168.42.6]> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > * I find it important to avoid storing passwords in clear text, > since people often use the same password for multiple systems. To > accomplish this, you need an MD5 implementation which supports > saving intermediate states. That's an implementation issue, and not a CRAM-MD5 problem. [More on this below.] > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. 3454 is a bit verbose, but from an implementation standpoint it's really not that complicated. There's no getting away from stringprep. The alternative solution of restricting everything to US-ASCII is a non-starter. With the IETF heavily leaning towards stringprep for all new protocol work, you shouldn't have any trouble finding libraries that will assist with the UTF coding issues. > Because of this complexity, I am likely to go back to CRAM-MD5, > ignoring the RFC 3454 requirement in the current draft. Please don't. We have enough trouble as it is with implementations sending non-ASCII strings in CRAM-MD5. Without the ability to specify the character set in use, interoperability suffers greatly. stringprep solves this problem. > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. If you don't trust the OS to protect this data then your only option is to use a SASL mechanism that doesn't require plain text equivalent secrets. This is SASL mechanism specific, and not an artifact of the Cyrus implementation. --lyndon From owner-ietf-sasl Mon Oct 13 14:16:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGHI7049390 for ; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DLGH0W049389 for ietf-sasl-bks; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGGI7049368 for ; Mon, 13 Oct 2003 14:16:16 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLGHSX018273; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLG3hk009695; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DLC0jW003985; Mon, 13 Oct 2003 17:12:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DLBvN6000604; Mon, 13 Oct 2003 17:11:57 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: Lyndon Nerenberg Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1066056060@[192.168.42.6]> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <2147483647.1066056060@[192.168.42.6]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066079516.30290.91.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 17:11:57 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 16:41, Lyndon Nerenberg wrote: > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > If you don't trust the OS to protect this data then your only option is > to use a SASL mechanism that doesn't require plain text equivalent > secrets. This is SASL mechanism specific, and not an artifact of the > Cyrus implementation. The issue is not how much the OS can be trusted; it's how much the owner of the server can be trusted. Ideally, the user should be able to provide the secret to the server owner in such a way that the server owner cannot reuse it with other services. On further consideration, even if CRAM-MD5 secrets are kept in intermediate form, that form can be reused with other CRAM-MD5 services, so that's maybe not so useful. However, a DIGEST-MD5 password in intermediate form can only be used with another DIGEST-MD5 service if the username and realm matches. I'm not really sure what the common practice is for realm names, but if they're commonly related to the server hostname then the secret shouldn't be reusable in practice. From owner-ietf-sasl Tue Oct 14 03:36:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAauI7038856 for ; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EAau2m038855 for ietf-sasl-bks; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAasI7038849 for ; Tue, 14 Oct 2003 03:36:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 11:36:49 +0100 Message-ID: <3F8BD1BF.4080001@isode.com> Date: Tue, 14 Oct 2003 11:36:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: >... > >First, I looked into CRAM-MD5. It doesn't authenticate the server and >it doesn't leave the window open for stream protection, but those >issues aren't critical. I found the following sources of hidden >complexity: > >... > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as well (at least it will when I publish a new revision) > >Faced with these problems and a general sense of guilt at the idea of >implementing a weak system, I turned to DIGEST-MD5. I found that >while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes >the digests, it comes with a burdensome level of complexity which is >unrelated to its conceptual security properties. In particular: > > * It introduces the concepts of realms, subsequent authentication, > and authorization IDs, none of which seem to be important > functionality for a generic shared-secret authentication scheme, > and all of which could (I think) be handled out of band. > Fortunately, it's not too difficult to avoid supporting those > features. > > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) > I suggest you try to find a case that breaks stuff. It is more constructive than saying that something doesn't (or may not) work. > * Length-counted strings would be easier to parse than quoted > strings while remaining human-readable. > > * Implicit allowance for linear whitespace has no intrinsic value > and renders implementations more complicated and error-prone. > Yes. There are historical reasons why this happened. It was a compromise between design and something that could have been implemented by one big vendor. It was supposed to become a replacement for another seriously broken SASL mechanism NTLM. > * It is not specified whether the serv-type, host, and digest-uri > values are required. > They are required to be sent, but the receiver SHOULD (but not required to) verify it. If the text is not clear, let me know and I will try to fix it. > (Cyrus treats digest-uri as required but not > the other two, probably because it's not specified what you should > do with an unspecified digest-uri when computing the digests.) It > is not made clear what security value, if any, these parameters > have; to "detect accidental connection to the incorrect server" is > not an important function for an authentication scheme. > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > like a very burdensome requirement to place on the protocol for > the sake of a very implementation-specific convenience. One can > avoid this complexity by not supporting UTF-8, but that in itself > is unfortunate. > >Most of this complexity is there to provide wire similarity between >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling >justification for requiring a tenfold expansion in code size over what >would be required to compute the digests and do basic parsing. > > See above. >Because of this complexity, I am likely to go back to CRAM-MD5, >ignoring the RFC 3454 requirement in the current draft. I'm not sure >what SASL can do at this point to reduce the implementation burdens, >but I have to say that I am sorely disappointed. When one is >designing a security system, one should compromise simplicity only in >the name of security. > SASL has nothing to do with your problem (well, very little to do). SASL is just a framework. If you don't like mechanisms that are currently available, you can write a new one and try to make it deployed. >As promised, here are my major issues with the Cyrus SASL >implementation: > > * As I've discussed before, if you're a library invoking the SASL > library, there's no way to ensure thread-safety while remaining > compatible with other libraries invoking SASL. > > * The getopt interface seems to be a barrier to successfully > documenting or internationalizing an application's configuration > system. > Why? > * The API does not successfully hide the complexity of the > underlying mechanisms, such as digest-md5's realms. (By "hide" > here I don't mean the API shouldn't support them, but that you > should have to go to extra effort to use them, instead of having > to go to extra effort to ignore them.) > Yes, this is a bit unfortunate, but I had exactly the same problem trying to write a different SASL implementation. > > * The secrets database is kept in a database format which depends on > the build of the library. > Shouldn't really. Secrets are usually stored in sasldb backend, the format is quite stable at this point and shouldn't change very much over the time. > If you go from one build to another > (say, by upgrading versions of Red Hat) and the new build uses a > different database, your server stops working and you get a > cryptic error. That seems totally unacceptable, and I wonder how > existing users of the library are dealing with it. > > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. > > Alexey From owner-ietf-sasl Tue Oct 14 07:54:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs7I7050838 for ; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EEs7O5050837 for ietf-sasl-bks; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs1I7050822 for ; Tue, 14 Oct 2003 07:54:01 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9QYh-0007AW-8m; Tue, 14 Oct 2003 16:53:59 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9QXB-0006bE-Dt; Tue, 14 Oct 2003 16:52:25 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9QX7-0003E1-00; Tue, 14 Oct 2003 16:52:21 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 16:52:21 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>4.1. Authentication protocol exchange >>> >>> A SASL mechanism is responsible for conducting an authentication >>> protocol exchange. This consists of a series of server challenges >>> and client responses, >>> >> >>Does this mean that the initial auth command from the client is not >>considered part of the authentication protocol exchange? >> > Does it matter in this section? Well, that's where "authentication protocol exchange" seems to be defined. It matters if other documents refer to "the authentication protocol exchange". Anyway, I think I found the answer in section 6.1. The initial auth command from the client is not part of the exchange, but the optional "response" in the auth command is. >>>4.2. Authorization identities and proxy authentication >>> >>> (...) >>> The character encoding scheme used for transmitting an authorization >>> identity over protocol is specified in each authentication mechanism >>> (with the authentication mechanism's blob being further >> ^^^^ >> >>What's a blob? I don't think it's 'something ill-defined or amorphous', >>like the dictionary says:-) >> > I've changed this to "data". I still don't know _which_ data you are talking about. >>> A protocol profile MAY further refine the definition of an >>> authorization identity by adding additional syntactic restrictions >>> and protocol-specific semantics. >> >>Add a paragraph break here, since the following is a new item. Remove >>"A protocol profile MUST specify" to just make the following a new item >>in the list of things that must be specified. >> >>> A protocol profile MUST specify the >>> form of the authorization identity (as it is protocol specific, as >>> > I would rather not do this, as this is a single logic item. OK. >>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>top. >> > I've added a sentence about this in the introduction section. I'm pretty sure you will still need to insert the words "Obsoletes: rfc 2222" in the header sometime, though I don't remember where this is stated. -- Hallvard From owner-ietf-sasl Tue Oct 14 08:01:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1jI7051200 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EF1jJu051199 for ietf-sasl-bks; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1iI7051193 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Qg8-0000BM-Pt; Tue, 14 Oct 2003 17:01:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9Qfz-0006hy-SS; Tue, 14 Oct 2003 17:01:31 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Qfy-0003FW-00; Tue, 14 Oct 2003 17:01:30 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt In-Reply-To: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:01:30 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >> draft-ietf-sasl-plain-02.txt says that >> >> The client leaves >> the authorization identity empty if it wishes the server to derive the >> authorization identity from the provided authentication identity. >> >> and >> >> Note that the parameters provided to the Authorize function are not >> prepared. >> >> so I think the pseudo-code for empty authzid should say >> authzid = DeriveAuthzid(authcid); >> and not >> authzid = DeriveAuthzid(pAuthcid); > > I think the current psuedo-code is correct, the first > quoted text is misleading. I don't feel strongly about this, but the original wording seems right to me. authzid is not prepared, so neither does it use the prepared version of authcid. And that way, PLAIN(authzid = "", authcid = X, password) does the same as PLAIN(authzid = X, authcid = X, password). Your way, it does not. That seems wrong to me. -- Hallvard From owner-ietf-sasl Tue Oct 14 08:33:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXII7052605 for ; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFXIfG052604 for ietf-sasl-bks; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXHI7052597 for ; Tue, 14 Oct 2003 08:33:17 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9RAf-0003aB-3F; Tue, 14 Oct 2003 17:33:13 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9RAb-0005Iv-1b; Tue, 14 Oct 2003 17:33:09 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9RAX-0003Jn-00; Tue, 14 Oct 2003 17:33:05 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:33:05 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> 3). Realm > > I have not yet heard any arguments to keep the realm text. I found it useful, since I had no clear idea what a realm was. The text is just too demanding. How about making the text purely informational, without any SHOULD or MUST? -- Hallvard From owner-ietf-sasl Tue Oct 14 08:53:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr2I7053298 for ; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFr2bK053297 for ietf-sasl-bks; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr1I7053292 for ; Tue, 14 Oct 2003 08:53:01 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EFr2lg099937; Tue, 14 Oct 2003 15:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014083522.03aaed50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 08:52:24 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> 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: At 08:01 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >>> draft-ietf-sasl-plain-02.txt says that >>> >>> The client leaves >>> the authorization identity empty if it wishes the server to derive the >>> authorization identity from the provided authentication identity. >>> >>> and >>> >>> Note that the parameters provided to the Authorize function are not >>> prepared. >>> >>> so I think the pseudo-code for empty authzid should say >>> authzid = DeriveAuthzid(authcid); >>> and not >>> authzid = DeriveAuthzid(pAuthcid); >> >> I think the current psuedo-code is correct, the first >> quoted text is misleading. > >I don't feel strongly about this, but the original wording seems >right to me. authzid is not prepared, No, the psuedo-code does not prepare the authzid. The authzid is prepared, it's just prepared by other code. I'll qualify the note with "by this code". >so neither does it >use the prepared version of authcid. The authzid is derived from the prepared authcid to ensure that all representations of the authentication identity produce the same authzid. This, I think, is important. >And that way, >PLAIN(authzid = "", authcid = X, password) does the same as >PLAIN(authzid = X, authcid = X, password). These are not necessarily equivalent. That is, authzid may not be in the same form as the authcid and may require different preparation. The psuedo code (and notes) are intended to reflect this. Kurt From owner-ietf-sasl Tue Oct 14 09:45:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjdI7055767 for ; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGjduk055766 for ietf-sasl-bks; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjcI7055761 for ; Tue, 14 Oct 2003 09:45:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EGjdlg000478; Tue, 14 Oct 2003 16:45:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014093409.03ab2c98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 09:44:46 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> 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: At 08:33 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> 3). Realm >> >> I have not yet heard any arguments to keep the realm text. > >I found it useful, since I had no clear idea what a realm was. >The text is just too demanding. How about making the text purely >informational, without any SHOULD or MUST? I think the primary concern is that the text introduces a concept with is particular to one or more mechanisms and hence is out of place. Seems better to move the text into the DIGEST-MD5 specification as it seems to following the DIGEST-MD5 concept of a realm. Other mechanisms also have realm concepts, but it's not clear to me that they are the same as DIGEST-MD5's. Kurt From owner-ietf-sasl Tue Oct 14 11:55:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItwI7060032 for ; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EItwpO060031 for ietf-sasl-bks; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItuI7060025 for ; Tue, 14 Oct 2003 11:55:56 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:53 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Oct 2003 11:55:53 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 14 Oct 2003 11:55:49 -0700 Content-class: urn:content-classes:message Subject: RE: Some implementor's notes MIME-Version: 1.0 Date: Tue, 14 Oct 2003 11:55:33 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_00A0_01C3924A.12E99900"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460539473B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Some implementor's notes thread-index: AcOSQgF/OFFnSNWNQjyVIpppTMaRZwAQhPMA From: "Paul Leach" To: "Alexey Melnikov" , "Greg Hudson" Cc: X-OriginalArrivalTime: 14 Oct 2003 18:55:49.0960 (UTC) FILETIME=[C8DA6480:01C39284] 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_000_00A0_01C3924A.12E99900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SASL's version of Digest has that clunky syntax so that it is possible to share an implementation with HTTP digest. HTTP digest couldn't get cleaned up when HTTP 1.1 was being worked on because some people claimed there were significant deployments of an earlier version. The "subsequent auth" feature was a request from client authors of apps where reconnects are frequent and the desire was to make them efficient. (POP3 clients are or used to be typical examples.) > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Alexey Melnikov > Sent: Tuesday, October 14, 2003 3:37 AM > To: Greg Hudson > Cc: ietf-sasl@imc.org > Subject: Re: Some implementor's notes > > > Greg Hudson wrote: > > >... > > > >First, I looked into CRAM-MD5. It doesn't authenticate the > server and > >it doesn't leave the window open for stream protection, but those > >issues aren't critical. I found the following sources of hidden > >complexity: > > > >... > > > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > > don't understand and which does not look trivial to implement. > > I'm sure there are real issues with internationalized usernames > > and passwords, but the blow-up in complexity seems astounding. > > > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as > well (at least it will when I publish a new revision) > > > > >Faced with these problems and a general sense of guilt at > the idea of > >implementing a weak system, I turned to DIGEST-MD5. I found > that while > >DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the > >digests, it comes with a burdensome level of complexity which is > >unrelated to its conceptual security properties. In particular: > > > > * It introduces the concepts of realms, subsequent authentication, > > and authorization IDs, none of which seem to be important > > functionality for a generic shared-secret authentication scheme, > > and all of which could (I think) be handled out of band. > > Fortunately, it's not too difficult to avoid supporting those > > features. > > > > * Messages are composed of key-value pairs which do not obey a > > consistent syntax for the value, so parsing them is hard. (I'm > > not convinced that Cyrus's implementation is correct, > particularly > > for skipping over auth-param values.) > > > I suggest you try to find a case that breaks stuff. It is > more constructive than saying that something doesn't (or may > not) work. > > > * Length-counted strings would be easier to parse than quoted > > strings while remaining human-readable. > > > > * Implicit allowance for linear whitespace has no intrinsic value > > and renders implementations more complicated and error-prone. > > > Yes. There are historical reasons why this happened. > It was a compromise between design and something that could > have been implemented by one big vendor. > It was supposed to become a replacement for another seriously > broken SASL mechanism NTLM. > > > * It is not specified whether the serv-type, host, and digest-uri > > values are required. > > > They are required to be sent, but the receiver SHOULD (but > not required > to) verify it. If the text is not clear, let me know and I > will try to fix it. > > > (Cyrus treats digest-uri as required but not > > the other two, probably because it's not specified what > you should > > do with an unspecified digest-uri when computing the > digests.) It > > is not made clear what security value, if any, these parameters > > have; to "detect accidental connection to the incorrect > server" is > > not an important function for an authentication scheme. > > > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > > like a very burdensome requirement to place on the protocol for > > the sake of a very implementation-specific convenience. One can > > avoid this complexity by not supporting UTF-8, but that in itself > > is unfortunate. > > > >Most of this complexity is there to provide wire similarity between > >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling > >justification for requiring a tenfold expansion in code size > over what > >would be required to compute the digests and do basic parsing. > > > > > See above. > > >Because of this complexity, I am likely to go back to CRAM-MD5, > >ignoring the RFC 3454 requirement in the current draft. I'm > not sure > >what SASL can do at this point to reduce the implementation burdens, > >but I have to say that I am sorely disappointed. When one > is designing > >a security system, one should compromise simplicity only in > the name of > >security. > > > SASL has nothing to do with your problem (well, very little to do). > SASL is just a framework. If you don't like mechanisms that > are currently available, you can write a new one and try to > make it deployed. > > >As promised, here are my major issues with the Cyrus SASL > >implementation: > > > > * As I've discussed before, if you're a library invoking the SASL > > library, there's no way to ensure thread-safety while remaining > > compatible with other libraries invoking SASL. > > > > * The getopt interface seems to be a barrier to successfully > > documenting or internationalizing an application's configuration > > system. > > > Why? > > > * The API does not successfully hide the complexity of the > > underlying mechanisms, such as digest-md5's realms. (By "hide" > > here I don't mean the API shouldn't support them, but that you > > should have to go to extra effort to use them, instead of having > > to go to extra effort to ignore them.) > > > Yes, this is a bit unfortunate, but I had exactly the same > problem trying to write a different SASL implementation. > > > > > * The secrets database is kept in a database format which > depends on > > the build of the library. > > > Shouldn't really. Secrets are usually stored in sasldb > backend, the format is quite stable at this point and > shouldn't change very much over the time. > > > If you go from one build to another > > (say, by upgrading versions of Red Hat) and the new build uses a > > different database, your server stops working and you get a > > cryptic error. That seems totally unacceptable, and I wonder how > > existing users of the library are dealing with it. > > > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > > > > Alexey > > > > ------=_NextPart_000_00A0_01C3924A.12E99900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlHDCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBmcwggYooAMCAQICCiFlQmAA AgAAAJYwCQYHKoZIzjgEAzBvMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1Jl ZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVW IFdpbjJLIElzc3VlIENBMB4XDTAzMDgyMTE3MDcyM1oXDTA0MDgyMDE3MDcyM1owQjErMCkGCSqG SIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTETMBEGA1UEAxMKUGF1bCBMZWFj aDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0xTvP/FlC8fgJAIfma5S5qyOlX9cEBVW6Pow YiSkWaKsfecw/fFg8olmGrV6STKTv0mxvvJgz6VprvvRgPc9/lavEa7Dg5BpW3bbEIWto40DvaqB gl9QZ9Ad+mtNFD5XyMO3Bw8JKiZgy1GIXerH6LQ+rTXmCQeqG/jVeOxoFiUCAwEAAaOCBJEwggSN MAsGA1UdDwQEAwIFoDAdBgNVHQ4EFgQUIaL8rFmdmJIbwYUpAThTsFPTjXowKQYJKwYBBAGCNxQC BBweGgBTAG0AYQByAHQAYwBhAHIAZABVAHMAZQByMIGUBgNVHSMEgYwwgYmAFCAZq9iZaHr5hoL6 cnmH00RgUUXvoWWkYzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQL EwVOdGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMoIK LgdxZgAFAAACIzCCAa4GA1UdHwSCAaUwggGhMIHioIHfoIHchoHZbGRhcDovLy9DTj1OVERFViUy MFdpbjJLJTIwSXNzdWUlMjBDQSgxKSxDTj1udGRldjJrY2EsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29y cCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBcoFqgWIZWaHR0cDovL250ZGV2MmtjYS5udGRl di5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFdpbjJLJTIwSXNzdWUlMjBD QSgxKS5jcmwwXKBaoFiGVmh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvTlRERVYlMjBXaW4ySyUyMElzc3VlJTIwQ0EoMSkuY3JsMIIBaQYIKwYBBQUH AQEEggFbMIIBVzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPU5UREVWJTIwV2luMkslMjBJc3N1 ZSUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRp ZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhQYIKwYBBQUH MAKGeWh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv bnRkZXYya2NhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFdpbjJLJTIwSXNzdWUl MjBDQSgyKS5jcnQwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwQGCCsGAQUFBwMCMFMG A1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1 bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTAJBgcqhkjOOAQDAy4AMCsCE0S2SLEdb4WEJv055mWF zOTOP/MCFFKWyliMgynk36EVIBHy8sw1aqfLMIIGlzCCBlagAwIBAgIKLgdxZgAFAAACIzAJBgcq hkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2 MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4XDTAyMTAx MTE3MDg1NloXDTA0MTAxMTE3MTg1NlowbzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU5UREVWMR0wGwYDVQQD ExROVERFViBXaW4ySyBJc3N1ZSBDQTCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQCTCC1vMkOpDkgx MJmlg1rQPpIRgEdDJNoJMpf47nK1k2QMx4tBoKaHhWPcxyblUTiWEz/ahR9Pb027PZS+l3Hg11Zn CkUDWv+Ua+x7HgRn88y219o5g5KLvXfXP66hargC7sip9Zs+qN1OMqrg6aKRNynCxav2lTghPQBO 4gc+LwIVANmVGNJGOMKtxSR5S3dlI7slhj0rAoGAVEWozto8isIYr5QbAWkAHlzfc2tX+2RhE/oa lqehpAtFfvDeWau/csQQ3QWZI46spI7ebyvGiOVbLF5HQMxAJ2fBC0XZBLM82YgeKuOfVYwam6gs TiYm24oKz7VbdofyCfjelJRXT2mJEeUonMaKbAySJySfQuELBvKxCUC7lqADgYQAAoGAFiRVn6Ny rDG1yvxstlatKvIt3Pd3oU148+jngq4lE6L7DCia91idkKfri321sSLZJpRWjw0tBXyV6PhX1Ofy cM04WMpYttjpgtYy31cMXmnnMgxC+jAYcOwYp6ecTGVxNRuZNzez3xmwZ9z82SfRCqmDh1EMNXYr QR0H4VUHI+ajggOIMIIDhDASBgkrBgEEAYI3FQEEBQIDAQACMB0GA1UdDgQWBBQgGavYmWh6+YaC +nJ5h9NEYFFF7zAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTivgNw1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAw ggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9y ZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNz PWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRwOi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0 LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGlj YTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NO PU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIu bnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWlj cm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUp LmNydDAJBgcqhkjOOAQDAzAAMC0CFHNk8vkyGD3GAmwPvUg1m5fVyfGTAhUAhnex7TIppYeW5OMY qJonfdc4Z5UwggaoMIIGEaADAgECAgor++JGAAMAMgjEMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERF ViBJU1NVRTMgQ0EwHhcNMDMwODIxMTcwNzExWhcNMDQwODIwMTcwNzExWjCBsDETMBEGCgmSJomT 8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNv cnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGln aHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqoW5IwY+zVFVnkEXvyXTr2NUw9BIh1G5Prz/7ICp7EF4y T3KXY5VXzfTgSaq3PofyDHpgtxz/mKKYyLxHiXYoovpCajquTpTyr3dlPpj6bkLpAHH7wWR3VvyX G3bzbYePZpkBho4/qI7SZhRhKJH8Jr4WgtcpMB+WZonry1GRZQIDAQABo4IEKzCCBCcwCwYDVR0P BAQDAgeAMB0GA1UdDgQWBBSd1h+ZKvVxSfNGOZpADzy9ClfE0jA+BgkrBgEEAYI3FQcEMTAvBicr BgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYK/nPZ8ht7mgFQCAXgCAQEwHwYDVR0jBBgwFoAU i9HNYfHpr468kdBA6im/5i6FQFcwggGIBgNVHR8EggF/MIIBezCCAXegggFzoIIBb4aBz2xkYXA6 Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSgyKSxDTj1XSElDQTMsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZNaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9OVERFVkNSTHMvTlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcmyGTGh0 dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ U1NVRTMlMjBDQSgyKS5jcmwwggFUBggrBgEFBQcBAQSCAUYwggFCMIHFBggrBgEFBQcwAoaBuGxk YXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRp b25BdXRob3JpdHkweAYIKwYBBQUHMAKGbGh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3Nv ZnQuY29tL0NlcnRFbnJvbGwvV0hJQ0EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUy MElTU1VFMyUyMENBKDMpLmNydDATBgNVHSUEDDAKBggrBgEFBQcDBDAtBgNVHSAEJjAkMCIGICsG AQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVAYMRMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH AwQwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRldi5taWNyb3NvZnQuY29t gRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMA0GCSqGSIb3DQEBBQUAA4GBAH/THraMU6d3 3PRTCS9MWY9ECxgGz/q4JBjPeHGdBKdcH3zjo291rfdmP8iqjekjHPC5Q7Mk2pghYt5IeksAdKNF PoPNOMaDVAM1BBMczPerfR1VA/jpltBeNrKc+X+en2VBlHVXTF/WDix7cgiVSKuO4njAykP1sCck FLpQVeTpMIIIGzCCBwOgAwIBAgIKKMbncgABAAAANTANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYg U0EgUm9vdCBDQTAeFw0wMjEwMTAxNjMzMDBaFw0wNTEwMTAxNjQzMDBaMGExCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRl cm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMIIBtzCCASsGByqGSM44BAEwggEeAoGBAPoSz3u7 mLB5rhlH5CE5AalrBl6Ntst+vZLNPRPhI8ABrNuHKYWlR6hWd/ikP5IMgDQr7DUpJrrdv4Z2T1pJ PVEHIxCua3HTX/o+XVGTZXdBv4x+OhHLmt11KcTy9B+0tpg3psJC4m+taONabd+yw/EB9AoPldGd HoGBBSGOdALjAhUAmE+UPbJ1WtXpFK2UwmM6G/zo60MCgYBmyg997xQQPnCr4IraxqUi5sXXsvSP vimwO/UEFxJwAiWS8OUunvnh7Gd0/scD5YNkVAsbRYF+XNgyYVCsYusC1LH8DvoOzq4Hz8lg9K/2 kA80v2Skr4DH1EFM2JG3J9Hbq362Dk9i8V6HAZEA/P8kB9/J+cI1LoXlWtfw5uaCmAOBhQACgYEA okrSViTIQt7ZG0Ytjr2GLccq5bTzDsmUdROQz1qi9eb5cOIYa2YXgE6cmZTIIFOLx6bPdgbwZSAs OfBQofQoLG3vJeQcGsA/vj7wzjmzlaImYsBF9OZRFKl7C3r/TLShHXBTQHo16zcCGuLCXhQvOsrj JhlKvhvR5fMmNpOK4jmjggRTMIIETzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTivgNw1Ysg 0kFEaq/myHdxWiUAHzALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwQABTAjBgkrBgEEAYI3 FQIEFgQU1lIoN1kh422F4hJqLWNtqmi8a0AwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUiMnNnJw6IoDq5C3aFUcv9fvEvJswggGZBgNVHR8EggGQMIIBjDCCAYigggGEoIIB gIaB2WxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKSxDTj13aGljYXNhcm9vdGNh LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGUWh0dHA6 Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFNB JTIwUm9vdCUyMENBKDEpLmNybIZPaHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybDCCAekGCCsGAQUFBwEB BIIB2zCCAdcwgcgGCCsGAQUFBzAChoG7bGRhcDovLy9DTj1OVERFViUyMFNBJTIwUm9vdCUyMENB LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhAYIKwYBBQUHMAKGeGh0 dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDCBggYIKwYBBQUHMAKGdmh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYl MjBTQSUyMFJvb3QlMjBDQSgxKS5jcnQwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBBQUA A4IBAQA0wmQlGbxPwheWF+0oj8v1hjBbV13gmBK/2Oy0q2OcgC/o+GSkKK+5S36xOxTvVIBio37P i6jtJI8WneO9ONcLQK5NHuUV3j9FFtCM2TnLbq/OJHu+rKrYIBRYAjn3y6oWPaZQnH1Ug6Qa54AC El1bocfKBM6bVNlJKnB+WRpnwb4MrXQinvr0rYrlYH+Z7xECHo+aJ9qnp7cXXzELF57Y9qBBbqY5 keifWFfX+NxhFpRrgwtS6LtdIPOInQLG2kPoY8QafHvTSBj4IuSxdaN+d0d9n1ODnN4IKRhRYiVS pwP7aoLrK3FelYjdLEH7XQC2q+T41duYgNhWl0Dkf26XMYIC6TCCAuUCAQEwWTBLMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYg SVNTVUUzIENBAgor++JGAAMAMgjEMAkGBSsOAwIaBQCgggHmMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAxNDE4NTUzM1owIwYJKoZIhvcNAQkEMRYEFPdbwOnO ppyG4GuX9P7P1EX02u5RMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGMBgkrBgEEAYI3EAQxfzB9MG8xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4G A1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOVERFVjEdMBsGA1UE AxMUTlRERVYgV2luMksgSXNzdWUgQ0ECCiFlQmAAAgAAAJYwgY4GCyqGSIb3DQEJEAILMX+gfTBv MQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1p Y3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVWIFdpbjJLIElzc3VlIENBAgoh ZUJgAAIAAACWMA0GCSqGSIb3DQEBAQUABIGAXpjbVOG6vEm8Ft/Id52KsowOHebp+rsm2uWqmYHx hJih28lSm+GAR57zi2xIbBoqOEoeps9m2GJ8ocbREn41peis80LNw9j26gyfJwurdyss2FkHZ3HW cOW9gJr7w6WCtz1DZ2oYZeBYiYUpZBGdxeOHopRnSXgU0rc0WY6RKysAAAAAAAA= ------=_NextPart_000_00A0_01C3924A.12E99900-- From owner-ietf-sasl Tue Oct 14 13:41:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfcI7064250 for ; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EKfcsS064249 for ietf-sasl-bks; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfaI7064242 for ; Tue, 14 Oct 2003 13:41:37 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Vz5-0007Y2-J3 for ietf-sasl@imc.org; Tue, 14 Oct 2003 22:41:35 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9Vz4-0006b5-5H; Tue, 14 Oct 2003 22:41:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Vz3-00041y-00; Tue, 14 Oct 2003 22:41:33 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis issues Date: Tue, 14 Oct 2003 22:41:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are various editorial and non-editorial comments for draft-ietf-sasl-rfc2831bis-02.txt. > Table of Contents > 3.8 CBC MODE ATTACKS............................................. Missing page number. > 1.1 Conventions and Notation > This specification uses the same ABNF notation and lexical > conventions as HTTP/1.1 specification; see section 7. ...as well as some named rules defined there (section 7.2). > The value of a quoted string constant as an octet string does not > include any terminating null character ...which the C language adds. [For readers who don't know C, if any.] > 2.1.1 Step One > > The server starts by sending a challenge. How does it know that it should do that? > nonce > Note > that since the string is passed as a quoted string, the > double-quote and backslash? > character is not allowed unless escaped (see section > 7.2). I think this applies to other quoted strings than the nonce. > server_maxbuf ("maximal ciphertext buffer size") > Let call "maximal cleartext buffer size" (or "maximal sender > size") the maximal size of a cleartext buffer that, after being "Let call"? Should be "Call", or "Let .... be", I think. > charset > This directive, if present, specifies that the server supports > UTF-8 [UTF-8] encoding for the username, realm and password. If > present, the username, realm and password are in Unicode, prepared > using the "SASLPrep" profile [SASLPrep] of the "stringprep" > algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not > present, the username, realm and password MUST be encoded in ISO > 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). There is no username and password sent by the server. Do you mean the _client_ MUST send them in UTF-8 if "charset" is given by the server? > cipher-opts > "qop-options" directive, in which case the "3des" cipher is > mandatory-to-implement. I suggest you remove the "-"s in mandatory-to-implement. > 2.1.2 Step Two > digest-uri > Indicates the principal name of the service with which the client > wishes to connect, formed from the serv-type, host, and serv-name. > For example, the FTP service on "ftp.example.com" would have a > "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from > the example above would have a "digest-uri" value of > "SMTP/mail3.example.com/example.com". > > Servers SHOULD check that the supplied value is correct. This will > detect accidental connection to the incorrect server, as well as some > redirection attacks. It is also so that clients will be trained to > provide values that will work with implementations that use a shared > back-end authentication service that can provide server > authentication. > > The serv-type component should match the service being offered. The > host component should match one of the host names of the host on > which the service is running, or it's IP address. Servers SHOULD NOT > normally support the IP address form, because server authentication > by IP address is not very useful; they should only do so if the DNS > is unavailable or unreliable. The serv-name component should match > one of the service's configured service names. > > This directive may appear at most once; if multiple instances are > present, the client should abort the authentication exchange. > > Note: In the HTTP use of Digest authentication, the digest-uri is the > URI (usually a URL) of the resource requested -- hence the name of > the directive. Is this entire section about digest-uri? If so, most of it should be indented. > authzid > The server SHOULD verify the correctness of an authzid as > specified by the corresponding SASL protocol profile. Which corresponding SASL profile? > 2.2 Subsequent Authentication > > If the client has previously authenticated to the server, and > remembers the values of username, realm, nonce, nonce-count, cnonce, ^^^^^^^^ > and qop that it used in that authentication, and the SASL profile for > a protocol permits an initial client response, then it MAY perform > "subsequent authentication", as defined in this section. What's the point of authenticating again with the same username? Auth with a _different_ username would be more interesting. > 2.2.2 Step Two > If the response is valid, the server MAY choose to deem that > authentication has succeeded. However, if it has been too long since > the previous authentication, or for any o including the next > subsequent authentication, between the client and the server MUST be > integrity protected. I don't understand the text starting with "or from any o". > Using as a base session key the value of H(A1) > as defined above need a "," here > Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the > received value; the message is discarded if they differ. The > receiver's sequence counter is incremented if they match. Doesn't the server send a response? How does the client know that the authentication is completed? > 2.4 Confidentiality Protection > > If the server sent a "cipher-opts" directive and the client responded > with a "cipher" directive, then subsequent messages between the > client and the server MUST be confidentiality protected. What is confidentiality protection? > The IV used to send/receive the initial buffer You might say "Initialization Vector (IV)" again here, it's been a while since you mentined what an IV is. > SEAL(Ki, Kc, SeqNum, msg) = > {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001, > SeqNum} SEAL? That is never used in this document. > 5.1 Normative references > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > [Unicode] The Unicode Consortium, "The Unicode Standard, Version Indent "The". > [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC > 2279, Janyary 1998. Indent "Yergeau". > [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Unindent "Hinden". > [FIPS] National Institute of Standards and Technology, "DES Modes of Indent "National". > [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", Indent "Daemen". > 5.2 Informative references > [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", Indent "Kaliski". > [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: Indent "Moeller". > 7.1 Augmented BNF Since <"> means to enclose a literal, you might replace other <">s with <'>s in this section. E.g. > rule1 | rule2 > Elements separated by a bar ("|") are alternatives, e.g., "yes | > no" will accept yes or no. Elements separated by a bar ('|') are alternatives, e.g., 'yes | no' will accept yes or no. > #rule > ( *LWS element *( *LWS "," *LWS element )) Should this really be asymmetric, or should it be ( element *( *LWS "," *LWS element )) or ( *LWS element *( *LWS "," *LWS element ) *LWS ) ? > 7.2 Basic Rules > OCTET = s/character/byte/, I think. A byte in a multi-byte UTF-8 character is not normally considered a character. > 8 Sample Code > for (scan = base; scan < end; ++scan) { > if (*scan > 0xC3) break; /* abort if outside 8859-1 */ > if (*scan >= 0xC0 && *scan <= 0xC3) { > if (++scan == end || *scan < 0x80 || *scan > 0xBF) > break; /* * Handle invalid UTF-8-like sequences, e.g. '\0' * encoded as "\xC0\x80". Accepting such sequences * is a security risk, according to [UTF-8]. */ if (*scan < 0xC2) return an error or something; Error return also requires the return type of the function to be changed, and a 'return success' at the end. Maybe another way is to simply not translate invalid UTF-8 strings to iso8859-1. This should also be discussed in the section which says that UTF-8 should be converted to iso8859-1 when possible. > } > } -- Hallvard From owner-ietf-sasl Wed Oct 15 03:58:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwXI7072093 for ; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FAwX2N072092 for ietf-sasl-bks; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwVI7072086 for ; Wed, 15 Oct 2003 03:58:31 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9jMK-0002Bu-Qs for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:28 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9jMG-0006WN-Em for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:24 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9jMB-0006DA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:19 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis: A2 when qop-value=token Date: Wed, 15 Oct 2003 12:58:19 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2831bis 2.1.1 "Step One" says: qop-options = "qop" "=" <"> qop-list <"> qop-list = 1#qop-value qop-value = "auth" | "auth-int" | "auth-conf" | token 2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is "auth", "auth-int" and "auth-conf", but not when it is . -- Hallvard From owner-ietf-sasl Wed Oct 15 04:31:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVOI7073131 for ; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBVO6x073130 for ietf-sasl-bks; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVMI7073120 for ; Wed, 15 Oct 2003 04:31:23 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9js8-0006Cl-JA for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:20 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9js5-0005N7-KS for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9js5-0006IA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: re-negotiating SASL security layer Date: Wed, 15 Oct 2003 13:31:17 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis section 6.3 "Multiple authentications" says: If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer must be removed. Exactly when is the old layer canceled? If an old layer is active and the client starts to negotiate a new layer, it may not know when to expect the response from the server. So the layer can't be canceled by starting a new negotiation. It could be canceled after receipt of the first response from the server. Or after the completed SASL negotiation, which would be performed with the old layer in effect. I don't know how easy that would be to implement, or if it would interfere with the definitions of some SASL mechanisms to have two mechanisms active at the same time. Another way would for the layers themselves contain a 'cancel layer' operation, which may only be used just before negotiating a new layer and before closing the connection. Then the SASL negotiation could be performed without mixing the old and the new SASL mechanism, and the layer could only be re-negotiated if the old layer had such a 'cancel layer' operation. -- Hallvard From owner-ietf-sasl Wed Oct 15 04:33:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXZI7073224 for ; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBXZT0073223 for ietf-sasl-bks; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXYI7073218 for ; Wed, 15 Oct 2003 04:33:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:33:36 +0100 Message-ID: <3F8D308B.5050208@isode.com> Date: Wed, 15 Oct 2003 12:33:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2831bis 2.1.1 "Step One" says: > > qop-options = "qop" "=" <"> qop-list <"> > qop-list = 1#qop-value > qop-value = "auth" | "auth-int" | "auth-conf" | > token > >2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >"auth", "auth-int" and "auth-conf", but not when it is . > Hi Hallvard, Token is specifically for future extensions, if you see a qop value you don't recognize - you have to ignore it. If you recognize nothing, you have to fail the authentication exchange. Do you want any clarifications on this to be added to the document. (I will go through your big message over weekend). Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 15 04:52:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq9I7073626 for ; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBq93X073625 for ietf-sasl-bks; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq7I7073620 for ; Wed, 15 Oct 2003 04:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:52:08 +0100 Message-ID: <3F8D34E4.4020607@isode.com> Date: Wed, 15 Oct 2003 12:52:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2222bis section 6.3 "Multiple authentications" says: > > If a security layer is in effect > and a subsequent SASL negotiation selects a second security layer, > then the second security layer replaces the first. If a security > layer is in effect and a subsequent SASL negotiation selects no > security layer, the original security layer must be removed. > >Exactly when is the old layer canceled? > >If an old layer is active and the client starts to negotiate a new >layer, it may not know when to expect the response from the server. >So the layer can't be canceled by starting a new negotiation. > No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully. Each profile document must document exactly when this takes place. A subsuquent authentication takes place while an old security layer is still in effect. >It could be canceled after receipt of the first response from the >server. Or after the completed SASL negotiation, which would be >performed with the old layer in effect. I don't know how easy that >would be to implement, or if it would interfere with the definitions of >some SASL mechanisms to have two mechanisms active at the same time. > >Another way would for the layers themselves contain a 'cancel layer' >operation, which may only be used just before negotiating a new layer >and before closing the connection. Then the SASL negotiation could be >performed without mixing the old and the new SASL mechanism, and the >layer could only be re-negotiated if the old layer had such a 'cancel >layer' operation. > > Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 11:43:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh7I7026999 for ; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IIh72l026998 for ietf-sasl-bks; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh5I7026992 for ; Sat, 18 Oct 2003 11:43:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 19:43:25 +0100 Message-ID: <3F915345.8070201@isode.com> Date: Sat, 18 Oct 2003 15:50:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>>4.1. Authentication protocol exchange >>>> >>>> A SASL mechanism is responsible for conducting an authentication >>>> protocol exchange. This consists of a series of server challenges >>>> and client responses, >>>> >>>> >>>> >>>Does this mean that the initial auth command from the client is not >>>considered part of the authentication protocol exchange? >>> >>> >>> >>Does it matter in this section? >> > >Well, that's where "authentication protocol exchange" seems to be >defined. It matters if other documents refer to "the authentication >protocol exchange". > >Anyway, I think I found the answer in section 6.1. The initial auth >command from the client is not part of the exchange, but the optional >"response" in the auth command is. > Sorry, this makes little sense to me. Semantically the initial response *is* part of an authentication exchange. It is just an optimization to avoid a round trip. > > >>>>4.2. Authorization identities and proxy authentication >>>> >>>> (...) >>>> The character encoding scheme used for transmitting an authorization >>>> identity over protocol is specified in each authentication mechanism >>>> (with the authentication mechanism's blob being further >>>> >>>> >>> ^^^^ >>> >>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>like the dictionary says:-) >>> >>> >>I've changed this to "data". >> >> > >I still don't know _which_ data you are talking about. > > Data is defined (and specific to) by each SASL mechanism. >>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>top. >>> >>> >>> >>I've added a sentence about this in the introduction section. >> >> > >I'm pretty sure you will still need to insert the words "Obsoletes: rfc >2222" in the header sometime, though I don't remember where this is >stated. > I think this is going to be added by a RFC editor. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 12:57:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJvAI7029677 for ; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IJvAxB029676 for ietf-sasl-bks; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJv4I7029670 for ; Sat, 18 Oct 2003 12:57:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 20:57:18 +0100 Message-ID: <3F919B07.6050909@isode.com> Date: Sat, 18 Oct 2003 20:56:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 04:52 AM 10/8/2003, Alexey Melnikov wrote: > > >>>> In >>>> order to avoid noninteroperability due to differing normalizations, >>>> when a mechanism specifies that a string authentication identity or >>>> password used as input to a cryptographic function (or used for >>>> comparison) it SHOULD specify that the string first be prepared using >>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>> [StringPrep]. This should be done by both the client (upon getting >>>> user input or retrieving a value from configuration) and by the >>>> server (upon receiving the value from the client). >>>> >>>> >>>> >>>What's the point of this duplicate preparation? Why not do it only >>>at the server side? >>> >>> >>> >>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> > >Alexey, the current text suggests that client (1) prep the >value before sending, the server then preps it (2) again >(before comparing it to the store value, which also should >be prep'ed (3) either before storing it or before each compare). > Ok, I am with you now. IMHO, as a server writer, I would do (2) anyway. But of course this is my personal opinion. However there is one case when all three may make sense. Imagine that there are two clients that use PLAIN. One of the prepares username/password, the other one doesn't. If the server also does preparation, it will be able to interoperate with both clients. > >We need to REQUIRE that mechanisms specify how character strings >are to be prepared for comparison and RECOMMEND that they use >SASLprep for simple user names and passwords. > >We should not suggest that mechanisms should do both (1) and >(2). (1) and (3) OR (2) or (3) are sufficient to ensure >proper matching. > IMHO, this is a responsibility of the client, so I will clarify that. But I will add that the server "MAY prepare". Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 13:06:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6rI7029838 for ; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IK6rm5029837 for ietf-sasl-bks; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6lI7029831 for ; Sat, 18 Oct 2003 13:06:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:07:07 +0100 Message-ID: <3F919D54.7070306@isode.com> Date: Sat, 18 Oct 2003 21:06:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> In-Reply-To: <3F919B07.6050909@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > >>>>> In >>>>> order to avoid noninteroperability due to differing normalizations, >>>>> when a mechanism specifies that a string authentication identity or >>>>> password used as input to a cryptographic function (or used for >>>>> comparison) it SHOULD specify that the string first be prepared using >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>> [StringPrep]. >>>> The new text after that reads: There are three entities that has to deal with this issue: a client (upon getting user input or retrieving a value from configuration), a server (upon receiving the value from the client) and a utility that is able to store passwords/hashes in a database that can be later used by the server. The preparation must be done by the client and the utility and may be done by the server. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. >>>>> This should be done by both the client (upon getting >>>>> user input or retrieving a value from configuration) and by the >>>>> server (upon receiving the value from the client). >>>>> >>>> >>>> What's the point of this duplicate preparation? Why not do it only >>>> at the server side? >>> >>> Because if the client doesn't do that, the hash calculated on the >>> server will not match the one calculated on the client. >> >> Alexey, the current text suggests that client (1) prep the >> value before sending, the server then preps it (2) again >> (before comparing it to the store value, which also should >> be prep'ed (3) either before storing it or before each compare). > > Ok, I am with you now. > > IMHO, as a server writer, I would do (2) anyway. But of course this is > my personal opinion. > > However there is one case when all three may make sense. Imagine that > there are two clients that use PLAIN. > One of the prepares username/password, the other one doesn't. If the > server also does preparation, it will be able to interoperate with > both clients. > >> We need to REQUIRE that mechanisms specify how character strings >> are to be prepared for comparison and RECOMMEND that they use >> SASLprep for simple user names and passwords. >> >> We should not suggest that mechanisms should do both (1) and >> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >> proper matching. > > IMHO, this is a responsibility of the client, so I will clarify that. > But I will add that the server "MAY prepare". Alexey From owner-ietf-sasl Sat Oct 18 13:10:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAsI7029921 for ; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IKAsvw029920 for ietf-sasl-bks; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAnI7029911 for ; Sat, 18 Oct 2003 13:10:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:10:59 +0100 Message-ID: <3F919E3C.2040504@isode.com> Date: Sat, 18 Oct 2003 21:10:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >Simon raised this issue to me privately... but I think it needs >broader discussion (given that it is a technical issue). > >At 02:19 PM 10/2/2003, Simon Josefsson wrote: > > >>* The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing). >> >> > >That is, what should the implementation do if the message it receives >is malformed? > >I note that this issue is likely not unique to ANONYMOUS. So, maybe >it should be dealt with in base SASL specification. > >I'm thinking a malformed message should be treated as a protocol >error in the application protocol. > I agree. However, can you be more specific what do you want me to add to the base spec. Alexey From owner-ietf-sasl Thu Oct 23 06:14:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEDI7062616 for ; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NDEDrr062615 for ietf-sasl-bks; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEBI7062603 for ; Thu, 23 Oct 2003 06:14:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17392; Thu, 23 Oct 2003 09:14:02 -0400 (EDT) Message-Id: <200310231314.JAA17392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-08.txt Date: Thu, 23 Oct 2003 09:14:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-08.txt Pages : 37 Date : 2003-10-22 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nystrom-http-sasl-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nystrom-http-sasl-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Oct 27 03:08:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB84I7043644 for ; Mon, 27 Oct 2003 03:08:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RB84Cl043643 for ietf-sasl-bks; Mon, 27 Oct 2003 03:08:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB7tI7043626 for ; Mon, 27 Oct 2003 03:08:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Mon, 27 Oct 2003 11:08:03 +0000 Message-ID: <3F9C2F32.1060004@isode.com> Date: Sun, 26 Oct 2003 20:31:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Here are various editorial and non-editorial comments for >draft-ietf-sasl-rfc2831bis-02.txt. > > >>Table of Contents >> >> >> 3.8 CBC MODE ATTACKS............................................. >> >> > >Missing page number. > Yes, I was lazy. I was changing text a lot, so I had to spend a lot of time fixing page numbers when doing each revision. So I just gave up. >>1.1 Conventions and Notation >> >> >> This specification uses the same ABNF notation and lexical >> conventions as HTTP/1.1 specification; see section 7. >> >> > >...as well as some named rules defined there (section 7.2). > 7 implies 7.2. >> The value of a quoted string constant as an octet string does not >> include any terminating null character >> >> > >...which the C language adds. > >[For readers who don't know C, if any.] > > IMHO, readers who don't know C will not care about this comment anyway, because it doesn't add any additional information. >>2.1.1 Step One >> >> The server starts by sending a challenge. >> >> > >How does it know that it should do that? > The client always starts first (according to SASL). If the client doesn't includes an initial response, the server will know. Can you suggest any clarification text here? >> nonce >> Note >> that since the string is passed as a quoted string, the >> double-quote >> >> > >and backslash? > Actually, I've changed ABNF to disallow double-quotes or backslashes. So, this should be removed. >> character is not allowed unless escaped (see section >> 7.2). >> >> > >I think this applies to other quoted strings than the nonce. > Yes, but it is especially problematic for nonces, as people just generate binary data and than forget to quote it. >> server_maxbuf ("maximal ciphertext buffer size") >> >> > > > >> Let call "maximal cleartext buffer size" (or "maximal sender >> size") the maximal size of a cleartext buffer that, after being >> >> > >"Let call"? Should be "Call", or "Let .... be", I think. > Ok. >> charset >> This directive, if present, specifies that the server supports >> UTF-8 [UTF-8] encoding for the username, realm and password. If >> present, the username, realm and password are in Unicode, prepared >> using the "SASLPrep" profile [SASLPrep] of the "stringprep" >> algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not >> present, the username, realm and password MUST be encoded in ISO >> 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). >> >> > >There is no username and password sent by the server. Do you mean the >_client_ MUST send them in UTF-8 if "charset" is given by the server? > Yes. >> cipher-opts >> >> >> "qop-options" directive, in which case the "3des" cipher is >> mandatory-to-implement. >> >> > >I suggest you remove the "-"s in mandatory-to-implement. > This is a term used in SASL. By using "-" I am trying to emphasize this. >>2.1.2 Step Two >> >> >> digest-uri >> Indicates the principal name of the service with which the client >> wishes to connect, formed from the serv-type, host, and serv-name. >> For example, the FTP service on "ftp.example.com" would have a >> "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from >> the example above would have a "digest-uri" value of >> "SMTP/mail3.example.com/example.com". >> >> Servers SHOULD check that the supplied value is correct. This will >> detect accidental connection to the incorrect server, as well as some >> redirection attacks. It is also so that clients will be trained to >> provide values that will work with implementations that use a shared >> back-end authentication service that can provide server >> authentication. >> >> The serv-type component should match the service being offered. The >> host component should match one of the host names of the host on >> which the service is running, or it's IP address. Servers SHOULD NOT >> normally support the IP address form, because server authentication >> by IP address is not very useful; they should only do so if the DNS >> is unavailable or unreliable. The serv-name component should match >> one of the service's configured service names. >> >> This directive may appear at most once; if multiple instances are >> present, the client should abort the authentication exchange. >> >> Note: In the HTTP use of Digest authentication, the digest-uri is the >> URI (usually a URL) of the resource requested -- hence the name of >> the directive. >> >> > >Is this entire section about digest-uri? If so, most of it should be >indented. > > >> authzid >> >> >> The server SHOULD verify the correctness of an authzid as >> specified by the corresponding SASL protocol profile. >> >> > >Which corresponding SASL profile? > I meant that any protocol using SASL should verify authorization identity as specified in the SASL profile for the protocol. Any suggestion how to make this clear? >>2.2 Subsequent Authentication >> >> If the client has previously authenticated to the server, and >> remembers the values of username, realm, nonce, nonce-count, cnonce, >> >> > ^^^^^^^^ > > >> and qop that it used in that authentication, and the SASL profile for >> a protocol permits an initial client response, then it MAY perform >> "subsequent authentication", as defined in this section. >> >> > >What's the point of authenticating again with the same username? Auth >with a _different_ username would be more interesting. > This is a case of fast reauthentication using a different TCP connection. This is similar to resuming a TLS session. >>2.2.2 Step Two >> >> >> If the response is valid, the server MAY choose to deem that >> authentication has succeeded. However, if it has been too long since >> the previous authentication, or for any o including the next >> subsequent authentication, between the client and the server MUST be >> integrity protected. >> >> > >I don't understand the text starting with "or from any o". > The text in my copy says: If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication. So I am not sure where have you found this. >> Using as a base session key the value of H(A1) >> as defined above >> >> > >need a "," here > Ok. >> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >> received value; the message is discarded if they differ. >> >> The >> receiver's sequence counter is incremented if they match. >> >> > >Doesn't the server send a response? How does the client know that the >authentication is completed? > This whole section talks about protecting data when authentication is already complete. > ... > >>5.1 Normative references >> >> >> [RFC 2222] Myers, J., "Simple Authentication and Security Layer >> (SASL)", RFC 2222, October 1997. >> >> > >Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > Fixed, thanks. >... > >> ( *LWS element *( *LWS "," *LWS element )) >> >> > >Should this really be asymmetric, or should it be > ( element *( *LWS "," *LWS element )) >or > ( *LWS element *( *LWS "," *LWS element ) *LWS ) > I can go for the last proposal. At least it seems to be the original intent. >? > > > >>7.2 Basic Rules >> >> > > > >> OCTET = >> >> > >s/character/byte/, I think. > I actually disagree in this case. A byte has 8 bits by definition. > A byte in a multi-byte UTF-8 character >is not normally considered a character. > I am not talking about Unicode characters here. Thank you for your comments. In the meantime I will work (and think more) on the rest of them. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ From owner-ietf-sasl Mon Oct 27 11:03:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3wI7068824 for ; Mon, 27 Oct 2003 11:03:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJ3w5U068823 for ietf-sasl-bks; Mon, 27 Oct 2003 11:03:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3pI7068808 for ; Mon, 27 Oct 2003 11:03:52 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECec-0003C4-9J; Mon, 27 Oct 2003 20:03:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECeZ-00026i-JM; Mon, 27 Oct 2003 20:03:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECeZ-00023k-00; Mon, 27 Oct 2003 20:03:47 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:03:47 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>1.1 Conventions and Notation >>> >>> This specification uses the same ABNF notation and lexical >>> conventions as HTTP/1.1 specification; see section 7. >> >>...as well as some named rules defined there (section 7.2). >> > 7 implies 7.2. True. Please add '...and named rules', though. Those are not notation or lexical conventions. >>> The value of a quoted string constant as an octet string does not >>> include any terminating null character >> >>...which the C language adds. >> >>[For readers who don't know C, if any.] >> > IMHO, readers who don't know C will not care about this comment anyway, > because it doesn't add any additional information. Disagree. For such readers, this comment adds a confusing reference to a null character which they can't find elsewhere in the draft. It might be better to just delete the sentence, though. >>>2.1.1 Step One >>> >>> The server starts by sending a challenge. >> >>How does it know that it should do that? >> > The client always starts first (according to SASL). If the client > doesn't includes an initial response, the server will know. > > Can you suggest any clarification text here? 'The server starts by sending a challenge after the client indicates that SASL negotiatin should start'? >>>2.1.2 Step Two >>> authzid >>> >>> >>> The server SHOULD verify the correctness of an authzid as >>> specified by the corresponding SASL protocol profile. >>> >>> >> >>Which corresponding SASL profile? >> > I meant that any protocol using SASL should verify authorization > identity as specified in the SASL profile for the protocol. Any > suggestion how to make this clear? Using your words, The server SHOULD verify the correctness of an authzid as specified by the SASL profile for the protocol. >>>2.2 Subsequent Authentication >>> >>> If the client has previously authenticated to the server, and >>> remembers the values of username, realm, nonce, nonce-count, cnonce, >> ^^^^^^^^ >>> and qop that it used in that authentication, and the SASL profile for >>> a protocol permits an initial client response, then it MAY perform >>> "subsequent authentication", as defined in this section. >> >>What's the point of authenticating again with the same username? Auth >>with a _different_ username would be more interesting. >> > This is a case of fast reauthentication using a different TCP > connection. This is similar to resuming a TLS session. Oh. Could you add 'even after closing the connection and reopening a new one' in section 2.2? >>>2.2.2 Step Two >>> >>> If the response is valid, (...) >> >>I don't understand the text starting with "or from any o". >> > The text in my copy says: > > (...) Thanks. > So I am not sure where have you found this. It's in http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt. >>> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >>> received value; the message is discarded if they differ. >>> (...) >> > This whole section talks about protecting data when authentication is > already complete. Not in the published draft. There, this sentence occurs in section 2.2.2. But there is no section between 2.2.2 and 2.4, so I guess this part of the published draft got garbled. >>>7.2 Basic Rules >> >>> OCTET = >> >>s/character/byte/, I think. >> > I actually disagree in this case. A byte has 8 bits by definition. No it hasn't. That's why the term 'octet' was invented. A byte is an addressable machine unit, which is _usually_ 8 bits nowadays. >> A byte in a multi-byte UTF-8 character >>is not normally considered a character. >> > I am not talking about Unicode characters here. A 'character' is part of a character set. Which character set is it supposed to be part of here, if not UTF-8? Maybe you are thinking of C, where the 'byte' type is called (unsigned) char? -- Hallvard From owner-ietf-sasl Mon Oct 27 11:15:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFQI7069534 for ; Mon, 27 Oct 2003 11:15:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJFQxt069533 for ietf-sasl-bks; Mon, 27 Oct 2003 11:15:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFPI7069525 for ; Mon, 27 Oct 2003 11:15:25 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AECpm-0004Ni-Ps; Mon, 27 Oct 2003 20:15:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AECpk-0005yD-Mz; Mon, 27 Oct 2003 20:15:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECpj-00025D-00; Mon, 27 Oct 2003 20:15:19 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F919D54.7070306@isode.com> References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:15:19 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >>>>> In > >>>>> order to avoid noninteroperability due to differing normalizations, > >>>>> when a mechanism specifies that a string authentication identity or > >>>>> password used as input to a cryptographic function (or used for > >>>>> comparison) it SHOULD specify that the string first be prepared using > >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm > >>>>> [StringPrep]. > >>>> > The new text after that reads: > > There are three entities that has to deal with this issue: a client > (upon getting user input or retrieving a value from configuration), a server > (upon receiving the value from the client) and a utility that is able to > store > passwords/hashes in a database that can be later used by the server. > The preparation must be done by the client and the utility and may be > done by the > server. If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. I like Kurt's suggestion better: The mechanism must define where preparation is done. That way clients using mechanisms like PLAIN can leave as much work as possible to the server. >>> Alexey, the current text suggests that client (1) prep the >>> value before sending, the server then preps it (2) again >>> (before comparing it to the store value, which also should >>> be prep'ed (3) either before storing it or before each compare). >> >> Ok, I am with you now. >> >> IMHO, as a server writer, I would do (2) anyway. But of course this is >> my personal opinion. I see no reason to prepare a string which we know already has been prepared (if the client works correctly). I guess it doesn't hurt to allow that, but what you are saying is that if the client sends incorrect data (it doesn't prepare when it should do so), auth on your server would succeed anyway. Put that way, I'm not sure if that is a bug or a feature. BTW, the server can't do (2) with mechanisms like DIGEST-MD5, where it never sees the plain password from the client. I got that wrong too in my original message. >>> We should not suggest that mechanisms should do both (1) and >>> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >>> proper matching. >> >> IMHO, this is a responsibility of the client, Disagree. It's the responsibility of the mechanism defintion to say where it should happen. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:21:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL8I7069814 for ; Mon, 27 Oct 2003 11:21:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJL8U0069813 for ietf-sasl-bks; Mon, 27 Oct 2003 11:21:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL6I7069806 for ; Mon, 27 Oct 2003 11:21:07 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AECvJ-0004vJ-MX; Mon, 27 Oct 2003 20:21:05 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AECvG-0006ok-AO; Mon, 27 Oct 2003 20:21:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECvG-00025S-00; Mon, 27 Oct 2003 20:21:02 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F915345.8070201@isode.com> References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:21:02 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >>>Hallvard B Furuseth wrote: >>> >>>>>4.1. Authentication protocol exchange >>Anyway, I think I found the answer in section 6.1. The initial auth >>command from the client is not part of the exchange, but the optional >>"response" in the auth command is. >> > Sorry, this makes little sense to me. > Semantically the initial response *is* part of an authentication > exchange. That's what I wrote. >>>>>4.2. Authorization identities and proxy authentication >>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an authorization >>>>> identity over protocol is specified in each authentication mechanism >>>>> (with the authentication mechanism's blob being further >>>> ^^^^ >>>> >>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>like the dictionary says:-) >>>> >>>I've changed this to "data". >> >>I still don't know _which_ data you are talking about. >> > Data is defined (and specific to) by each SASL mechanism. Is the text in the ()'s just saying that the SASL mechanism restricts the data sent between client and server to more than just being random strings in the character encoding scheme? Well, of course. Why mention that at all? If not, I still don't understand what this () is saying. >>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>top. >>>> >>>I've added a sentence about this in the introduction section. >> >>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>2222" in the header sometime, though I don't remember where this is >>stated. >> > I think this is going to be added by a RFC editor. > > I couldn't find anything saying so. I did find rfc2223 (Instructions > to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks > you to insert. rfc2223 does say that the RFC Editor may make some > changes, but preferably as few as possible, and it doesn't mention > that one. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:23:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNJI7069893 for ; Mon, 27 Oct 2003 11:23:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJNIm9069892 for ietf-sasl-bks; Mon, 27 Oct 2003 11:23:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNHI7069885 for ; Mon, 27 Oct 2003 11:23:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECxQ-00059f-K2; Mon, 27 Oct 2003 20:23:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECxN-0004NX-58; Mon, 27 Oct 2003 20:23:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECxM-00025m-00; Mon, 27 Oct 2003 20:23:12 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3F8D34E4.4020607@isode.com> References: <3F8D34E4.4020607@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:23:12 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2222bis section 6.3 "Multiple authentications" says: >> >> If a security layer is in effect >> and a subsequent SASL negotiation selects a second security layer, >> then the second security layer replaces the first. If a security >> layer is in effect and a subsequent SASL negotiation selects no >> security layer, the original security layer must be removed. >> >>Exactly when is the old layer canceled? >> >>If an old layer is active and the client starts to negotiate a new >>layer, it may not know when to expect the response from the server. >>So the layer can't be canceled by starting a new negotiation. >> > No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully. OK. Please mention that explicitly. > Each profile document must document exactly when this takes place. 'this' = 'it completed successfully', I take it. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:25:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPCI7069974 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJPCP5069973 for ietf-sasl-bks; Mon, 27 Oct 2003 11:25:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPBI7069966 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AECzG-0005M0-Be; Mon, 27 Oct 2003 20:25:10 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AECzD-0004YS-Ja; Mon, 27 Oct 2003 20:25:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECzD-00025o-00; Mon, 27 Oct 2003 20:25:07 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token In-Reply-To: <3F8D308B.5050208@isode.com> References: <3F8D308B.5050208@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:25:07 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2831bis 2.1.1 "Step One" says: >> >> qop-options = "qop" "=" <"> qop-list <"> >> qop-list = 1#qop-value >> qop-value = "auth" | "auth-int" | "auth-conf" | >> token >> >>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>"auth", "auth-int" and "auth-conf", but not when it is . > > Token is specifically for future extensions, if you see a qop value you > don't recognize - you have to ignore it. > If you recognize nothing, you have to fail the authentication exchange. > > Do you want any clarifications on this to be added to the document. Not sure. I think it would be good to mention that 'token is for future extensions' somewhere. And perhaps that these extensions must define A2, since rfc2831bis does not. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:49:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnGI7071153 for ; Mon, 27 Oct 2003 11:49:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJnGCK071152 for ietf-sasl-bks; Mon, 27 Oct 2003 11:49:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnFI7071147 for ; Mon, 27 Oct 2003 11:49:15 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1BDD1515EA; Mon, 27 Oct 2003 14:49:10 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 14:49:10 -0500 In-Reply-To: <3F919B07.6050909@isode.com> (Alexey Melnikov's message of "Sat, 18 Oct 2003 20:56:55 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> IMHO, as a server writer, I would do (2) anyway. But of Alexey> course this is my personal opinion. This needs to be left up to individual mechanisms. The server definitely should not do this. I can think of mechanisms where doing (2) will break signatures of data, etc. For plain, I would probably do all three as you suggest. From owner-ietf-sasl Mon Oct 27 12:02:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2dI7071665 for ; Mon, 27 Oct 2003 12:02:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK2deT071664 for ietf-sasl-bks; Mon, 27 Oct 2003 12:02:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2cI7071659 for ; Mon, 27 Oct 2003 12:02:38 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E4D781515EB; Mon, 27 Oct 2003 15:02:37 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 15:02:37 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 27 Oct 2003 20:21:02 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Alexey Melnikov writes: >> Hallvard B Furuseth wrote: >>> Alexey Melnikov writes: >>>> Hallvard B Furuseth wrote: >>>>>> 4.1. Authentication protocol exchange >>> Anyway, I think I found the answer in section 6.1. The >>> initial auth command from the client is not part of the >>> exchange, but the optional "response" in the auth command is. >>> >> Sorry, this makes little sense to me. Semantically the initial >> response *is* part of an authentication exchange. Hallvard> That's what I wrote. >>>>>> 4.2. Authorization identities and proxy authentication >>>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an >>>>>> authorization >>>>> identity over protocol is specified in each authentication >>>>>> mechanism >>>>> (with the authentication mechanism's blob being further >>>>> ^^^^ >>>>> >>>>> What's a blob? I don't think it's 'something ill-defined or >>>>> amorphous', like the dictionary says:-) >>>>> >>>> I've changed this to "data". >>> I still don't know _which_ data you are talking about. >>> >> Data is defined (and specific to) by each SASL mechanism. Hallvard> Is the text in the ()'s just saying that the SASL Hallvard> mechanism restricts the data sent between client and Hallvard> server to more than just being random strings in the Hallvard> character encoding scheme? Well, of course. Why Hallvard> mention that at all? If not, I still don't understand Hallvard> what this () is saying. Because you want to make it clear to application protocol designers and SASL library implementers that mechanisms will be expected to restrict this data. From owner-ietf-sasl Mon Oct 27 12:08:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8dI7071881 for ; Mon, 27 Oct 2003 12:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK8dnl071880 for ietf-sasl-bks; Mon, 27 Oct 2003 12:08:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8cI7071871 for ; Mon, 27 Oct 2003 12:08:38 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RK7xxA009860; Mon, 27 Oct 2003 12:07:59 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9RK7v58012282; Mon, 27 Oct 2003 13:07:58 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9RK3qQx003840; Mon, 27 Oct 2003 12:03:52 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9RK3oR7003839; Mon, 27 Oct 2003 12:03:50 -0800 (PST) Date: Mon, 27 Oct 2003 12:03:50 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org Cc: nfsv4@ietf.org Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt] Message-ID: <20031027200350.GI24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org, nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Followups-To: nfsv4@ietf.org Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies for the cross-post; followups should NOT be cross-posted this widely. Please Cc ONLY the appropriate WG mailing list(s) on any replies. Since I am not subscribed to all of the relevant WGs' mailing lists, please Cc me in all replies.] The NFSv4 WG I-D on channel bindings needs review from several IETF WGs. This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02). We would appreciate feedback from the Cc'ed WGs on several areas as requested below. Please cc the appropriate WG lists only in your replies. The I-D announcement is included below, including the I-D Abstract. Thanks, Nico Review requests: - From all the cc'ed WGs, the security community in general and the [concluded] CAT WG mailing list: o Please review the generic definition of "channel bindings" in this I-D and the concept of "channel bindings" in general. (Use the CAT WG list and/or the NFSv4 WG list.) - From the IPSEC WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. o Please review the IPsec channel bindings construction. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPSP WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPS WG: o Please consider the channel bindings concept as a general solution to the problems with the iSCSI approach to security ("authenticate at iSCSI layer with x, y or z authentication technology, but delegate session integrity/confidentiality protection to IPsec"). See the introduction (section 1) of this I-D for a description of the problem with the iSCSI approach to security. (I realize that I'm late to the iSCSI party - my goal is not to affect the progression of the iSCSI I-Ds to Proposed Standard and publication as RFCs, far from it.) (Use the IPS WG list.) - From the TLS WG: o Please review the construction of channel bindings to TLS channels given in this I-D. (Use the TLS WG list.) - From the SECSH WG: o Please review the construction of channel bindings to SSHv2 channels given in this I-D. (Use the SECSH WG list.) - From the KRB WG: o Please review sections 3.3 and 4.5 of this I-D. (Use the KRB WG list.) - From the SASL WG: o Please review section 3.2 of this I-D. (Use the SASL WG list.) ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 24 Oct 2003 10:50:50 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt To: IETF-Announce: ; Cc: nfsv4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : On the Use of Channel Bindings to Secure Channels Author(s) : N. Williams Filename : draft-ietf-nfsv4-channel-bindings-00.txt Pages : 14 Date : 2003-10-23 This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-channel-bindings-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- From owner-ietf-sasl Mon Oct 27 13:17:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHXI7074996 for ; Mon, 27 Oct 2003 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLHX22074995 for ietf-sasl-bks; Mon, 27 Oct 2003 13:17:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHRI7074986 for ; Mon, 27 Oct 2003 13:17:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BFF3F1515E8; Mon, 27 Oct 2003 16:17:27 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> <3F867FC1.90704@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 16:17:27 -0500 In-Reply-To: <3F867FC1.90704@isode.com> (Alexey Melnikov's message of "Fri, 10 Oct 2003 10:45:37 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: >> I wonder if it might be better to not to change the protocol >> but, instead, just document the security consideration. >> Alexey> I would like to allow new protocols to allow to deinstall Alexey> the security layer when none is negotiated. RFC 2222 Alexey> prohibits this. Why do you want this? From owner-ietf-sasl Tue Oct 28 12:31:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVXI7003412 for ; Tue, 28 Oct 2003 12:31:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKVXj2003411 for ietf-sasl-bks; Tue, 28 Oct 2003 12:31:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVWI7003405 for ; Tue, 28 Oct 2003 12:31:32 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A83111515E8; Tue, 28 Oct 2003 15:31:33 -0500 (EST) To: Greg Hudson Cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Sam Hartman Date: Tue, 28 Oct 2003 15:31:33 -0500 In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> (Greg Hudson's message of "Mon, 13 Oct 2003 13:19:19 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Greg" == Greg Hudson writes: Greg> * It introduces the concepts of realms, subsequent Greg> authentication, and authorization IDs, none of which seem to Greg> be important functionality for a generic shared-secret Greg> authentication scheme, and all of which could (I think) be Greg> handled out of band. Fortunately, it's not too difficult to Greg> avoid supporting those features. I think the only point you raise that I disagree with is the idea that authorization IDs are not important. I can understand why an implementation might not want to use them, but I believe they are important for protocols to support and are something you will tend to want to add over time to an implementation. From owner-ietf-sasl Tue Oct 28 12:45:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjtI7004136 for ; Tue, 28 Oct 2003 12:45:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjtGB004135 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjrI7004130 for ; Tue, 28 Oct 2003 12:45:54 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25736; Tue, 28 Oct 2003 15:45:43 -0500 (EST) Message-Id: <200310282045.PAA25736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt Date: Tue, 28 Oct 2003 15:45:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-03.txt Pages : 11 Date : 2003-10-28 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 12:45:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjlI7004123 for ; Tue, 28 Oct 2003 12:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjlS8004122 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjjI7004115 for ; Tue, 28 Oct 2003 12:45:46 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25711; Tue, 28 Oct 2003 15:45:36 -0500 (EST) Message-Id: <200310282045.PAA25711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-04.txt Date: Tue, 28 Oct 2003 15:45:35 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-04.txt Pages : 6 Date : 2003-10-28 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 12:46:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk5I7004151 for ; Tue, 28 Oct 2003 12:46:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKk5Ip004150 for ietf-sasl-bks; Tue, 28 Oct 2003 12:46:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk2I7004144 for ; Tue, 28 Oct 2003 12:46:02 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25756; Tue, 28 Oct 2003 15:45:52 -0500 (EST) Message-Id: <200310282045.PAA25756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-03.txt Date: Tue, 28 Oct 2003 15:45:51 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-03.txt Pages : 9 Date : 2003-10-28 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 13:18:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI7I7005384 for ; Tue, 28 Oct 2003 13:18:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLI6FW005383 for ietf-sasl-bks; Tue, 28 Oct 2003 13:18:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI5I7005378 for ; Tue, 28 Oct 2003 13:18:06 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLI6s9014556; Tue, 28 Oct 2003 16:18:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLDWal015702; Tue, 28 Oct 2003 16:13:32 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9SLDVEi010084; Tue, 28 Oct 2003 16:13:31 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9SLDTB9027808; Tue, 28 Oct 2003 16:13:29 -0500 Subject: Re: Some implementor's notes From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067375609.27762.26.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 28 Oct 2003 16:13:29 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > I think the only point you raise that I disagree with is the idea that > authorization IDs are not important. And yet, to the best of my knowledge, they are not introduced by any mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, but they each have different passwords, so they aren't analagous to DIGEST-MD5 authzids.) They are trivial to support by authenticating and then transmitting the desired authzid. So they should either be part of the protocol or part of the SASL framework, but certainly not part of SASL mechanisms. From owner-ietf-sasl Tue Oct 28 13:20:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKhI7005489 for ; Tue, 28 Oct 2003 13:20:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLKhWu005488 for ietf-sasl-bks; Tue, 28 Oct 2003 13:20:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKfI7005483 for ; Tue, 28 Oct 2003 13:20:42 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 28 Oct 2003 21:21:06 +0000 Message-ID: <3F9EDDAB.2080804@isode.com> Date: Tue, 28 Oct 2003 21:20:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt References: <200310282045.PAA25736@ietf.org> In-Reply-To: <200310282045.PAA25736@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) > Author(s) : A. Melnikov > Filename : draft-ietf-sasl-rfc2222bis-03.txt > Pages : 11 > Date : 2003-10-28 > > The updated draft deals with most (but not all) issues raised during WG Last Call. There are some mostly editorial issues left. There was a recent discussion on IMAP mailing list about adding examples to show how to encode initial response when it is/is not supported by the protocol. I will add this in the next revision. I am not going to attend IETF in Minneapolis. What is the planned agenda for the SASL meeting in Minneapolis? Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ From owner-ietf-sasl Tue Oct 28 13:51:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLpCI7006906 for ; Tue, 28 Oct 2003 13:51:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLpBYq006905 for ietf-sasl-bks; Tue, 28 Oct 2003 13:51:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SLpAI7006899 for ; Tue, 28 Oct 2003 13:51:11 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa04663; 28 Oct 2003 16:50 EST Date: Tue, 28 Oct 2003 16:50:44 -0500 From: Jeffrey Hutzelman To: Greg Hudson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <1116100000.1067377844@minbar.fac.cs.cmu.edu> In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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, October 28, 2003 16:13:29 -0500 Greg Hudson wrote: > > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: >> I think the only point you raise that I disagree with is the idea that >> authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, > but they each have different passwords, so they aren't analagous to > DIGEST-MD5 authzids.) They are trivial to support by authenticating and > then transmitting the desired authzid. So they should either be part of > the protocol or part of the SASL framework, but certainly not part of > SASL mechanisms. They're not introduced by this mechanism, either. Authorization identities _are_ part of the SASL framework -- a client may optionally specify the authorization identity he wishes to assume, independent of the authentication identity provided by the mechanism. It is the responsibility of the mechanism to transport the requested authzid, if there is one. -- Jeff From owner-ietf-sasl Tue Oct 28 13:48:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmnI7006761 for ; Tue, 28 Oct 2003 13:48:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLmmeA006760 for ietf-sasl-bks; Tue, 28 Oct 2003 13:48:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmlI7006754 for ; Tue, 28 Oct 2003 13:48:47 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9SLmmk4025751; Tue, 28 Oct 2003 16:48:48 -0500 Date: Tue, 28 Oct 2003 16:48:48 -0500 (EST) From: Rob Siemborski To: Greg Hudson cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Some implementor's notes In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> Message-ID: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> 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: On Tue, 28 Oct 2003, Greg Hudson wrote: > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > > I think the only point you raise that I disagree with is the idea that > > authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. In addition to DIGEST-MD5, the PLAIN, KERBEROS_V4, GSSAPI, SRP, and OTP mechanisms all support authorization identifiers. This certainly isn't something completely new introduced by DIGEST-MD5. > They are trivial to support by authenticating and then transmitting the > desired authzid. So they should either be part of the protocol or part > of the SASL framework, but certainly not part of SASL mechanisms. I admit that hindsight reveals that it would be nice for SASL to be able to support authorization ids as part of the framework -- it would solve the inconsistency introduced by CRAM-MD5. I don't think we really want to do this at the application layer either, since that repeats this work for every SASL application (having application-specific constraints on the authorization ID, however, would be fine). However, I don't think we can abandon the current deployed infrastructure to fix the SASL framework to allow this at this point. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 29 10:44:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi6kT035183 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TIi69Z035182 for ietf-sasl-bks; Wed, 29 Oct 2003 10:44:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi5kT035177 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F80E1515E8; Wed, 29 Oct 2003 13:44:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Agenda items to discuss Message-Id: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Date: Wed, 29 Oct 2003 13:44:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a lot of discussion on the list since the last IETF and I'm curious which issues actually need meeting time. I'd appreciate it if people could suggest issues that still seem to be open. Thing I think may be open or need discussion are: * Initial server challenges especially as they interact with SMTP * Security layer replacement in the base SASL spec * Authorization ID text (data vs blob, confusion about restriction, etc) * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want to develop guidance for protocol designers on this issue? I think most of the other changes that have been brought forward have been resolved; please correct me if I'm wrong. I think Greg's comments on implementing SASL have not suggested any specific changes to documents that need discussion. There's also been a lot of IDN related discussion in the Kerberos working group. So far, I don't think any of that discussion affects saslprep. If any of those issues do end up affecting saslprep, we may at least want to be aware of them. I'll review those discussion within the next week. From owner-ietf-sasl Wed Oct 29 13:58:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwJkT046847 for ; Wed, 29 Oct 2003 13:58:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLwJ3q046846 for ietf-sasl-bks; Wed, 29 Oct 2003 13:58:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwHkT046840 for ; Wed, 29 Oct 2003 13:58:18 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLtZD6012330; Wed, 29 Oct 2003 16:58:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLphSA015781; Wed, 29 Oct 2003 16:51:44 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9TLphMU012960; Wed, 29 Oct 2003 16:51:43 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9TLpfCa028654; Wed, 29 Oct 2003 16:51:41 -0500 Subject: Re: Agenda items to discuss From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067464301.27762.103.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 29 Oct 2003 16:51:41 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-10-29 at 13:44, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I won't be at the meeting, but I'd like to weigh in with the opinion that we shouldn't make it any harder for implementations to do dual encryption of data for defense-in-depth. It may seem redundant and expensive to encrypt or sign twice (and it's certainly fair for an implementation to avoid using a security layer if it's running over TLS), but it's not completely redundant; the keys used for one security layer may be compromisable under different assumptions than the keys used for another. For example: I make a TLS connection to an MIT server and then SASL-authenticate via GSSAPI. Unbeknownst to me, a CA trusted by my client has issued a bogus X.509 certificate for MIT to an attacker. The attacker intercepts my connection, initiates its own connection to the real MIT server, and passes through my communications so that GSSAPI authentication succeeds. If my client insists on using a SASL security layer, the attacker will not be able to modify (or perhaps even read) my communications despite having compromised TLS. I'm not sure if anyone was seriously considering disallowing dual security layers, but RFC 3080 section 4.1 does so, so it seemed worth heading off. > I think most of the other changes that have been brought forward have > been resolved; please correct me if I'm wrong. I think Greg's > comments on implementing SASL have not suggested any specific changes > to documents that need discussion. Correct; I hope my comments will be kept in mind for future work, but they don't have any ramifications for current documents. (And, apologies for the misconception about authzids. I still feel they should have appeared within the framework and not within mechanisms, but I was wrong to assume that they were specific to DIGEST-MD5.) From owner-ietf-sasl Wed Oct 29 14:55:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtKkT049836 for ; Wed, 29 Oct 2003 14:55:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMtKOS049835 for ietf-sasl-bks; Wed, 29 Oct 2003 14:55:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtJkT049828 for ; Wed, 29 Oct 2003 14:55:19 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TMtGxA014090; Wed, 29 Oct 2003 14:55:16 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TMtG58017978; Wed, 29 Oct 2003 15:55:16 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TMpAQx010060; Wed, 29 Oct 2003 14:51:10 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TMp9Jc010059; Wed, 29 Oct 2003 14:51:09 -0800 (PST) Date: Wed, 29 Oct 2003 14:51:09 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031029225109.GB24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I think this should be discussed. I think the guidance we want to give is: don't delegate session protection from one layer to another without confirming that the end-points at both layers are the same. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt It would be nice if SASL had a channel bindings facility. Such a facility could be added or applications could be encouraged to exchange channel bindings data integrity protected at the SASL layer. Can GSS-API channel bindings facility be used when using the GSS-* SASL mechanisms? Cheers, Nico -- From owner-ietf-sasl Wed Oct 29 15:44:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiakT052523 for ; Wed, 29 Oct 2003 15:44:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNiaKH052522 for ietf-sasl-bks; Wed, 29 Oct 2003 15:44:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiYkT052517 for ; Wed, 29 Oct 2003 15:44:35 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TNiUY9001498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Oct 2003 18:44:33 -0500 (EST) Message-ID: <3FA050DA.9000702@columbia.edu> Date: Wed, 29 Oct 2003 18:44:26 -0500 From: "Jeffrey Altman [Kermit Project Volunteer]" Reply-To: ietf-sasl@imc.org Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > > >>* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >>to develop guidance for protocol designers on this issue? >> >> > >I think this should be discussed. > >I think the guidance we want to give is: don't delegate session >protection from one layer to another without confirming that the >end-points at both layers are the same. > >See: > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > > >It would be nice if SASL had a channel bindings facility. Such a >facility could be added or applications could be encouraged to exchange >channel bindings data integrity protected at the SASL layer. > >Can GSS-API channel bindings facility be used when using the GSS-* SASL >mechanisms? > >Cheers, > >Nico > > I second this sentiment. We need to provide advice on how the underlying session security can be validated as part of the SASL authentication OR after the authentication by exchanging messages using the SASL Security Layer which can be then be turned off if validation was successful. Jeffrey Altman From owner-ietf-sasl Wed Oct 29 15:48:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052767 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNmMVb052766 for ietf-sasl-bks; Wed, 29 Oct 2003 15:48:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052738 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TNmJxA004621; Wed, 29 Oct 2003 15:48:19 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TNmI2o023242; Wed, 29 Oct 2003 16:48:18 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TNiCQx022365; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TNiCMe022364; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Date: Wed, 29 Oct 2003 15:44:12 -0800 From: Nicolas Williams To: ietf-sasl@imc.org Cc: Sam Hartman Subject: Re: Agenda items to discuss Message-ID: <20031029234412.GF24528@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org, Sam Hartman References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> <3FA050DA.9000702@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA050DA.9000702@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 06:44:26PM -0500, Jeffrey Altman [Kermit Project Volunteer] wrote: > Nicolas Williams wrote: > [...] > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > [...] > I second this sentiment. We need to provide advice on how the > underlying session security can be validated as part of the SASL > authentication OR after the authentication by exchanging messages using > the SASL Security Layer which can be then be turned off if validation > was successful. Note that I did post a request for this and other WGs to review the channel bindings draft. There is a section in that I-D about SASL, BTW. Cheers, Nico -- From owner-ietf-sasl Wed Oct 29 16:05:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05DkT053844 for ; Wed, 29 Oct 2003 16:05:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U05DhD053842 for ietf-sasl-bks; Wed, 29 Oct 2003 16:05:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05BkT053836 for ; Wed, 29 Oct 2003 16:05:11 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9U05CE7016851; Wed, 29 Oct 2003 19:05:12 -0500 Date: Wed, 29 Oct 2003 19:05:11 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org cc: mrc@CAC.Washington.EDU Subject: Mark Crispin's comments on draft-ietf-sasl-plain-03.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: Mark had a few comments on the PLAIN draft, mostly centered around the issue of the initial response examples. I tend to agree with his assessments. I'll note (as Kurt did), that this document has already been through the WG last call. a) ACAP is probably not the best choice of protocol for the example, since it is not in wide use. A protocol such as SMTP is probably more appropriate (especially given the trouble we've seen with SMTP implementations getting initial response handling correct). SMTP has the added advantage of having 3 digit response codes that in other have optional text -- though that is not the case in the SASL challenges. b) An example demonstrating plain without using the initial response argument on a protocol that supports it. This would again help to address the implementation problems with the optional initial client send. There are examples in draft-siemborski-rfc2554bis-00.txt (using SMTP) that satisfy this, and could be used. One thing that may also help is to place reminders in mechanism (and protocol) documents that a correct implementation of SASL for a given protocol requires an understanding of the protocol profile, the SASL framework, and the mechanism, and that reading all three documents is necessary to get it right. Of course, in a perfect world, normative references would be enough, but experience seems to be showing this not to be the case. (I'd also like to encourage people again to read over and comment more generally on draft-siemborski-rfc2554bis-00.txt and draft-siemborski-rfc1734bis-00.txt). We're also both planning on being at the SASL WG meeting in Minneapolis, and can discuss this further then. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 29 23:11:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BikT001883 for ; Wed, 29 Oct 2003 23:11:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7BiDN001882 for ietf-sasl-bks; Wed, 29 Oct 2003 23:11:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BhkT001870 for ; Wed, 29 Oct 2003 23:11:43 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U7Bblg099887; Thu, 30 Oct 2003 07:11:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 23:10:51 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: ietf-sasl@imc.org, mrc@CAC.Washington.EDU In-Reply-To: References: 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: At 04:05 PM 10/29/2003, Rob Siemborski wrote: >Mark had a few comments on the PLAIN draft, mostly centered around the >issue of the initial response examples. I tend to agree with his >assessments. I'll note (as Kurt did), that this document has already been >through the WG last call. > >a) ACAP is probably not the best choice of protocol for the example, since >it is not in wide use. A protocol such as SMTP is probably more >appropriate (especially given the trouble we've seen with SMTP >implementations getting initial response handling correct). SMTP has the >added advantage of having 3 digit response codes that in other have >optional text -- though that is not the case in the SASL challenges. I think ACAP is a good choice for illustration of SASL/PLAIN mechanism. No base64, meaningful protocol tokens (instead of numeric codes), and a straightforward/simple syntax. I doubt developers needs to consult the ACAP specific to understand the example. The trouble we've seen with SMTP implementations, I think, make SMTP a particular bad choice for use here. >b) An example demonstrating plain without using the initial response >argument on a protocol that supports it. This would again help to address >the implementation problems with the optional initial client send. I have no objection to adding another example. I'll offer specific text for the WG to consider in a subsequent post. >One thing that may also help is to place reminders in mechanism (and >protocol) documents that a correct implementation of SASL for a given >protocol requires an understanding of the protocol profile, the SASL >framework, and the mechanism, and that reading all three documents is >necessary to get it right. I'll stay on the fence on this one, so I suggest that someone who currently supports adding such offer specific text for WG consideration. Kurt From owner-ietf-sasl Wed Oct 29 23:17:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HjkT004053 for ; Wed, 29 Oct 2003 23:17:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7Hj88004052 for ietf-sasl-bks; Wed, 29 Oct 2003 23:17:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HikT004044 for ; Wed, 29 Oct 2003 23:17:44 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7HeMk021511; Wed, 29 Oct 2003 23:17:45 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7Hemo023689; Wed, 29 Oct 2003 23:17:40 -0800 Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: > I think ACAP is a good choice for illustration of SASL/PLAIN > mechanism. No base64, meaningful protocol tokens (instead of > numeric codes), and a straightforward/simple syntax. It is precisely because ACAP does not use BASE64 and does not use numeric code that makes it unsuitable. IMAP is also unsuitable. > The trouble we've seen with SMTP implementations, I think, make > SMTP a particular bad choice for use here. The trouble with SMTP implementation is the *exact* reason why SMTP examples are needed. You don't need examples for things that people will get right. You need examples for things that people get wrong! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 01:12:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CkkT040821 for ; Thu, 30 Oct 2003 01:12:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U9CktC040819 for ietf-sasl-bks; Thu, 30 Oct 2003 01:12:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CjkT040809 for ; Thu, 30 Oct 2003 01:12:45 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U9Cglg001249; Thu, 30 Oct 2003 09:12:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 01:11:56 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: At 11:17 PM 10/29/2003, Mark Crispin wrote: >On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> I think ACAP is a good choice for illustration of SASL/PLAIN >> mechanism. No base64, meaningful protocol tokens (instead of >> numeric codes), and a straightforward/simple syntax. > >It is precisely because ACAP does not use BASE64 and does not use numeric >code that makes it unsuitable. IMAP is also unsuitable. The sole purpose of the example is to illustrate the syntax and semantics described in Section 2 and this purpose is, in my opinion, best served by avoiding protocol encodings which obfuscate the value of the message production. >> The trouble we've seen with SMTP implementations, I think, make >> SMTP a particular bad choice for use here. > >The trouble with SMTP implementation is the *exact* reason why SMTP >examples are needed. You don't need examples for things that people will >get right. You need examples for things that people get wrong! Some folks have problems getting LDAP/SASL right, so, by your argument, we should include LDAP-based examples in the PLAIN document. The trouble with SMTP implementations of SMTP's SASL profile is more appropriately addressed by revising the SMTP specification. Attempting to address these problems in the PLAIN specification might lead to even more confusion in the SMTP community. Kurt From owner-ietf-sasl Thu Oct 30 06:53:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr9kT065699 for ; Thu, 30 Oct 2003 06:53:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UEr9iQ065698 for ietf-sasl-bks; Thu, 30 Oct 2003 06:53:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr4kT065689 for ; Thu, 30 Oct 2003 06:53:07 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UEqq3w031544; Thu, 30 Oct 2003 09:52:52 -0500 (EST) Message-ID: <3FA12679.3070409@oceana.com> Date: Thu, 30 Oct 2003 09:55:53 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > At 11:17 PM 10/29/2003, Mark Crispin wrote: > >>On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> >>>I think ACAP is a good choice for illustration of SASL/PLAIN >>>mechanism. No base64, meaningful protocol tokens (instead of >>>numeric codes), and a straightforward/simple syntax. >> >>It is precisely because ACAP does not use BASE64 and does not use numeric >>code that makes it unsuitable. IMAP is also unsuitable. > > > The sole purpose of the example is to illustrate the syntax and > semantics described in Section 2 and this purpose is, in my opinion, > best served by avoiding protocol encodings which obfuscate the value > of the message production. I tend to agree. The mechanism docs should only have to worry about the order and contents of the exchanges, not how they are encoded or how the client-first and server-last issues are handled. >>>The trouble we've seen with SMTP implementations, I think, make >>>SMTP a particular bad choice for use here. >> >>The trouble with SMTP implementation is the *exact* reason why SMTP >>examples are needed. You don't need examples for things that people will >>get right. You need examples for things that people get wrong! > > > Some folks have problems getting LDAP/SASL right, so, by your argument, > we should include LDAP-based examples in the PLAIN document. > > The trouble with SMTP implementations of SMTP's SASL profile is more > appropriately addressed by revising the SMTP specification. Attempting > to address these problems in the PLAIN specification might lead to > even more confusion in the SMTP community. I understand why Mark is proposing more examples (to prevent large deployment of incorrect implementations that we all have to deal with), but I have to agree with Kurt that the protocol profile is where comprehensive examples belong. RFC 2222[bis] was written so that the protocol profiles and mechanism specifications are orthogonal. In fact, the PLAIN doc shouldn't have to worry about whether particular protocols support an initial response or not. RFC 2222bis describes how to handle this, and the protocol profile should describe how to implement it. No matter how you slice it, any good/responsible implementer is going to *have* to read three docs. I think that encouraging/enforcing this point is more important than cross-pollinating the docs with the same info. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 30 07:48:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmUkT068901 for ; Thu, 30 Oct 2003 07:48:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UFmUTg068900 for ietf-sasl-bks; Thu, 30 Oct 2003 07:48:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmTkT068893 for ; Thu, 30 Oct 2003 07:48:29 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRmw032022; Thu, 30 Oct 2003 07:48:27 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRtS032744; Thu, 30 Oct 2003 07:48:27 -0800 Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <3FA12679.3070409@oceana.com> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: On Thu, 30 Oct 2003, Ken Murchison wrote: > No matter how you slice it, any good/responsible implementer is going to > *have* to read three docs. I think that encouraging/enforcing this > point is more important than cross-pollinating the docs with the same info. Unfortunately, the "good/responsible implementors" do not include the authors of SMTP SASL for qmail, Microsoft Exchange, or for one of China's main SMTP servers (smtp.163.net). People cut corners, skip documents, and make assumptions through empirical tests with existing implementation. I wish that the world was not this way. It is. For people with that mindset, the only thing that you need the SMTP SASL document for is to learn the response codes. Nothing else needs to be read. They don't read 2222 either. "It works with Netscape and Outlook" is their rallying call. I am not of that mindset, but I have spent many weary hours convincing those who have that mindset that their software is broken. Clarifying examples are always good. I understand why you resist examples; I underwent that myself with the IMAP specification. The IMAP specification had to grow enormously to accomodate all the examples that people insisted upon adding. But even I have to acknowledge that the result was better than what was before. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 08:45:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjskT071831 for ; Thu, 30 Oct 2003 08:45:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGjrQs071830 for ietf-sasl-bks; Thu, 30 Oct 2003 08:45:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjqkT071818 for ; Thu, 30 Oct 2003 08:45:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 80E071515E8; Thu, 30 Oct 2003 11:45:55 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> From: Sam Hartman Date: Thu, 30 Oct 2003 11:45:55 -0500 In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> (Nicolas Williams's message of "Wed, 29 Oct 2003 14:51:09 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman Nicolas> wrote: >> * There was some discussion of multiple layers of encryption >> (TLS vs security layers) in XMPP; do we want to develop >> guidance for protocol designers on this issue? Nicolas> I think this should be discussed. Nicolas> I think the guidance we want to give is: don't delegate Nicolas> session protection from one layer to another without Nicolas> confirming that the end-points at both layers are the Nicolas> same. This approach is out of scope for the SASL working group as it cannot be implemented within the current charter. If you want to discuss the approach on the list, that's fine. However I don't think modifying SASL to gain channel bindings is appropriate for meeting time at the IETF. From owner-ietf-sasl Thu Oct 30 09:00:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0FkT072715 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UH0FcR072714 for ietf-sasl-bks; Thu, 30 Oct 2003 09:00:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0EkT072707 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9UGqKEG032595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 11:52:23 -0500 Date: Thu, 30 Oct 2003 12:00:16 -0500 From: Cyrus Daboo To: Ken Murchison , "Kurt D. Zeilenga" cc: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Message-ID: <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <3FA12679.3070409@oceana.com> References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 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: Hi Ken, --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison wrote: | No matter how you slice it, any good/responsible implementer is going to | *have* to read three docs. Its not just three, in fact it is one (SASL), + one per-mechanism, + one per-protocol. If you're writing an email client, chances are that's going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). Each of those is slightly different in some way. Multiply that by all the mechanisms... | I think that encouraging/enforcing this point | is more important than cross-pollinating the docs with the same info. Again I would like to suggest some kind of "implementer's guide" document for SASL that would provide comprehensive examples for each type of protocol and each mechanism, as well as a list of the common implementation errors that have cropped up. That's not meant to replace having to read and understand each of the other documents, but can be used more as a starting point for multiple protocol implementations etc. I would also like to suggest the possibility of an interop event once the new docs are out so that we can pin down problems related to the new i18n stuff, as well as weed out existing problems. The feedback from that could be used in the implementer's guide too. -- Cyrus Daboo From owner-ietf-sasl Thu Oct 30 09:10:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAokT073611 for ; Thu, 30 Oct 2003 09:10:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHAoGk073610 for ietf-sasl-bks; Thu, 30 Oct 2003 09:10:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAnkT073597 for ; Thu, 30 Oct 2003 09:10:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 30 Oct 2003 17:11:11 +0000 Message-ID: <3FA1460D.6070108@isode.com> Date: Thu, 30 Oct 2003 17:10:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Ken Murchison , "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >Clarifying examples are always good. I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. > Instead of modifying PLAIN, I would rather recommend adding more examples to RFC2222bis or create a new draft "SASL Implementation Considerations" which contains list of common mistakes and compares different profiles. Alexey From owner-ietf-sasl Thu Oct 30 09:49:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075968 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHn5jA075967 for ietf-sasl-bks; Thu, 30 Oct 2003 09:49:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075959 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9UHn1xA026420; Thu, 30 Oct 2003 09:49:01 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9UHn058006952; Thu, 30 Oct 2003 10:49:01 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9UHisQx023663; Thu, 30 Oct 2003 09:44:54 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9UHirAC023662; Thu, 30 Oct 2003 09:44:53 -0800 (PST) Date: Thu, 30 Oct 2003 09:44:53 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031030174453.GI24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 30, 2003 at 11:45:55AM -0500, Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman > Nicolas> wrote: > >> * There was some discussion of multiple layers of encryption > >> (TLS vs security layers) in XMPP; do we want to develop > >> guidance for protocol designers on this issue? > > Nicolas> I think this should be discussed. > > Nicolas> I think the guidance we want to give is: don't delegate > Nicolas> session protection from one layer to another without > Nicolas> confirming that the end-points at both layers are the > Nicolas> same. > Sam> This approach is out of scope for the SASL working group as it Sam> cannot be implemented within the current charter. If you want to Sam> discuss the approach on the list, that's fine. However I don't Sam> think modifying SASL to gain channel bindings is appropriate for Sam> meeting time at the IETF. I don't see how the text from me that you quote could possibly be out of scope for this WG - that text calls for "guidance" - security considerations text. The following text from me which you didn't quote does propose two things, one of which may well be out of scope for the WG - which is fine by me, as long as guidance is given: Nico> It would be nice if SASL had a channel bindings facility. Such a Nico> facility could be added or applications could be encouraged to Nico> exchange channel bindings data integrity protected at the SASL Nico> layer. I can see that adding a channel bindings facility to SASL may be out of scope for this WG. That said, you could argue that the channel bindings I-D itself provides, or should provide, sufficient guidance for developers of SASL application protocols. If so, please review the text in section 3.2 of draft-ietf-nfsv4-channel-bindings-00.txt. Thanks, Nico -- From owner-ietf-sasl Thu Oct 30 09:44:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi5kT075669 for ; Thu, 30 Oct 2003 09:44:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHi56P075668 for ietf-sasl-bks; Thu, 30 Oct 2003 09:44:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi4kT075662 for ; Thu, 30 Oct 2003 09:44:04 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9UHi2lg005675; Thu, 30 Oct 2003 17:44:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 09:43:15 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: At 07:48 AM 10/30/2003, Mark Crispin wrote: >People cut corners, skip documents, and make assumptions through empirical >tests with existing implementation. I wish that the world was not this >way. It is. > >For people with that mindset, the only thing that you need the SMTP SASL >document for is to learn the response codes. Nothing else needs to be >read. They don't read 2222 either. "It works with Netscape and Outlook" >is their rallying call. If they don't read the SASL specification, then any wouldn't read any examples we'd place there. I also note that examples are informative in nature. It should be possible to independently develop interoperable implementations without reading any example. >Clarifying examples are always good. If placed in the appropriate document and don't get in the way of the definitive specification, I would accept that non-redundant clarifying examples are generally good thing. >I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. I think we're resisting attempts to add examples intended to clarify aspects of protocol which are not specified in this document. Clarifying the SMTP, LDAP, IMAP, and other application level protocol specifications is beyond the scope of this document. Kurt From owner-ietf-sasl Thu Oct 30 09:36:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHaekT075028 for ; Thu, 30 Oct 2003 09:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHaePV075023 for ietf-sasl-bks; Thu, 30 Oct 2003 09:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHadkT074955 for ; Thu, 30 Oct 2003 09:36:39 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UHaV3w002180; Thu, 30 Oct 2003 12:36:31 -0500 (EST) Message-ID: <3FA14CD4.6020806@oceana.com> Date: Thu, 30 Oct 2003 12:39:32 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <2147483647.1067515216@[10.0.1.8]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Ken, > > --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison > wrote: > > | No matter how you slice it, any good/responsible implementer is going to > | *have* to read three docs. > > Its not just three, in fact it is one (SASL), + one per-mechanism, + one > per-protocol. If you're writing an email client, chances are that's Right. I was just looking at the SMTP + PLAIN scenario. > going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case > we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). > Each of those is slightly different in some way. Multiply that by all > the mechanisms... > > | I think that encouraging/enforcing this point > | is more important than cross-pollinating the docs with the same info. > > Again I would like to suggest some kind of "implementer's guide" > document for SASL that would provide comprehensive examples for each > type of protocol and each mechanism, as well as a list of the common > implementation errors that have cropped up. That's not meant to replace > having to read and understand each of the other documents, but can be > used more as a starting point for multiple protocol implementations etc. I think this is an excellent idea. I might even be able to volunteer to author or co-author such a document. > I would also like to suggest the possibility of an interop event once > the new docs are out so that we can pin down problems related to the new > i18n stuff, as well as weed out existing problems. The feedback from > that could be used in the implementer's guide too. Another good idea. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 30 10:39:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdakT079630 for ; Thu, 30 Oct 2003 10:39:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIdav6079629 for ietf-sasl-bks; Thu, 30 Oct 2003 10:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdZkT079621 for ; Thu, 30 Oct 2003 10:39:35 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTaZ032355; Thu, 30 Oct 2003 10:39:34 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTEf008294; Thu, 30 Oct 2003 10:39:29 -0800 Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> 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: On Thu, 30 Oct 2003, Kurt D. Zeilenga wrote: > If they don't read the SASL specification, then any wouldn't read any > examples we'd place there. Exactly. That's why it has to be in all the relevant documents, in the hope that the implementor will see the example in the document he chooses to read. > I also note that examples are informative > in nature. It should be possible to independently develop interoperable > implementations without reading any example. I wish that too; but it is unrealistic. > I think we're resisting attempts to add examples intended to clarify > aspects of protocol which are not specified in this document. Clarifying > the SMTP, LDAP, IMAP, and other application level protocol specifications > is beyond the scope of this document. PLAIN is a mechanism which can operate in one of two ways, depending upon whether or not the client supplies initial data. This applies to all application protocols that use SASL. Therefore, this is within the scope of PLAIN. The choice of SMTP instead of ACAP is defensible by the fact that there will be many more SMTP implementations than ACAP implementations. Also, SMTP style interaction is much more typical of Internet protocols than ACAP (or POP3 or IMAP). NNTP and FTP are other examples of such protocols that use SASL now (or are likely to in the future). The fact that a server needs to send something like "334 " (note the trailing space) and nothing else is non-intuitive and surprising. It triggers a "that can't be right" feeling. Therefore, there needs to be explicit examples that say, "yes, it is right". No matter how redundant an example may seem to be, if it prevents a bad implementation then less harm is done by having the example in the document. I regularly deal with individuals who insist that because explicit text isn't in one particular RFC, the associated requirement therefore does not exist -- no matter how many normative documents say otherwise! This is why RFCs 2821 and 2822 spend a considerable amount of effort belaboring points that seem to be in the other document's scope. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 12:05:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5rkT083801 for ; Thu, 30 Oct 2003 12:05:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK5rAf083800 for ietf-sasl-bks; Thu, 30 Oct 2003 12:05:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5qkT083795 for ; Thu, 30 Oct 2003 12:05:52 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 311C31515E8; Thu, 30 Oct 2003 15:05:42 -0500 (EST) To: ietf-sasl@imc.org Subject: Any new lines of thought on the SMTP comments Message-Id: <20031030200542.311C31515E8@konishi-polis.mit.edu> Date: Thu, 30 Oct 2003 15:05:42 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems like we're starting to repeat ourselves somewhat especially on the issue of revising examples in the plain SASL mechanism document. Are there any new positions that have not previously been considered or any misunderstandings that need to be worked out before we conclude that discussion? From owner-ietf-sasl Thu Oct 30 12:04:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4FkT083738 for ; Thu, 30 Oct 2003 12:04:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK4FZa083737 for ietf-sasl-bks; Thu, 30 Oct 2003 12:04:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4EkT083732 for ; Thu, 30 Oct 2003 12:04:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 852C41515E8; Thu, 30 Oct 2003 15:04:03 -0500 (EST) To: Cyrus Daboo Cc: Ken Murchison , "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> From: Sam Hartman Date: Thu, 30 Oct 2003 15:04:03 -0500 In-Reply-To: <2147483647.1067515216@[10.0.1.8]> (Cyrus Daboo's message of "Thu, 30 Oct 2003 12:00:16 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Cyrus" == Cyrus Daboo writes: Cyrus> | I think that encouraging/enforcing this point | is more Cyrus> important than cross-pollinating the docs with the same Cyrus> info. Cyrus> Again I would like to suggest some kind of "implementer's Cyrus> guide" document for SASL that would provide comprehensive Cyrus> examples for each type of protocol and each mechanism, as Cyrus> well as a list of the common implementation errors that Cyrus> have cropped up. That's not meant to replace having to read Cyrus> and understand each of the other documents, but can be used Cyrus> more as a starting point for multiple protocol Cyrus> implementations etc. Why is this preferable to including protocol specific implementation notes in the protocol profile documents? --Sam From owner-ietf-sasl Fri Oct 31 10:56:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuxkT002402 for ; Fri, 31 Oct 2003 10:56:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIuxsZ002401 for ietf-sasl-bks; Fri, 31 Oct 2003 10:56:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuwkT002396 for ; Fri, 31 Oct 2003 10:56:58 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8E2221515E8; Fri, 31 Oct 2003 13:56:57 -0500 (EST) To: Jeffrey Altman Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <3FA2AEBB.1010806@columbia.edu> From: Sam Hartman Date: Fri, 31 Oct 2003 13:56:57 -0500 In-Reply-To: <3FA2AEBB.1010806@columbia.edu> (Jeffrey Altman's message of "Fri, 31 Oct 2003 13:49:31 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Over the last week I have realized that we may have overlooked a Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. As you know, the document has already passed working group last call. So if we are going to make a change we should come to consensus soon. To that end, I'm seeking comments on this proposed change from the working group. From owner-ietf-sasl Fri Oct 31 10:49:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInkkT002152 for ; Fri, 31 Oct 2003 10:49:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VInkCN002151 for ietf-sasl-bks; Fri, 31 Oct 2003 10:49:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInikT002141 for ; Fri, 31 Oct 2003 10:49:45 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VInc2D007562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 13:49:42 -0500 (EST) Message-ID: <3FA2AEBB.1010806@columbia.edu> Date: Fri, 31 Oct 2003 13:49:31 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: SASLPrep vs Full Stop code points Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. The Full Stop code points U+002E (full stop) U+3002 (ideographic full stop) U+FF0E (fullwidth full stop) U+FF61 (halfwidth ideographic full stop). do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). Jeffrey Altman From owner-ietf-sasl Fri Oct 31 10:58:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwnkT002504 for ; Fri, 31 Oct 2003 10:58:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIwnVs002503 for ietf-sasl-bks; Fri, 31 Oct 2003 10:58:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwmkT002498 for ; Fri, 31 Oct 2003 10:58:48 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VIwkPh002018; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VIwj58003633; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9VIseQx027506; Fri, 31 Oct 2003 10:54:40 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9VIsdTL027505; Fri, 31 Oct 2003 10:54:39 -0800 (PST) Date: Fri, 31 Oct 2003 10:54:39 -0800 From: Nicolas Williams To: Sam Hartman Cc: Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <20031031185439.GH27412@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov References: <3FA2AEBB.1010806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Oct 31, 2003 at 01:56:57PM -0500, Sam Hartman wrote: > >>>>> "Jeffrey" == Jeffrey Altman writes: > > Jeffrey> Over the last week I have realized that we may have overlooked a > Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. > > As you know, the document has already passed working group last call. > So if we are going to make a change we should come to consensus soon. > To that end, I'm seeking comments on this proposed change from the > working group. I agree with Jeff's point. Nico -- From owner-ietf-sasl Fri Oct 31 11:52:06 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq6kT004431 for ; Fri, 31 Oct 2003 11:52:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJq6M2004430 for ietf-sasl-bks; Fri, 31 Oct 2003 11:52:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq5kT004425 for ; Fri, 31 Oct 2003 11:52:05 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 60C6F1515E8; Fri, 31 Oct 2003 14:52:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Consensus call: changing examples from ACAP to SMTP Message-Id: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> Date: Fri, 31 Oct 2003 14:52:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. The discussion seems to have died down on the issue of replacing the ACAP example with an SMTP example in the plain draft. The rough consensus of this working group is that we will not change to an SMTP-based example. We seem to believe that the examples in the plain document should illustrate that mechanisms, not illustrate common implementation errors in other related protocols. I think that we have something approaching a consensus that we will be better served by encouraging implementers to read all the appropriate documents than to include information designed to make sure that implementers will not make mistakes even if they do not read the appropriate documents. That's not as clear as the consensus against changing the example to SMTP; there may be more room for discussion on this issue. Personally I believe that we may want to consider ways in which we can make it clear to implementers what documents they want to read. --Sam From owner-ietf-sasl Fri Oct 31 11:48:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmpkT004281 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJmp7j004280 for ietf-sasl-bks; Fri, 31 Oct 2003 11:48:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmokT004275 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9VJmm5u025885; Fri, 31 Oct 2003 12:48:48 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VJmmru018316; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EFZ0DBUK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Date: Fri, 31 Oct 2003 11:48:48 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EG00DCUK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: CwuEY9WEdIoX6gjf2xZb2Q== Actually, the IDNA specifies that out of the Stringprep and the Nameprep profile; in the similar sense/reasons and to preserve the context of the various full stops as much as possible, it seems the Kerberos extension also need to specify the additional mappings at the extension not at the Stringprep profile and only for the Internet domain-style names. Please see the attached, esp., the issue-1. With regards, Ienup ] Date: Fri, 31 Oct 2003 13:49:31 -0500 ] From: Jeffrey Altman ] Subject: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Over the last week I have realized that we may have overlooked a ] necessary mapping for the SASLPrep: Full Stop code points. ] ] The Full Stop code points ] ] U+002E (full stop) ] U+3002 (ideographic full stop) ] U+FF0E (fullwidth full stop) ] U+FF61 (halfwidth ideographic full stop). ] ] do not have mapping tables in StringPrep and are not mapped in NamePrep ] because IDNA (RFC 3490) uses these characters as an equivalent class of ] label separators. Therefore, they cannot exist in any input to which ] NamePrep would have been applied. ] ] It is my belief that SASLPrep must specify a mapping requiring all Full ] Stop code points to be mapped to U+002E (full stop). ] ] Jeffrey Altman ] ] ] ] ] --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; name=idn-considerations-with-kerberos-extension.txt; charset=us-ascii; x-unix-mode=0644 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=idn-considerations-with-kerberos-extension.txt Content-description: idn-considerations-with-kerberos-extension.txt Content-MD5: VfsNrPuCPZApp138x+c8QQ== 10/23/2003 ienup.sung@sun.com Internationalized Domain Name considerations at Kerberos extension ------------------------------------------------------------------ 1. Overview Many existing implementations and system administrators derive Kerberos Realm and Principal Names from Internet domain-style domain names [1, 2]. While it is rather and relatively a simple task when the coded character set (codeset) is a 7-bit ASCII, when the repertoire of the characters to support increases and have to support various scripts and languages at the same time, the complexity also increases and there are issues that the existing standards have not been anticipated. Furthermore, recent standardization of Internationalized Domain Name (IDN) and accompanying application layer architecture/model called Internationalized Domain Names in Applications (IDNA) [3], further increase the complexity and uncertainty on the compatible support of the IDN. This memo tries to describe what are the surrounding issues when we move to the Unicode character set repertoire and also when we have to support IDN and also have maximum compatibility with the IDNA implementations. This memo does not cover or deal with any other internationalization issues at the moment. The U+XXXX and U+YYYYYY are the usual Unicode notations where the XXXX and the YYYYYY denote code point values in the Unicode coding space. 2. Issues and Possible Resolution Suggestions In my opinion, the following issues should be mentioned at the extension and hopefully with normative assertions/guidelines/recommendations on what should be done: - Issue-1: IDNA allows various label separators such as U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), and U+FF61 (halfwidth ideographic full stop). - Resolution-1: Before such domain-style names be used at the Kerberos implementations to derive the Realm, Principal Names, or both, such label separators should all be mapped to 7-bit ASCII/UTF-8 full-stop character ('.' which is U+002E). This is only for Internet domain-style names. - Issue-2: IDNA allows both ASCII Compatible Encoding (ACE) [3, 5] names and IDN names with 8-bit characters as possible user input. - Resolution-2: The Kerberos extension will use UTF-8 as the codeset of the choice; thus if user input is in ACE which starts with "xn--" prefix, then, such names must be converted back to non-ACE, UTF-8 IDN names through the [3]'s conversion steps before the use. For any IDN names with 8-bit characters with non-UTF-8 codsets/codepages, such names should be must be converted to UTF-8 IDN names before the use if the name is not in the UTF-8. - Issue-3: Since the Nameprep [4] used as the Stringprep [5] profile at the IDNA does the case-folding [7] mappings before the Normalization Form KC (NFKC) [8], the IDNA effectively allows various equivalent IDN names for a domain name (or, hostname for that matter). On the other hand, the SASLprep [9] that will be used by the extension does not employee the case-folding mapping and, as a consequence, generates different results for various equivalent names. - Resolution-3: Before the use, any IDN names with 8-bit characters must be converted to UTF-8 if necessary and then the Nameprep must be applied; this will ensure that the various equivalent names map to a single Realm and Principal names derived. - Issue-4: SASLprep and Nameprep prohibits Private Use Area (PUA) characters and hence denying characters/character codes of user-defined characters commonly used in Asian countries at the Principal names. - Resolution-4: Either accept that as the limitation, update the SASLprep and allow the PUA characters, or come up with a Kerberosprep profile that will allow the PUA characters by omitting the Stringprep Table C.3 from the "Prohibited Output" section. - Issue-5: The clarification [2] defines Realm and PrincipalName be encoded as KerberosString. The KerberosString type includes ACE string by definition. - Resolution-5: To reduce future confusions, the exclusion recommendation of the ACE encoded string at the KerberosString with a rationale is desired preferably at the [2] and also at the extension. If to allow the ACE, then, also ample descriptions on consequences and also additional info should be given at the [2] and the extension. - Issue-6: Case conversions are required for the Principals and Realms; Unicode introduces complications to case mappings due to the character set includes characters from various scripts and languages. - Resolution-6: If the case conversions are also required for the IDN names, they must be done as normative steps for the Realm and Principal Names. In doing so, it is necessary to provide the rules and mapping tables to have the deterministic case conversions; the rules and mappings should come from [7] and standard Unicode data files. Furthermore, considering normalized names are necessary to have deterministic name matchings in my opinion, the case conversions should not be done alone but should be done before or possibly together with the normalization depending on the normalization form that will be used for the Realm and the Principal names. Also, considering there is no mapping tables defined for the case conversions in any of the existing profiles or the Stringprep itself, it appears that the WG should come up with case conversion mapping tables that will be used at the Stringprep profile's mapping step prior to or along with the normalization step. (More investigation and study would required on this issue by the way.) - Issue-7: Unlike case-foldings that can be done in *pretty much* locale- independent way, case conversions can yield and also require different per-locale conversion mappings. - Resolution-7: Either there should be additional mappings at the mapping step of the Stringprep profile that will be used for the extension so that such locale-specific case conversion differences will be erased (in a sense, a small set of case-folding or semi-case-folding, if you will, on certain characters) or allow such per-locale conversions and treat the converted names not equivalent. 3. References [1] RFC 1510 Kerberos [2] Kerberos clarification Internet Draft [3] RFC 3490 IDNA [4] RFC 3491 Nameprep [5] RFC 3492 Punycode [6] RFC 3454 Stringprep [7] UAX21 Case Mappings for Unicode 3.2 [8] UAX15 Unicode Normalization Forms for Unicode 3.2 [9] SASLprep Internet Draft --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)-- From owner-ietf-sasl Fri Oct 31 12:07:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7vkT005240 for ; Fri, 31 Oct 2003 12:07:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VK7vL4005239 for ietf-sasl-bks; Fri, 31 Oct 2003 12:07:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7skT005234 for ; Fri, 31 Oct 2003 12:07:55 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VK7oXL008153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:07:53 -0500 (EST) Message-ID: <3FA2C10E.4080907@columbia.edu> Date: Fri, 31 Oct 2003 15:07:42 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ienup Sung wrote: >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >profile; in the similar sense/reasons and to preserve the context of the various >full stops as much as possible, it seems the Kerberos extension also need to >specify the additional mappings at the extension not at the Stringprep profile >and only for the Internet domain-style names > > I see no justification for while this should be specified at some level above the application of SASLprep. SASLprep is applied to Storage and Query strings for the purpose of ensuring that the strings are equivalent when matching are performed or that the one true form is used as input to cryptographic operations. If the Full Stop must be mapped to U+002E before applying SASLprep, and both operations must always be performed, then it follows that the Full Stop mapping should be part of SASLprep. From owner-ietf-sasl Fri Oct 31 13:07:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7JkT008084 for ; Fri, 31 Oct 2003 13:07:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VL7JbA008083 for ietf-sasl-bks; Fri, 31 Oct 2003 13:07:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7IkT008074 for ; Fri, 31 Oct 2003 13:07:18 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VL7EUP012232; Fri, 31 Oct 2003 13:07:15 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VL7Eru001817; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EIH402UK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Date: Fri, 31 Oct 2003 13:07:14 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EII402UK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: reBJGW8+y0HsYkgyST+BQg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks. I agree with you on the place where the mappings of various full stops to the U+002E (ASCII's full stop) should be done; the best place would be before any Stringprep profile based preparation and iff the name is of Internet domain style names. The reason for the above is that the U+002E isn't equivalent/equal to any other ideographic full stops for all the cases and thus, rather, the ideographic full stops needed to be preserved as they are. One notable exception is of course when they are used as label separators for the Internet domain style names. With regards, Ienup ] Date: Fri, 31 Oct 2003 15:07:42 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Ienup Sung wrote: ] ] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep ] >profile; in the similar sense/reasons and to preserve the context of the various ] >full stops as much as possible, it seems the Kerberos extension also need to ] >specify the additional mappings at the extension not at the Stringprep profile ] >and only for the Internet domain-style names ] > ] > ] I see no justification for while this should be specified at some level ] above the ] application of SASLprep. SASLprep is applied to Storage and Query ] strings for the ] purpose of ensuring that the strings are equivalent when matching are ] performed ] or that the one true form is used as input to cryptographic operations. ] ] If the Full Stop must be mapped to U+002E before applying SASLprep, and ] both ] operations must always be performed, then it follows that the Full Stop ] mapping ] should be part of SASLprep. ] ] ] ] ] From owner-ietf-sasl Fri Oct 31 13:38:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcOkT009280 for ; Fri, 31 Oct 2003 13:38:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLcO3H009279 for ietf-sasl-bks; Fri, 31 Oct 2003 13:38:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcMkT009274 for ; Fri, 31 Oct 2003 13:38:23 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VLcJvO011516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 16:38:21 -0500 (EST) Message-ID: <3FA2D641.7010408@columbia.edu> Date: Fri, 31 Oct 2003 16:38:09 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EII402UK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EII402UK@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204020601030306090208" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050204020601030306090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup: I do not agree with you. You cannot have it both ways. Either the code points are considered to be equivalent in which case they are mapped, or they are not equivalent in which case they cannot be mapped. Please remember that the purpose of SASLPrep is to produce a unique representation of a string which is independent of locale and which can be stored in a database for the purpose of ensuring that it can be queried successfully in the future. Strings which have a String Prep profile applied to them are NOT meant to be used for displaying strings to end users. They are meant only for the purpose of on the wire equivalency. SASLPrep is a string prep profile which specifies all of the steps which must be taken an in which order they are to be taken in order to produce the form to be stored in the database. If there are different classes of strings for which there should be different string prep profiles specified for the different classes. - Jeff Ienup Sung wrote: >Thanks. > >I agree with you on the place where the mappings of various full stops to >the U+002E (ASCII's full stop) should be done; the best place would be before >any Stringprep profile based preparation and iff the name is of Internet domain >style names. > >The reason for the above is that the U+002E isn't equivalent/equal to any >other ideographic full stops for all the cases and thus, rather, the ideographic >full stops needed to be preserved as they are. One notable exception is >of course when they are used as label separators for the Internet domain >style names. > >With regards, > >Ienup > > >] Date: Fri, 31 Oct 2003 15:07:42 -0500 >] From: Jeffrey Altman >] Subject: Re: SASLPrep vs Full Stop code points >] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov >] MIME-version: 1.0 >] Content-transfer-encoding: 7bit >] X-Accept-Language: en-us, en >] X-No-Spam-Score: Local >] X-Scanned-By: MIMEDefang 2.35 >] >] Ienup Sung wrote: >] >] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >] >profile; in the similar sense/reasons and to preserve the context of the >various >] >full stops as much as possible, it seems the Kerberos extension also need to >] >specify the additional mappings at the extension not at the Stringprep profile >] >and only for the Internet domain-style names >] > >] > >] I see no justification for while this should be specified at some level >] above the >] application of SASLprep. SASLprep is applied to Storage and Query >] strings for the >] purpose of ensuring that the strings are equivalent when matching are >] performed >] or that the one true form is used as input to cryptographic operations. >] >] If the Full Stop must be mapped to U+002E before applying SASLprep, and >] both >] operations must always be performed, then it follows that the Full Stop >] mapping >] should be part of SASLprep. >] >] >] >] >] > > --------------ms050204020601030306090208 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIxMzgwOVowIwYJKoZIhvcNAQkEMRYEFAZO3rSkm38d 8XqTifdq2LESwzJDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAoT9RMvowLOhLzoBNBC3C09F0YtWW vq9K1HrRy0GHVE6Fn3fufAXY1vb6wzculOoyGZehTIYfGqxhDh0Gn+rNMbZRpx2bLT65bn4f ZthYTO1wG6ErEreuhcqQ8gsvRphSdukOqsNwa3md7LeiUjwPeSkTVgX9AReiAB0XBJDAgKb9 dJaFhR54XLES+mchR0YTl1Ta+2EILkdJOdvBbs5DHjkveDAsZTd3u2+A3fBuCKMOrWJFvPPk GT4D9WqhHQ9yz2iHTbL23SUE7+A2ceUrx9/FLcEN2Xbbk1hLfE/v2rCED+edplTFX/yLyxVg nDeRxjfMJIXZQTTxbXAHD2/2MQAAAAAAAA== --------------ms050204020601030306090208-- From owner-ietf-sasl Fri Oct 31 13:51:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLpckT009725 for ; Fri, 31 Oct 2003 13:51:38 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLpcSQ009724 for ietf-sasl-bks; Fri, 31 Oct 2003 13:51:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VLpbkT009716 for ; Fri, 31 Oct 2003 13:51:37 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa10252; 31 Oct 2003 16:50 EST Date: Fri, 31 Oct 2003 16:50:59 -0500 From: Jeffrey Hutzelman To: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Friday, October 31, 2003 11:48:48 -0800 Ienup Sung wrote: > Actually, the IDNA specifies that out of the Stringprep and the Nameprep > profile; in the similar sense/reasons and to preserve the context of the > various full stops as much as possible, it seems the Kerberos extension > also need to specify the additional mappings at the extension not at the > Stringprep profile and only for the Internet domain-style names. Please bear in mind that when we discuss saslprep, we're not just talking about Kerberos; we're also talking about the whole range of SASL mechansims which also use the SASLprep profile for their authentication ID's or for other strings, and any SASL applications which use the SASLprep profile on authzids. Also, since you're apparently not familiar with the history, I'll point out that there is a simple reason why Kerberos uses the SASLprep profile. Both groups recently had need for stringprep profiles, and began to develop requirements and produce documents. As things progressed, we noticed that we were essentially writing exactly the same profile twice. So, after some investigation to determine that we had essentially the same needs, we agreed to combine the work and produce a single document. The folks you've been discussing IDN issues with over in krb-wg were part of this process. Further, I'll point out to the others reading the fundamental point that you try to make, which may have been missed -- it may be desirable to map U+3002, U+FF0E, and U+EE61 to U+002E _only_ in the context of domain names (where it is required), and not in other contexts. Doing that would indeed require that the work of mapping be done other than in SASLprep. Nameprep does not specify mapping for the full stop characters Jeff mentioned, not out of a desire to "preserve context", but because Nameprep applies to individual DNS labels, and the full stop characters are not permitted in such labels in order to avoid confusion when full domain names are represented as strings with "." separating the labels. IDNA (specifically, RFC3490) has the following to say: 1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). It also requires, in the following paragraph, that when dots are used as label separators in a domain name placed into an IDN-unaware domain name slot, the label separator MUST be U+002E, for the simple reason that none of the other possible choices are valid US-ASCII characters. However, this is of relevance only as an indication of intent, since we are NOT presently talking about any domain name slots, IDN-aware or otherwise. One legitimate way to accomplish these requiements is to insure that by the time anything is parsed out as a domain name, all of these characters have been mapped to U+002E (full stop). That is what Jeff is proposing for SASLprep. There are two significant advantages to this approach: (a) It eliminates the need for "special processing" based on whether something is to be treated as a domain name. This is particularly important in Kerberos, because even those strings in Kerberos which may be derived from domain names (certain realm names and principal name components) are _never_ treated as an independent sequence of labels; they are treated as single strings which do, in fact, contain periods. In order for KDB lookups and other operations to succeed, the periods must be consistent. (b) It provides for consistent behaviour over all strings of the relevant types (among them, Kerberos realm names and principal name components, plus the authentication ID's of several SASL mechanisms), rather than giving a different behavour for those strings or parts of strings which may contain or be derived from domain names. However, there is also a disadvantage, which is that this is a mapping based primarily on visual similarity. SASLprep does not presently contain any such mappings, other than the mapping of non-ASCII space characters to U+0020 (space). I believe we came to the conclusion in the process of designing the (now abandoned) Kerberos stringprep profile that such mappings would lead down a vague and inconsistent path of attempting to second-guess the user, and would thus be counterproductive. Section 1.2 of RFC3490 addresses this issue as well. It may be the case that the special use of dots in domain names, combined with the recommendations of RFC3490 on processing certain other full stop characters as domain label separators, justifies special handling in SASLprep. My first inclination was to agree with Jeff and Nico that this was obviously the right answer; after thinking about it for a few minutes, I'm not so sure. In any case, including this mapping in SASLprep will not save us (or applications, or krb5_sname_to_principal, or whatever) from having to recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when constructing principal names or other strings from domain names. This is because Nameprep may only be applied to individual labels, not entire domain names, and thus such names _must_ be split into separate labels at these characters, each label processed separately, and then the name reassembled, presumably using U+002E (full stop) as the label separator. This is effectively a separate processing step that is required any time nameprep is to be applied. -- Jeff From owner-ietf-sasl Fri Oct 31 14:36:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaYkT011065 for ; Fri, 31 Oct 2003 14:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMaYlU011064 for ietf-sasl-bks; Fri, 31 Oct 2003 14:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaXkT011059 for ; Fri, 31 Oct 2003 14:36:33 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9VMaUlg021617; Fri, 31 Oct 2003 22:36:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031142722.02beae80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 14:35:42 -0800 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <3FA2AEBB.1010806@columbia.edu> References: <3FA2AEBB.1010806@columbia.edu> 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: I concur. I suggest the following bullet item be added to Section 2.1 of [SASLPrep]: - the IDEOGRAPHIC FULL STOP (U+3002), FULLWIDTH FULL STOP (U+FF0E), and HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61) characters be mapped to the FULL STOP (U+002E) character. Kurt At 10:49 AM 10/31/2003, Jeffrey Altman wrote: >Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. > >The Full Stop code points > > U+002E (full stop) > U+3002 (ideographic full stop) > U+FF0E (fullwidth full stop) > U+FF61 (halfwidth ideographic full stop). > >do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. > >It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). > >Jeffrey Altman From owner-ietf-sasl Fri Oct 31 14:44:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiNkT011251 for ; Fri, 31 Oct 2003 14:44:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMiNpL011250 for ietf-sasl-bks; Fri, 31 Oct 2003 14:44:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiMkT011244 for ; Fri, 31 Oct 2003 14:44:22 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VMiMXL000293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 17:44:23 -0500 (EST) Message-ID: <3FA2E5BD.7050505@columbia.edu> Date: Fri, 31 Oct 2003 17:44:13 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <2311370000.1067637059@minbar.fac.cs.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060501080504060901060506" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060501080504060901060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > In any case, including this mapping in SASLprep will not save us (or > applications, or krb5_sname_to_principal, or whatever) from having to > recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when > constructing principal names or other strings from domain names. This > is because Nameprep may only be applied to individual labels, not > entire domain names, and thus such names _must_ be split into separate > labels at these characters, each label processed separately, and then > the name reassembled, presumably using U+002E (full stop) as the label > separator. This is effectively a separate processing step that is > required any time nameprep is to be applied. > > -- Jeff The application of SASLprep produces a Storage string or a Query string. These strings are not appropriate for use as Display strings. The distinction between the different forms of "full stops" just like the distinction between "spaces" is important for display strings. I just don't see how they can be important for query and storage strings. There is an on-going battle taking place on the ietf-imaa@ietf.org mailing list. It is a rehashing of all the arguments which have taken place over the last ten years on whether or not internationalization is a good idea. The argument is clearly pointless. Internationalized strings are not just a necessity but a desirable feature. The fundamental problems related to internationalizing protocols have been caused by an attempt to allow the use of Storage Strings as Display Strings. This is wrong. Storage and query strings are meant to be used within wire protocols. Display strings are meant to be used in user interfaces. Their use is different and therefore so are the requirements. I do not see any reason why protocols which rely on SASLprep must allow this misuse. For example, in Kerberos the set/change password protocol and the kdb could very well provide for both a storage string and a display string. The KDC could have a query function which allows any query string to be used to obtain the display string. The KDC would also utilize the display string in error messages when necessary. The purpose of this is to maintain the proper separation between the User Interface and the Wire Protocols. The one requirement is that the string prep'd Display String must equal the string prep'd storage string when the principal is created. - Jeff --------------ms060501080504060901060506 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIyNDQxM1owIwYJKoZIhvcNAQkEMRYEFHAv23S7Pu4w uhvEYdloO+pvTMaRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAvDfjwaR/czI+lxzDJHLD4rnO9uZt Rgmkky4juV8RVyREns+85GvNWjnWim379a3tn1h8JkNEhKPOqBLOeDO1tkMJ5vL7UaW1ByYr jiYRjnhEHCCXl3qlulU/QS8S33DhJLN4vAlMBN20DXEX9PS4GLXvKZbuYMwbTC+AW+ogaONh 3Fis5y3NaMQAU9uocwMxiNNUiAnKbOzP4LD7xKZCr2naA0QTqMFYGE5NOH2L3xNJOwFfKB9l 9GR5o7Qu1eAHLTRi5mRePfvRtvm1Cyu8HSEeV315bct0r2/YbdhR1SiZXrtDMQntIByR+5Z5 LB7bY3kPWDuPW/4dn2kw/MOG9wAAAAAAAA== --------------ms060501080504060901060506-- From owner-ietf-sasl Fri Oct 31 17:42:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gwkT020372 for ; Fri, 31 Oct 2003 17:42:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA11gwo0020369 for ietf-sasl-bks; Fri, 31 Oct 2003 17:42:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gukT020341 for ; Fri, 31 Oct 2003 17:42:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA11gv5u006209; Fri, 31 Oct 2003 18:42:57 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA11gvru018724; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00IIRGRK5B@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Date: Fri, 31 Oct 2003 17:42:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00IISGRK5B@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: egx+Eeie5tdm2UXdN7GdKQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Regarding the full stops, while I do understand the point of display vs. storage/query string in my opinion, I think the issue boils down onto the followign two things in my view: 1. Should/can we treat ideographic/Asian full stops as equivalent characters of the ASCII full stop (U+002E) in 100% of the possible cases/usages? The answer is no since the U+002E is not only a full stop character but it is also a period and dot/decimal point character; CJK speakers do not use the ideographic/Asian full stops as the dot/decimal point character and hence some use of the ideographic/Asian full stops rather be preserved as they are to be distingushed. And in that cases, can we distinguish what to preserve and what not to preserve and map? 2. Should/can we keep the compatiblity with the IDNA's additional and pre-processing on the label separators, i.e., mappings of all full stops to the U+002E, for the domain style (IDN) names before they are used? I think the answer should be yes. I know the above two sound conflicting and the example shown at the argument #1 could be considered as a case that may not need to be really supported. But I thought presenting them might be a valuable thing to do. With regards, Ienup From owner-ietf-sasl Fri Oct 31 20:53:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r3kT025576 for ; Fri, 31 Oct 2003 20:53:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA14r3on025575 for ietf-sasl-bks; Fri, 31 Oct 2003 20:53:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r2kT025570 for ; Fri, 31 Oct 2003 20:53:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA14r3lg027640; Sat, 1 Nov 2003 04:53:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031193854.02b18be8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 20:52:15 -0800 To: Ienup Sung From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <0HNN00IISGRK5B@mpkmail.eng.sun.com> References: <0HNN00IISGRK5B@mpkmail.eng.sun.com> 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: At 05:42 PM 10/31/2003, Ienup Sung wrote: >Regarding the full stops, while I do understand the point of display vs. >storage/query string in my opinion, I think the issue boils down onto >the followign two things in my view: >1. Should/can we treat ideographic/Asian full stops as equivalent characters > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? SASLprep is only applicable to two use cases: simple user names and password. > The answer is no since the U+002E is not only a full stop character but > it is also a period and dot/decimal point character; CJK speakers do not use > the ideographic/Asian full stops as the dot/decimal point character and > hence some use of the ideographic/Asian full stops rather be preserved as > they are to be distingushed. And in that cases, can we distinguish what to > preserve and what not to preserve and map? SASLprep scope is limited to preparation of user input strings for matching. Issues such as how to preserving the (unprepared) user input is simply beyond our scope as matching and hence SASLprep. >2. Should/can we keep the compatiblity with the IDNA's additional and > pre-processing on the label separators, i.e., mappings of all full stops to > the U+002E, for the domain style (IDN) names before they are used? > I think the answer should be yes. SASLprep can define one preparation algorithm for simple user names and passwords. Simple here implies the input has no structure. That is, names have no particular style in respect to the algorithm. It is possible that specification using SASLprep could apply additional transformations be done. However, such transforms are beyond the scope of SASLprep. >I know the above two sound conflicting and the example shown at the argument >#1 could be considered as a case that may not need to be really supported. >But I thought presenting them might be a valuable thing to do. I would be interested in hearing whether you think the additional suggested mapping is appropriate or not for matching of simple user names or passwords, and why. I think this issue boils down to whether the user provided strings: should match or not. Because user names are often constructed from domain names, and IDNA says these stops are to be treated as equivalent, I believe they should match. Kurt From owner-ietf-sasl Wed Oct 1 06:25:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPUKP084014 for ; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91DPUnA084011 for ietf-sasl-bks; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPTKP084005 for ; Wed, 1 Oct 2003 06:25:29 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1A4gyt-0006QG-76 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:27 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1A4gys-00013a-0j for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:26 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4gyr-0004C6-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:25:25 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 1 Oct 2003 15:25:25 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). > > I'm thinking "blob" is not a good word choice here. (...) > I'm thinking "blob" should be replaced with "string". But which string is the draft talking about? -- Hallvard From owner-ietf-sasl Wed Oct 1 06:49:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnjKP085367 for ; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Dnj3Q085366 for ietf-sasl-bks; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnhKP085361 for ; Wed, 1 Oct 2003 06:49:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A4hML-0001VS-TL for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A4hMK-00010R-B0 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4hMK-0004Gr-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:49:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: empty authzid in draft-ietf-sasl-plain-02.txt Date: Wed, 1 Oct 2003 15:49:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: draft-ietf-sasl-plain-02.txt says that The client leaves the authorization identity empty if it wishes the server to derive the authorization identity from the provided authentication identity. and Note that the parameters provided to the Authorize function are not prepared. so I think the pseudo-code for empty authzid should say authzid = DeriveAuthzid(authcid); and not authzid = DeriveAuthzid(pAuthcid); -- Hallvard From owner-ietf-sasl Wed Oct 1 08:44:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Fi0KP089583 for ; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Fi01P089582 for ietf-sasl-bks; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h91FhxKP089577 for ; Wed, 1 Oct 2003 08:43:59 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa23323; 1 Oct 2003 11:43 EDT Date: Wed, 01 Oct 2003 11:43:34 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 01, 2003 10:17:55 -0700 "Kurt D. Zeilenga" wrote: >> Network Working Group A. Melnikov >> Internet Draft Editor >> Document: draft-ietf-sasl-rfc2222bis-02.txt August 2003 >> Expires in six months Well, it doesn't matter now, but "expires in six months" is not acceptable; a specific date must be specified. See the "Formatting" section in 1id-guidelines.txt >> 1. Abstract Don't number the abstract. >> 4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. > > IANA should be spelled out here. > >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". Ick. IMHO this phrasing is ugly and not necessary. It appears to encourage authors of documents like SASL-GSSAPI to allocate themselves parts of the namespace without bothering to direct the IANA to reserve them. This would be a bad thing, and would indeed require that a potential future protocol designer (and/or the IANA itself) search the complete space of standards-track documents to see if the name they want to use has been reserved. IETF standards-track documents do not need the SASL spec's permission to direct the IANA to reserve parts of the namespace; thus, I don't think it's necessary to mention it at all. However, if it is mentioned, it should be in the IANA considerations section, not here, and with text like "IETF standards track documents may direct the IANA to reserve a portion of the SASL mechansim namespace and may specify different registration criteria for the reserved portion." Given the large size of the mechanism namespace, it is unfortunate that we have failed to provide for mechanism names of the form foo@domain. Delegated registration is much less work for IANA. >> Per IETF character set >> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >> these and other strings in UTF-8 [UTF-8]. > > This seems counter to [CHARSET-POLICY] as it allows a mechanism to > not support UTF-8 transfer of character data. > > [CHARSET-POLICY] says: > Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". > > Personally, I refer to this as "proxy authorization". Proxy > authentication makes it sound like the feature can be used by a > proxy to authenticate its users. The same argument can be made for "proxy authorization". We are talking about "authentication by proxy", not "authentication to a proxy". And yes, we're really talking about authorization, not authentication, but it's not really "authorization by proxy"; it's just authorization. The terminology is pretty bad. It's not clear to me that we need a name for this at all. But I'm pretty sure the phrase "proxy authentication" has been in use for a while, and to change it might cause more confusion than leaving it alone. >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. Sure, but that's not really all it's good for. It also allows jhutz@CS.CMU.EDU to log in to the IMAP server on CYRUS.ANDREW.CMU.EDU as 'jhutz', even though the server is in the ANDREW.CMU.EDU realm. And similar functionality, though not using SASL, allows me to type "jhutz@CS.CMU.EDU,maint:" at a login prompt, followed by jhutz@CS.CMU.EDU's password, and log in as the user 'maint'. >> The server SHOULD verify the correctness of a received authorization >> identity. > > "Correctness" here doesn't appear to be correct. And it should > be a MUST. I suggest: > The server SHALL fail the authentication exchange if the > authenticated client is not allowed to assume the asserted > authorization identity. s/SHALL/MUST/ >> 4.4. Character string issues >> >> Per IETF character set policy [CHARSET-POLICY], authentication >> mechanisms SHOULD encode character strings in UTF-8 [UTF-8]. > > See above note about charset-policy. And my response. It's really quite important that we get this right for authentication identities, or we risk invalidating a number of popular mechanisms because they are based on underlying authentication technology which does not use UTF-8. >> 5. Protocol profile requirements >> >> In order to use this specification, a protocol definition MUST supply >> the following information: >> >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] This >> service name is made available to the authentication mechanism. >> >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" A definition Paragraph break. >> A definition of the method by which the authentication protocol >> exchange is carried out, including how the challenges and responses >> are encoded, how the server indicates completion or failure of the >> exchange, how the client aborts an exchange, and how the exchange >> method interacts with any line length limits in the protocol. >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. This allows the >> server to avoid a round trip when using a mechanism which is defined >> to have the server send additional data along with the indication of >> successful completion. See section 6.2 of this document for further >> information. What command? Who says "the method by which the authentication protocol exchange is carried out" is a command? s/The command/The exchange method/ >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. > > I think it unwise to enter into a discussion of realms here. > Realm syntax and semantics are, for mechanisms which have realms, > mechanism specific. The mechanism specification should state how > they are to be compared. The mechanism specification should state > how they are to constructed and used in the mechanism and, where > appropriate, state any protocol profiling requirements. (Note: > I'd likely doubt any mechanism attempt to state protocol profiling > requirements as this breaks SASL's separation of profile and > mechanism). I agree. A realm is just part of the authentication identities used by certain mechanisms. It is mechanism-specific, and a discussion of realms is irrelevant to protocol profiling. >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. Absolutely not. Protocols may decide to include some concept of realm in their authorization identities, but they have no business whatsoever defining the semantics of authentication identities. That is the responsiblity of the mechanism. >> Below the term "realm" has the meaning as defined in the section 5. >> A security layer that remains in effect when a client, which already >> has authenticated and established the security layer with "Realm A", >> authenticates to "Realm B", without negotiating a new security layer, >> enables "Realm B" to make guesses about previously observed >> ciphertext using the server's SASL engine as an oracle. "Realm B" may >> observe how known cleartext is encrypted. >> >> +---------+ +---------+ >> | | | | >> | Realm B | | Realm A | >> | | | | >> +---------+ +---------+ >> | ^ | >> | : +-----------+ | >> Traffic from | : | Encryption| | Traffic from A >> B to client +-------->| end point |<-------+ to client >> : | (SSL/SASL)| >> : +-----------+ >> : | >> : | >> : +---+ >> : | | >> : | | >> : | | Encryption tunnel, e.g. SASL or SSL, >> : | | between the server > >> encrypted | | Separate tunnels to different >> traffic between | | clients. >> Realm A and client +---+ >> | >> | >> +-----------> Traffic to clients This discussion is confusing and makes no sense to me. SASL doesn't protect traffic between "realms" and clients; it protects traffic between _servers_ and clients. This needs to be reworded so it makes sense, in terms of entities known to the SASL framework. A "realm" is not such an entity; it is no more than part of the autentication identities used by some mechanisms, and has no place outside the mechainsm specification. Put another way, and ignoring the issue of "realms"; the above description makes so little sense to me that I cannot evaluate its validity or understand what attack we are trying to avoid. >> 8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. Provide the template. Do not specify how to communicate the registration to the IANA, because that may change over time and is out of scope for this document. >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. Again, too bad we didn't allow for foo@domain.com. >> 8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism > > Replace quotes with < and >, and insert a period at the end of the > sentence. > >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). > > Drop "by sending (...)". IMHO, drop the whole subsection. IANA considerations are about telling the IANA what it needs to do and be aware of with respect to this document. It's appropriate to specify the form of registration and the rules which govern whether IANA should accept a registration. It is not appropriate to specify the means used to communicate with the IANA or the RFC Editor, or to direct the IANA as to the URL at which it must provide the registration data. These things may change over time, and it is out of scope for the SASL working group (or, indeed, the IETF) to specify them. >> 8.3. Change control >> >> Once a SASL mechanism registration has been published by IANA, the >> author may request a change to its definition. The change request >> follows the same procedure as the registration request. This sounds a lot like the stringprep loophole, and it makes me nervous. >> 9.2. Informative References >> >> <> [SASL-GSSAPI] Myers, "SASL GSSAPI >> mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt, >> September 2000 >> [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest >> Authentication as a SASL Mechanism", work in progress, draft-ietf- >> sasl-rfc2831bis-XX.txt, replaces RFC 2831 I think it would be good to eliminate references to new or updated mechanisms if at all possible, since otherwise we are forced to either publish a document with incorrect or incomplete references, or wait until those documents are ready. If we keep them, use the correct reference form: [SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms" (draft-ietf-cat-sasl-gssapi-01.txt) See "References" in section 2 of ID-nits. >> [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) >> MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. Ew. I don't think this is necessary. Also, references to URL's are to be avoided, as they may change, rendering the document obsolete and confusing. See "References" in section 2 of id-nits. >> "stringprep" and Unicode security considerations apply to >> authentication identities, authorization identities and passwords. Include references to these. Put Security Considerations _before_ references, not after. >> 12. Acknowledgments >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). Except we should be dropping the definition of "realm". >> In certain situations, it is reasonable to use SASL underneath one of >> these Transport Security services. The transport service would >> secure the connection, either service would authenticate the client, >> and SASL would negotiate the authorization identity. The SASL >> negotiation would be what moves the protocol from "unauthenticated" >> to "authenticated" state. The "EXTERNAL" SASL mechanism is >> explicitly intended to handle the case where the transport service >> secures the connection and authenticates the client and SASL >> negotiates the authorization identity. >> >> When using SASL underneath a sufficiently strong Transport Security >> service, a SASL security layer would most likely be redundant. The >> client and server would thus probably want to negotiate off the use >> of a SASL security layer. Please don't say this without a _lot_ more text explaining when it is safe. A common configuration is to run SASL under TLS, using SASL for client authentication and negotation of the authorization identity. In this configuration, it is _not_ safe to skip using a SASL security layer if the client did not check the server's certificate (there is a tunnelling MitM attack), and it's not a particularly good idea even if the server cert was checked, because the client's authentication is still not bound to the encryption keys used at the TLS layer. We already have problems with people who think it is actively bad to use a SASL security layer under TLS. The result is that some insecure configurations are now widely deployed. Let's not encourage this any further. >> Appendix B. IANA considerations Uh, no. IANA considerations were section 8. Please merge them. >> The IANA is directed to modify the SASL mechanisms registry as >> follows: > > Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: It's not demanting; it's perfectly reasonable usage. The IANA works for the IETF; it is appropriate for the IETF, in the form of a standards-track document, to direct it to make changes to a registry. It is also common usage. Put the TOC at the _top_ of the document, just after the abstract. See the "Tabel of Contents" section at http://www.rfc-editor.org/policy.html -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Oct 1 11:20:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKNKP095438 for ; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IKNSw095437 for ietf-sasl-bks; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKMKP095432 for ; Wed, 1 Oct 2003 11:20:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 740CF151D9B; Wed, 1 Oct 2003 14:20:02 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> From: Sam Hartman Date: Wed, 01 Oct 2003 14:20:02 -0400 In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 01 Oct 2003 10:17:55 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an >> authentication protocol exchange. This consists of a series of >> server challenges and client responses, the contents of which >> are specific to and defined by the mechanism. Kurt> Can't the client challenge the server as well? I always thought that in SASL, the challenge was defined to be the message from the server to the client even if it didn't serve that purpose in a security sense. --Sam From owner-ietf-sasl Wed Oct 1 11:46:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkIKP096361 for ; Wed, 1 Oct 2003 11:46:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IkHGh096360 for ietf-sasl-bks; Wed, 1 Oct 2003 11:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkGKP096354 for ; Wed, 1 Oct 2003 11:46:16 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h91IkF5t031925; Wed, 1 Oct 2003 14:46:15 -0400 Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: Message-ID: References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> 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: On Wed, 1 Oct 2003, Sam Hartman wrote: > Kurt> Can't the client challenge the server as well? > > I always thought that in SASL, the challenge was defined to be the > message from the server to the client even if it didn't serve that > purpose in a security sense. I agree. Indeed, in 6.1 we refer to an "initial client response" even though it could, in fact, be an initial challenge from client to server. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu Oct 2 18:41:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fwKP025631 for ; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h931fwa0025630 for ietf-sasl-bks; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fvKP025624 for ; Thu, 2 Oct 2003 18:41:57 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h931fxlg022341 for ; Fri, 3 Oct 2003 01:41:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 03 Oct 2003 06:41:43 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: References: 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: Simon raised this issue to me privately... but I think it needs broader discussion (given that it is a technical issue). At 02:19 PM 10/2/2003, Simon Josefsson wrote: >* The document doesn't mandate any specific action when the client > send an invalid string (e.g., one that is rejected by string > processing). That is, what should the implementation do if the message it receives is malformed? I note that this issue is likely not unique to ANONYMOUS. So, maybe it should be dealt with in base SASL specification. I'm thinking a malformed message should be treated as a protocol error in the application protocol. Comments? Kurt From owner-ietf-sasl Fri Oct 3 00:39:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dpKP091053 for ; Fri, 3 Oct 2003 00:39:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h937dpbV091052 for ietf-sasl-bks; Fri, 3 Oct 2003 00:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dmKP091031 for ; Fri, 3 Oct 2003 00:39:48 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h937dlJV076012; Fri, 3 Oct 2003 01:39:47 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 03 Oct 2003 01:39:46 -0600 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Message-ID: <2147483647.1065145186@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > At 02:19 PM 10/2/2003, Simon Josefsson wrote: >> * The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing) [...] > That is, what should the implementation do if the message it receives > is malformed? In the absence of a very compelling reason to do otherwise, the application should immediately fail the transaction. "Be liberal in what you accept" has no place here. However, I'm more concerned about protocol parser state machines getting out of sync (see the recent spate of -- again -- ASN.1 parser bugs) than applications misinterpreting bogus realm strings. > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. [...] > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. [Son-of-]2222 is a framework document, so I'm not sure if we can mandate that sort of behaviour in it. But that cannot stop us from suggesting some extremely rude behaviour towards authors of deviant software in the Security Considerations section. --lyndon From owner-ietf-sasl Fri Oct 3 08:54:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FsFKP027698 for ; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FsFn3027697 for ietf-sasl-bks; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Fs8KP027684 for ; Fri, 3 Oct 2003 08:54:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 3 Oct 2003 16:53:55 +0100 Message-ID: <3F7D9B91.7060906@isode.com> Date: Fri, 03 Oct 2003 16:53:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've started with the easy (editorial) stuff and I will reply to other comments after the weekend. Kurt D. Zeilenga wrote: >Attached are my raw review notes... mostly editorial, >clarifications, and such. I do raise (as Hallvard did) >some concerns with the realm text. I'll try to pull >that issue (and maybe a couple of other issues) out as >separate threads. > >Kurt > > >> >>1. Abstract >> >> SASL provides a method for adding authentication support with an >> optional security layer to connection-based protocols. >> >> > >SASL needs to be spelled out here (first use in Abstract). > Done. >> It also >> describes a structure for authentication mechanisms. The result is >> an abstraction layer between protocols and authentication mechanisms >> such that any SASL-compatible authentication mechanism can be used >> with any SASL-compatible protocol. >> >> This document describes how a SASL authentication mechanism is >> structured, how a protocol adds support for SASL, defines the >> protocol for carrying a security layer over a connection, and defines >> the EXTERNAL SASL authentication mechanism. >> >>... >> >>2.2. Conventions used in this document >> >> In examples, "C:" and "S:" indicate lines sent by the client and >> server respectively. >> >> The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" >> in this document are to be interpreted as defined in "Key words for >> use in RFCs to Indicate Requirement Levels" [KEYWORDS]. >> > >Add U+ convent description (see SASLprep). > > > Done. >>... >> >>4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. >> >> > >IANA should be spelled out here. > Ok. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". >> >> The "sasl-mech" rule below defines the syntax of a SASL mechanism >> name. This uses the augmented Backus-Naur Form (BNF) notation as >> > >s/augmented Backus-Naur Form (BNF)/Augmented Backus-Naur Form (ABNF)/ > Done. >> specified in [ABNF] and the ABNF core rules as specified in Appendix >> A of the ABNF specification [ABNF]. >> >> >> sasl-mech = 1*20mech-char >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase letters, >> ; digits, "-" and "_" >> >> >> >> >> >> >>A. Melnikov FORMFEED[Page 3] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. >> >> > >Can't the client challenge the server as well? > Rob has already answered this question. > ... > >> After receiving a challenge, a client mechanism may issue a response >> or abort the exchange. The protocol's profile specifies how each of >> these is then represented over the connection. >> >> > >Indicate here that mechanisms may also involve challenges to >the server by the client. > > See Rob's reply. >>... >> >> An authorization identity is a string of zero or more ISO 10646 >> [ISO-10646] coded characters. The NUL (U+0000) character is not >> permitted in authorization identities. The meaning of an >> authorization identity of the empty string (zero length) is defined >> below in this section. The authorization identity is used by the >> server as the primary identity for making access policy decisions. >> >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> >> > >I'm thinking "blob" is not a good word choice here. > > Blob \Blob\ (bl[o^]b), n. [See {Bleb}.] > 1. Something blunt and round; a small drop or lump of > something viscid or thick; a drop; a bubble; a blister. > --Wright. > > 2. (Zo["o]l.) A small fresh-water fish ({Uranidea > Richardsoni}); the miller's thumb. > >>From WordNet (r) 2.0 [wn]: > > blob > n : an indistinct shapeless form > v : make a spot or mark onto; "The wine spotted the tablecloth" > [syn: {spot}, {fleck}, {blot}] > [also: {blobbing}, {blobbed}] > > >You could have meant BLOB (Binary Large OBject), but this seems not to >fit as well. > >I'm thinking "blob" should be replaced with "string". > I would rather use "data". >> While some legacy >> mechanisms are incapable of transmitting an authorization identity >> other than the empty string, >> >> > >I know of mechanisms which do not transmit an authorization identity... >but are there ones which only allow transfers of empty authorization >identity strings? > No, I am not aware of any such mechanism >> newly defined mechanisms are expected to >> be capable of carrying the entire Unicode repertoire (with the >> exception of the NUL character). An authorization identity of the >> empty string and and an absent authorization identity MUST be treated >> >> > >s/and and/and/ > Yes, already fixed in my diff ;-). >> as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an >> >> >> >>A. Melnikov FORMFEED[Page 4] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> authorization identity is allowed to be absent, but one is >> transferred, it SHOULD NOT be an empty string). >> >> > >Suggest this be reworded: > However, mechanisms SHOULD NOT allow both. That is, a mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. > > Done (I didn't like the original either, but couldn't think of anything better). >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. >> >> The server makes an implementation defined policy decision as to >> whether the authentication identity is permitted to have the access >> privileges of the authorization identity and whether the >> authorization identity is permitted to receive service. If it is >> not, the server indicates failure of the authentication protocol >> exchange. >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >> > >I suggest rewording this: > As a client might not have the same information as the > server, clients SHOULD NOT derive authorization identities > from authentication identities. Instead, clients SHOULD > provide no (or empty) authorization identity when the user > has not provided an authorization identity. > Ok. >>... >> >> In this example, the client is proxy >> authenticating, sending the authorization id "fred". The server has >> determined the client's identity through IPsec and has a security >> policy that permits that identity to proxy authenticate as any other >> identity. >> >> To the protocol profile, the four octet sequence "fred" is an opaque >> binary blob. The SASL protocol profile for SMTP specifies that >> server challenges and client responses are encoded in BASE64; the >> BASE64 encoding of "fred" is "ZnJlZA==". >> >> > >s/binary blob/string/ > I've changed this to "data" instead, as above. >>... >> >> S: 220 smtp.example.com ESMTP server ready >> C: EHLO jgm.example.com >> S: 250-smtp.example.com >> S: 250 AUTH DIGEST-MD5 EXTERNAL >> C: AUTH EXTERNAL ZnJlZA== >> S: 235 Authentication successful. >> >>8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. >> >> >> >> >>A. Melnikov FORMFEED[Page 11] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. >> >> While the registration procedures do not require it, authors of SASL >> mechanisms are encouraged to seek community review and comment >> whenever that is feasible. Authors may seek community review by >> posting a specification of their proposed mechanism as an internet- >> draft. SASL mechanisms intended for widespread use should be >> standardized through the normal IETF process, when appropriate. >> >>8.1. Comments on SASL mechanism registrations >> >> Comments on registered SASL mechanisms should first be sent to the >> "owner" of the mechanism. Submitters of comments may, after a >> reasonable attempt to contact the owner, request IANA to attach their >> comment to the SASL mechanism registration itself. If IANA approves >> of this the comment will be made accessible in conjunction with the >> SASL mechanism registration itself. >> >>8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism >> >> > >Replace quotes with < and >, and insert a period at the end of the >sentence. > > Already done. >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). >> >> > >Drop "by sending (...)". > Done. >>... >> >>9. References >> >>9.1. Normative References >> >> [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: >> ABNF", RFC 2234, November 1997 >> >> [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and >> Languages", RFC 2277, January 1998 >> >> [GSSAPI] Linn, "Generic Security Service Application Program >> Interface, Version 2, Update 1", RFC 2743, January 2000 >> >> [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - >> Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. >> >> > >For consistency (all other references use tags not associated with >their document numbers), I suggest replacing the tag [ISO-10646] >with [UCS]. > > I frankly doubt that this make it any better. >> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate >> Requirement Levels", RFC 2119, March 1997 >> >> [Stringprep] P. Hoffman, M. Blanchet, "Preparation of >> Internationalized Strings ("stringprep")", RFC 3454, December 2002. >> >> [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names >> and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. >> >> [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work >> in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, >> Janyary 1998 >> >>... >> >>12. Acknowledgments >> >> This document is a revision of RFC 2222 written by John G. Myers >> . He also wrote the major part of this >> document. >> >> > >Drop John's e-mail address here. I suggest replacing the second >sentence with: > He also contributed significantly to this revision. > Ok. >> Thank you to Magnus Nystrom for the ASCII picture used in section >> 6.3. >> > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Ok. >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). >> >> Contributions of many members of the SASL mailing list are gratefully >> acknowledged. >> >> > >s/mailing list/working group/ > A lot of contribution was done before we had a working group. (Not that it worth arguing about anyway.) >>... >> >>Appendix B. IANA considerations >> >> The IANA is directed to modify the SASL mechanisms registry as >> follows: >> >> > >Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: > > Ok. Alexey From owner-ietf-sasl Fri Oct 3 11:00:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0FKP035504 for ; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93I0FPK035503 for ietf-sasl-bks; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0EKP035498 for ; Fri, 3 Oct 2003 11:00:14 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BA80C151D9B; Fri, 3 Oct 2003 13:59:57 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> From: Sam Hartman Date: Fri, 03 Oct 2003 13:59:57 -0400 In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 03 Oct 2003 06:41:43 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> I'm thinking a malformed message should be treated as a Kurt> protocol error in the application protocol. Kurt> Comments? This seems reasonable during the authentication phase, but I think we may need to say something more specific about security layers. From owner-ietf-sasl Mon Oct 6 16:16:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGTKP077980 for ; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NGTaG077979 for ietf-sasl-bks; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGSKP077974 for ; Mon, 6 Oct 2003 16:16:28 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NGT5t009824 for ; Mon, 6 Oct 2003 19:16:29 -0400 Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: SASL Initial Response? (fwd) 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: Here are some of Mark's comments on RFC2222bis: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- ---------- Forwarded message ---------- Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski Cc: RL 'Bob' Morgan , IMAP Extensions WG Subject: Re: SASL Initial Response? On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree. I also suspect an example or two could help the appropriate > sections of 2222bis. But further discussion of this should probably move > to the ietf-sasl list. I'm not on the ietf-sasl list, so would appreciate this being passed on. I guess that I should be at the SASL session in Minneapolis (assuming I go there which seems likely). Examples are always helpful. Section 6.1 of 2222bis should give examples of AUTH PLAIN in SMTP both with and without initial client data. Similar examples should appear in the specification for the PLAIN mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!) *and* in the specifications for POP3 SASL and SMTP SASL. > Obviously. But currently it seems that the primary reason that we don't > have an initial SASL response in IMAP is concerns over clarity of the > SASL specification. Actually, the primary reason was compatibility with the past; IMAP SASL is older than SASL. I'm willing to go along with it as a server-optional extension *IF* the problems with the current client-optional server-mandatory initial client data POP3/SMTP SASL are fixed. Since implementation of initial client data will be server-optional in IMAP, it will be more complex than in POP3/SMTP. This is because it's mandatory to implement in POP3/SMTP servers. > If fixing *that* specification still isn't good enough, I'm totally > willing to supply text in the draft for the IMAP extention to the effect > of "pay careful attention to the fact that initial responses are > *optional*," even to the point of making it a Security Consideration. We will need that text, and much more. > And indeed, any IMAP server that didn't get this right would immediately > have a large number of old-style clients fail to work against it anyway, > since it is an extention and not part of the base protocol. It's not just IMAP servers we have to worry about. It's also IMAP clients. We already have clients which fail to interoperate with a server that does not have a particular extension and/or declare such servers to be "broken." The offenders know who they are. We have to concern ourselves about the possibility of clients that think that initial data is mandatory to implement in the server (since it is mandatory in POP3 and SMTP). Thus, the situation is *worse* with IMAP than with POP3 or SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Mon Oct 6 16:15:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFhKP077954 for ; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NFh8e077953 for ietf-sasl-bks; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFfKP077944 for ; Mon, 6 Oct 2003 16:15:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NFe5t009820; Mon, 6 Oct 2003 19:15:40 -0400 Date: Mon, 6 Oct 2003 19:15:41 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> 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: I am moving this discussion to the ietf-sasl list, since it seems to have wandered somewhat from a discussion of IMAP's specific case. Background for members of the IETF SASL list: This was part of a discussion in the IMAPEXT working group about the creation of an initial client response extention for IMAP. Currently, the argument against creating such an extention is that "implementors get client-initial-send wrong" (Specifically, servers get it wrong when clients choose to not perform the optional initial send). Mark, as this is your argument, please correct me if I have summarized it incorrectly. On Mon, 6 Oct 2003, Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > > > The most common offense is to implement PLAIN and LOGIN as the same thing, > > > thus giving LOGIN challenges to PLAIN with no initial response. > > That's inexcusable, since they are clearly NOT the same thing, and PLAIN > > has always had a standardized SPEC. Obviously we can't make people read > > the specs correctly, all we can do is make them clear and unambiguous. > > Agreed completely. However, multiple commercial implementations have done > this blunder. > > > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > > Somtimes you also find extra CRLFs in the responses. > > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > > take a look. > > It's not ambiguous, but you have to read three separate documents (RFCs > 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in > SMTP. For POP3, you just need to read 2222 and 2595. > > There is no single document, and *NO* examples, that explains this. RFC > 2554 is a bit better in talking about empty challenges than 2595 (see > first paragraph of page 3, RFC 2554) but without the context of RFC 2222 > it makes no sense. Isn't it typical that a SASL implementor should need to look at 3 documents however? The one for their protocol, the one for the mechanism that interests them, and RFC2222 or its replacement. My personal reading of 2554 is that it could use a lot of rework anyway, and I'm toying with writing an update to it right now. Such an update would include examples. > > > Over and over again, I get told "just make Pine send the initial > > > challenge"; in other words, that the initial challenge is mandatory. But > > > the SASL specification does not say that; and the idea of inflicting the > > > non-interoperable brokenness of POP/SMTP on IMAP repels me. > > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead > > of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become > > problematic because the initial response truely is optional. > > Actually, I would like the SHOULD to become a MAY, and it be emphasized > that servers MUST implement the correct empty challenge behavior. > > However, a MUST is preferable to the status quo, which is a de jure SHOULD > but (at least according to certain individuals) a de facto MUST. I don't see a strong technical reason for reducing the requirement for SHOULD to MAY (reducing the round trips used should be encouraged). I do see a strong argument for making it abundantly clear that servers MUST implement the correct omitted-challenge behavior (to be distinguished from an empty challenge -- "" is not the same as NIL) > > I will do this. Just to be clear, we are only talking about > > client-first mechanisms in which the client chooses to not send an > > initial response, correct? > > Correct. SMTP is the worst case, since you have to read three RFCs to > work out how to implement PLAIN in SMTP. > > Note that there are no examples. The examples situation should be fixed. I don't think that we can expect SASL implementors to (in the general case) have to read only two RFCs, especially as we are breaking all of the mechanisms into their own documents. I will be forwarding your other message along to the SASL list momentarily. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Oct 6 16:49:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnEKP079404 for ; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NnEaN079403 for ietf-sasl-bks; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnDKP079396 for ; Mon, 6 Oct 2003 16:49:13 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDC2028637; Mon, 6 Oct 2003 16:49:13 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDSS006277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 16:49:13 -0700 Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing 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: On Mon, 6 Oct 2003, Rob Siemborski wrote: > Currently, the argument against > creating such an extention is that "implementors get client-initial-send > wrong" (Specifically, servers get it wrong when clients choose to not > perform the optional initial send). Mark, as this is your argument, > please correct me if I have summarized it incorrectly. Yes, that is an incorrect summary. The argument against creating such an extension is that the current specifications for SASL in POP3 and SMTP (which permit client-initial-send) are complex, and as a result many POP3/SMTP servers are not handling client-initial-send properly when the client does not provide an initial response. Consequently, I do not believe that IMAP should be extended to provide client-initial-send until after the specifications are clarified. This is especially the case because IMAP will be a *more* complex case than POP3/SMTP because client-initial-send is mandatory to implement in POP3/SMTP servers but must be optional (due to compatibility with the installed base) in IMAP servers. Thus, the interoperability matrix with IMAP is 4 possible configurations instead of 2 with POP3/SMTP. The one-line summary: Before making it more complex, fix the existing complexity > Isn't it typical that a SASL implementor should need to look at 3 > documents however? The one for their protocol, the one for the mechanism > that interests them, and RFC2222 or its replacement. Empirical data suggests that this requires considerably more care than currently exists among implementors. An understanding of the correct server behavior for "AUTH PLAIN" in SMTP requires reading three documents. > My personal reading of 2554 is that it could use a lot of rework anyway, > and I'm toying with writing an update to it right now. Such an update > would include examples. Excellent; I'll be glad to help you. > I don't see a strong technical reason for reducing the requirement for > SHOULD to MAY (reducing the round trips used should be encouraged). I do > see a strong argument for making it abundantly clear that servers MUST > implement the correct omitted-challenge behavior (to be distinguished from > an empty challenge -- "" is not the same as NIL) I see it as a matter of semantics. Too many people see a SHOULD as an excuse to overlook a MUST. > The examples situation should be fixed. I don't think that we can expect > SASL implementors to (in the general case) have to read only two RFCs, > especially as we are breaking all of the mechanisms into their own > documents. I fear that it is a lot to expect them to read *one* RFC, much less grasp concepts that only come through by reading three. We seem to be in a world where protocol engines are written by empirical tests and a cursory glance at the examples in RFCs. It is a helpful exercise to go through the steps to figure out what is the correct server response to "AUTH PLAIN" in SMTP. You have to start with 2554, then 2595, then 2222, then back to 2554, then back to 2595. You have to remember certain statements in each of these documents which make no apparent sense until you read certain equally-obscure statements in the other documents. And you have to put this all together. I went through this exercise with someone who I knew to be of above-average intelligence. It took some time before he grasped it. That told me that the documents have a problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Tue Oct 7 11:29:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IToKP039969 for ; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97ITo82039968 for ietf-sasl-bks; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97ITmKP039958 for ; Tue, 7 Oct 2003 11:29:49 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97ITjo5001254 for ; Tue, 7 Oct 2003 14:29:45 -0400 (EDT) Message-ID: <3F8306B8.3010207@oceana.com> Date: Tue, 07 Oct 2003 14:32:24 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00 Last Call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we did not receive any negative feedback (or positive, for that matter) and Mark, Rob Siemborski and I feel that the current doc accurately describes the existing deployed implementation, I intend ask the IETF to Last Call it shortly. If you have any comments on the existing doc, please send them soon. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 11:36:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaNKP040195 for ; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97IaNbC040194 for ietf-sasl-bks; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaLKP040189 for ; Tue, 7 Oct 2003 11:36:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97IaGo5001378; Tue, 7 Oct 2003 14:36:16 -0400 (EDT) Message-ID: <3F83083F.10600@oceana.com> Date: Tue, 07 Oct 2003 14:38:55 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steven F Siirila CC: SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> In-Reply-To: <20031007180404.GA16933@earth.tc.umn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steven F Siirila wrote: > In reading section 2.2: > > 2.2. Server side of authentication protocol exchange > > The server issues the string "User Name" in challenge, and receives a > client response. This response is recorded as the authorization > identity. The server then issues the string "Password" in challenge, > and receives a client response. This response is recorded as the > authorization authenticator. The server must verify that the > authorization authenticator permits login as the authorization > identity. > > Note: There is at least one widely deployed client which requires > that the challenge strings transmitted by the server be "Username:" > and "Password:" respectively. For this reason, server > implementations MAY send these challenge strings instead of those > listed above. > > Why is the string "User name" chosen as the suggested challenge to be sent > by the server instead of "Username:", considering that second paragraph? > Are there other clients out there that expect "User name" as a challenge > string? Note that the current Cyrus SASL (V2) returns "Username:" and > "Password:". The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). The wording in the draft is a compromise between the authors. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 14:50:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97LoFKP047316 for ; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97LoFOf047315 for ietf-sasl-bks; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Lo9KP047305 for ; Tue, 7 Oct 2003 14:50:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 7 Oct 2003 22:49:34 +0100 Message-ID: <3F8334ED.80504@isode.com> Date: Tue, 07 Oct 2003 22:49:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre , Jeremie Miller CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG wrote: >The IESG has received a request from the Extensible Messaging and Presence >Protocol WG to consider the following document: > >- 'XMPP Core ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-09. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt > I would like to raise several SASL related issues in XMPP document. (Sorry for crosspost and sorry for being late with reviewing this.) 1). > 7. The initiating entity MUST provide an authzid during SASL > negotiation. The authzid-value MUST be a valid JID of the form > (i.e., a domain identifier only) for servers and of the > form (i.e., node identifier, domain > identifier, and resource identifier) for clients. The initiating > entity MAY process the authzid-value in accordance with the rules > defined in Addressing Scheme (Section 3) before providing it to > the receiving entity, but is NOT REQUIRED to do so; however, the > receiving entity MUST verify that the authzid-value provided by > the initiating entity conforms to the rules defined therein. Not all SASL mechanisms are capable of transmitting authorization identity, so this requirement might be problematic. Also, the revision of RFC 2222 says that the client must not specify authorization-id unless it wants to impersonate some other entity: As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. So, the text should be reworded reflect that an authorization identity is optional and that if one is provided, it is in the form described above. 2). > This series of challenge/response pairs continues until one of three > things happens: > > 1. The initiating entity aborts the handshake by sending an > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > namespace to the receiving entity. Upon receiving the > element, the receiving entity MUST terminate the TCP connection. I think the requirement to drop TCP connection is unreasonable here. There are several valid reasons why the client may retry failed authentication: 1). User typed in a wrong password, the client should retry the same SASL mechanism a reasonable number of times. 2). The client invoked a SASL mechanism that reported that it can't be used because of misconfiguration (e.g. kerberos configuration file is missing). The client than sends to the server and tries another mechanism. 3). > 3. The receiving entity reports success of the handshake by sending > a element qualified by the > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > entity; this element MAY optionally contain character data (in > SASL terminology "additional data with success"). Upon receiving > the element, the initiating entity MUST initiate a new > stream by sending an opening XML stream header to the receiving > entity (it is not necessary to send a closing > element first, since the receiving entity and initiating entity > MUST consider the original stream to be closed upon sending or > receiving the element). Upon receiving the new stream > header from the initiating entity, the receiving entity MUST > respond by sending a new XML stream header to the initiating > entity, along with any remaining available features (but NOT > including the STARTTLS feature or any authentication mechanisms) > or an empty features element (to signify that no additional > features are available); note that any such additional features > are not defined herein, and MUST be defined by the relevant > extension to XMPP. Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a successful SASL authentication. Some of them require that the client compares the list of the advertised mechanism with the one before the authentication. This is done to prevent man-in-the-middle attacks when an attacker removes strong SASL mechanisms from the list of supported mechanisms. (Whether this check is useful in practice is another matter. I am not sure whether anybody implements it). 4). There was a recent discussion on the bugtraq mailing list about handling invalid base64 data. It turned out that different implementations handle this differently, for example: 1). Ignore invalid characters 2). Treat an invalid character as the end of the base64 encoded data (and ignore the rest) 3). Truncate base64 encoded data before the invalid character. In particular there was a discussion regarding the padding character ('=') in the middle of a base64 data. I suggest that some text about this be added to the Security considerations sections. For example: Both the client and the server should verify the received base64 data and reject (and not ignore) any characters not explicitly allowed by the base64 alphabet [BASE64] and should reject any sequence of base64 characters that contains the pad ('=') character not as the last character of the (e.g. "=AAA" or "BBBB=CCC"). [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. (You might decide to relax this for XMPP and to allow spaces and/or CRLFs anywhere in the data.) 5). >6.3 SASL Errors > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. Do you mean invalid base64 encoding here or something else? 6). >6.3 SASL Errors > > The following SASL-related error conditions are defined: > > o -- The receiving entity acknowledges an > element sent by the initiating entity; sent in response to the > element. > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. or with initial challenge data. Example: SASL PLAIN mechanism. > o -- The mechanism chosen by the initiating > entity may be used only if the stream is already encrypted; sent > in response to the element. > > o -- The authzid provided by the initiating > entity is invalid, either because it is incorrectly formatted or > because the initiating entity does not have permissions to > authorize that ID; sent in response to a element. or with initial challenge data. > o -- The initiating entity did not provide a > mechanism or requested a mechanism that is not supported by the > receiving entity; sent in response to the element. > > o -- The realm provided by the initiating entity > (in mechanisms that support the concept of a realm) does not match > one of the hostnames served by the receiving entity; sent in > response to a element. or with initial challenge data. > o -- The mechanism requested by the initiating > entity is weaker than server policy permits for that initiating > entity; sent in response to the element. or with initial challenge data. > o -- The authentication failed because the > initiating entity did not provide valid credentials (this includes > the case of an unknown username); sent in response to a element. or with initial challenge data. 7). >12.4 Order of Layers > > The order of layers in which protocols MUST be stacked is as follows: > > 1. TCP > > 2. TLS > > 3. SASL > > 4. XMPP > > The rationale for this order is that TCP is the base connection layer > used by all of the protocols stacked on top of TCP, TLS is often > provided at the operating system layer, SASL is often provided at the > application layer, and XMPP is the application itself. This should be referenced in "6.4 SASL Definition" section, because it is related to the XMPP profile of SASL. Cheers, Alexey From owner-ietf-sasl Tue Oct 7 15:04:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4RKP047888 for ; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97M4R4U047887 for ietf-sasl-bks; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4QKP047881 for ; Tue, 7 Oct 2003 15:04:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h97M4Mlg071146; Tue, 7 Oct 2003 22:04:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 03:04:05 -0700 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: draft-murchison-sasl-login-00 Last Call Cc: Steven F Siirila , SASL mailing list , Mark Crispin In-Reply-To: <3F83083F.10600@oceana.com> References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> 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: Ken, This use of MAY is a bit problematic. MAY items are suppose to be truly optional (see RFC 2119). As servers using the alternative protocol tokens won't interoperate with client not expecting those alternatives, this item isn't. Likely this can be addressed by (more explicitly) limiting the applicability of the option. Kurt At 11:38 AM 10/7/2003, Ken Murchison wrote: >Steven F Siirila wrote: > >>In reading section 2.2: >>2.2. Server side of authentication protocol exchange >> The server issues the string "User Name" in challenge, and receives a >> client response. This response is recorded as the authorization >> identity. The server then issues the string "Password" in challenge, >> and receives a client response. This response is recorded as the >> authorization authenticator. The server must verify that the >> authorization authenticator permits login as the authorization >> identity. >> Note: There is at least one widely deployed client which requires >> that the challenge strings transmitted by the server be "Username:" >> and "Password:" respectively. For this reason, server >> implementations MAY send these challenge strings instead of those >> listed above. >>Why is the string "User name" chosen as the suggested challenge to be sent >>by the server instead of "Username:", considering that second paragraph? >>Are there other clients out there that expect "User name" as a challenge >>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>"Password:". > >The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). > >The wording in the draft is a compromise between the authors. > >-- >Kenneth Murchison Oceana Matrix Ltd. >Software Engineer 21 Princeton Place >716-662-8973 x26 Orchard Park, NY 14127 >--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 16:12:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NCmKP051035 for ; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NCmoY051034 for ietf-sasl-bks; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NClKP051017 for ; Tue, 7 Oct 2003 16:12:47 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97NCao5011151; Tue, 7 Oct 2003 19:12:40 -0400 (EDT) Message-ID: <3F834860.6050807@oceana.com> Date: Tue, 07 Oct 2003 19:12:32 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Steven F Siirila , SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > Ken, > > This use of MAY is a bit problematic. MAY items are suppose to be > truly optional (see RFC 2119). As servers using the > alternative protocol tokens won't interoperate with client not > expecting those alternatives, this item isn't. > > Likely this can be addressed by (more explicitly) limiting the > applicability of the option. I'll let Mark argue for the continued use of MAY. FWIW, I wanted to make the challenge strings used by M$ products a SHOULD and those originally intended by c-client a MAY. Mark is against making c-client [semi-]uncompliant, which I can also agree with. Cyrus SASL uses the M$ challenges and we are not aware of any products which fail to work with these strings, since clients other than M$ correctly ignore the contents of the challenges. Mark, Rob and myself struggled with this issue a lot. >>Steven F Siirila wrote: >> >> >>>In reading section 2.2: >>>2.2. Server side of authentication protocol exchange >>> The server issues the string "User Name" in challenge, and receives a >>> client response. This response is recorded as the authorization >>> identity. The server then issues the string "Password" in challenge, >>> and receives a client response. This response is recorded as the >>> authorization authenticator. The server must verify that the >>> authorization authenticator permits login as the authorization >>> identity. >>> Note: There is at least one widely deployed client which requires >>> that the challenge strings transmitted by the server be "Username:" >>> and "Password:" respectively. For this reason, server >>> implementations MAY send these challenge strings instead of those >>> listed above. >>>Why is the string "User name" chosen as the suggested challenge to be sent >>>by the server instead of "Username:", considering that second paragraph? >>>Are there other clients out there that expect "User name" as a challenge >>>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>>"Password:". >> >>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). >> >>The wording in the draft is a compromise between the authors. >> >>-- >>Kenneth Murchison Oceana Matrix Ltd. >>Software Engineer 21 Princeton Place >>716-662-8973 x26 Orchard Park, NY 14127 >>--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Oct 7 16:52:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NqLKP052559 for ; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NqLck052558 for ietf-sasl-bks; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from web103.bizmail.yahoo.com (web103.bizmail.yahoo.com [216.136.172.120]) by above.proper.com (8.12.9/8.12.8) with SMTP id h97NqJKP052551 for ; Tue, 7 Oct 2003 16:52:19 -0700 (PDT) (envelope-from syy@gama-tech.com) Message-ID: <20031007234715.54450.qmail@web103.bizmail.yahoo.com> Received: from [218.102.39.129] by web103.bizmail.yahoo.com via HTTP; Tue, 07 Oct 2003 16:47:15 PDT Date: Tue, 7 Oct 2003 16:47:15 -0700 (PDT) From: SY Yip Subject: linkage to data security To: ietf-sasl@imc.org 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: Hi All I'm new to this list. Just wonder if ietf-sasl addresses the linkage of authentication to data security. Meaning, a user logs on to a system, the system is able to use the user identity to determine data access security from LDAP or RDBMS. Today most applications can authenticate users but they use system id to connect to LDAP or RDBMS. As a result, they can't link the login ID to Data Access. Much appreciated for any help. Regards sy yip Gama Technology From owner-ietf-sasl Tue Oct 7 18:24:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OUKP055551 for ; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h981OUx6055550 for ietf-sasl-bks; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OSKP055545 for ; Tue, 7 Oct 2003 18:24:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUmw007879; Tue, 7 Oct 2003 18:24:30 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUx1021400; Tue, 7 Oct 2003 18:24:30 -0700 Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F834860.6050807@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> 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: On Tue, 7 Oct 2003, Ken Murchison wrote: > FWIW, I wanted to make the challenge strings used by M$ products a > SHOULD and those originally intended by c-client a MAY. Mark is against > making c-client [semi-]uncompliant, which I can also agree with. Especially since c-client is the first, reference, and most widely deployed implementation of the LOGIN mechanism; and was written by its inventor. I think that c-client's needs are more important that the evil empire's, and that it would be reprehensible to change specifications to match a broken implementation in evil empireware. I have never encountered the reported problems with evil empireware. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Tue Oct 7 21:37:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bIKP062198 for ; Tue, 7 Oct 2003 21:37:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h984bIKP062197 for ietf-sasl-bks; Tue, 7 Oct 2003 21:37:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bFKP062190 for ; Tue, 7 Oct 2003 21:37:17 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h984bHlg074914; Wed, 8 Oct 2003 04:37:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008090509.03ad6350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 09:37:00 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org In-Reply-To: References: 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: Hallvard, This wording concerns me a bit too. I think we need to have one registry which lists all "public" mechanisms. Hence, I suggest the text be reworded to allow a standard track RFC to establish additional registration requirements for portions of the name space (or "families of names"). That is, the SASL-GSSAPI specification can establish additional requirements for GSSAPI mechanisms. However, SASL-GSSAPI cannot (without updating the base specification) remove requirements established by the base specification. Also, I think having the text belongs only in the IANA Considerations section. Section 4 should just say SASL mechanism names must be registered with the IANA in accordance with Section 8 of this document. Section 8 should include both the guidelines for IANA to follow (for individual names and for families of names) and procedures for those requesting registration. (I suggest having two subsections "Guidelines for IANA" and "Registration Procedures". Kurt At 01:48 PM 9/30/2003, Hallvard B Furuseth wrote: >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? From owner-ietf-sasl Tue Oct 7 22:28:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SnKP070098 for ; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h985Sn0O070096 for ietf-sasl-bks; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SlKP070085 for ; Tue, 7 Oct 2003 22:28:48 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h985Splg075247; Wed, 8 Oct 2003 05:28:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 10:28:30 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: 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: At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >draft-ietf-sasl-plain-02.txt says that > > The client leaves > the authorization identity empty if it wishes the server to derive the > authorization identity from the provided authentication identity. > >and > > Note that the parameters provided to the Authorize function are not > prepared. > >so I think the pseudo-code for empty authzid should say > authzid = DeriveAuthzid(authcid); >and not > authzid = DeriveAuthzid(pAuthcid); I think the current psuedo-code is correct, the first quoted text is misleading. The word "provided" should be deleted as it implies the provided representation (as opposed to prepared representation of the provided authentication identity). Also, I recommend the following text be added immediately above the paragraph which ends with "that string MUST be prepared before generation of the hash." When the no authorization identity is provided, the server SHALL derive the authorization identity from the prepared representation of the provided authentication identity string. This ensures that the derivation of different representations of the authentication identity produce the same authorization identity. Kurt From owner-ietf-sasl Tue Oct 7 23:54:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986spKP098288 for ; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h986spsu098287 for ietf-sasl-bks; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986soKP098275 for ; Tue, 7 Oct 2003 23:54:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h986smlg075769; Wed, 8 Oct 2003 06:54:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 11:54:31 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: ietf-sasl@imc.org In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> 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: My main gripe here is that the I-D implied incorrectly that the IETF character set policy RECOMMENDs protocols be able to use UTF-8 when the police that protocols are REQUIRED to be able to use UTF-8. I think both these "Per IETF character set policy" statements should be deleted. Inserting a note like shown below might be appropriate. > The character encoding scheme used (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols) for > transmitting an authorization identity over protocol is > specified in each authentication mechanism (with the > authentication mechanism's blob being further > restricted/encoded by the protocol profile). At 08:43 AM 10/1/2003, Jeffrey Hutzelman wrote: >>> Per IETF character set >>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>> these and other strings in UTF-8 [UTF-8]. >> >>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>not support UTF-8 transfer of character data. >>[CHARSET-POLICY] says: >> Protocols MUST be able to use the UTF-8 charset, which consists of >> the ISO 10646 coded character set combined with the UTF-8 character >> encoding scheme, as defined in [10646] Annex R (published in >> Amendment 2), for all text. > >It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. > Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. > >So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". From owner-ietf-sasl Wed Oct 8 04:52:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqMKP041254 for ; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98BqMs2041253 for ietf-sasl-bks; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqGKP041248 for ; Wed, 8 Oct 2003 04:52:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 12:52:14 +0100 Message-ID: <3F83FA6D.1030909@isode.com> Date: Wed, 08 Oct 2003 12:52:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sorry about coming with these comments so late. I have just discovered >the SASL list, and there was a lot to read:-) >Feel free to ignore comments that have already been discussed. > >>4. Authentication mechanisms >> >> SASL mechanisms are named by >> >> > >ASCII > > > >> strings, >> (...) >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase >> >> > >ASCII > Ok. >>letters, >> ; digits, "-" and "_" >> >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; >> >> > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > IMHO, this was the intent. I will try to clarify this. >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, >> > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? > Does it matter in this section? >>4.2. Authorization identities and proxy authentication >> >> (...) >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> >> > ^^^^ > >What's a blob? I don't think it's 'something ill-defined or amorphous', >like the dictionary says:-) > I've changed this to "data". >>4.3. Security layers >> >> If use of a security layer is negotiated by the authentication >> protocol exchange, the security layer is applied to all subsequent >> data sent over the connection >> > >... until another security layer or no security layer is negotiated. > >[Added according to section 6.3.] > > > Done. >> In >> order to avoid noninteroperability due to differing normalizations, >> when a mechanism specifies that a string authentication identity or >> password used as input to a cryptographic function (or used for >> comparison) it SHOULD specify that the string first be prepared using >> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >> [StringPrep]. This should be done by both the client (upon getting >> user input or retrieving a value from configuration) and by the >> server (upon receiving the value from the client). >> >> > >What's the point of this duplicate preparation? Why not do it only >at the server side? > > Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] >> > >Nitpick: I think the period should be after [GSSAPI]. > Fixed. >> This >> service name is made available to the authentication mechanism. >> >> > >There should be no paragraph break here. > Fixed. >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" >> >> > >Instead, a paragraph break here. (And a trailing '.'.) > > Fixed. >> A definition >> of the command to initiate the authentication protocol exchange. >> >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. >> >> > >I suggest you rename "an optional challenge" to "optional data", or >put "challenge" in quotes. > > Ok. >> A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics. >> >> > >Add a paragraph break here, since the following is a new item. Remove >"A protocol profile MUST specify" to just make the following a new item >in the list of things that must be specified. > > > >> A protocol profile MUST specify the >> form of the authorization identity (as it is protocol specific, as >> >> I would rather not do this, as this is a single logic item. > > > >>6.3. Multiple authentications >> >> Unless otherwise stated by the protocol's profile, only one >> successful SASL negotiation may occur in a protocol session. >> >> > >This should be mentioned in the "Protocol profile requirements" section. > I agree. >>7.1. Formal syntax >> >> initial-response = *( UTF8-char-no-null ) >> >> > >Why is initial-response required to be UTF-8 when the character encoding >scheme of the rest of the exchange is left to the specifications of the >individual mechanisms? I would think that either initial-response >merely "SHOULD" be UTF-8, like the rest of the exchange. > This is specific to EXTERNAL. I've changed "initial-response" to "extern-init-resp" in order to avoid confusion. > > > >And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >top. > > I've added a sentence about this in the introduction section. Alexey > > From owner-ietf-sasl Wed Oct 8 05:06:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6RKP042074 for ; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98C6RTI042073 for ietf-sasl-bks; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6PKP042068 for ; Wed, 8 Oct 2003 05:06:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:06:21 +0100 Message-ID: <3F83FDBB.70702@isode.com> Date: Wed, 08 Oct 2003 13:06:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Proxy authentication (was WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt) References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Because there are too many issues raised I will be starting a separate thread for each] Kurt D. Zeilenga wrote: >> During the authentication protocol exchange, the mechanism performs >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, and negotiates the use of a >> mechanism-specific security layer. If the use of a security layer is >> agreed upon, then the mechanism must also define or negotiate the >> maximum security layer buffer size that each side is able to receive. >> >>4.2. Authorization identities and proxy authentication >> > > >See note below regarding the term "proxy authentication". > > > ... >> The identity derived from the client's authentication credentials is >> known as the "authentication identity". With any mechanism, >> transmitting an authorization identity of the empty string directs >> the server to derive an authorization identity from the client's >> authentication identity. >> >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". >> >> > >Personally, I refer to this as "proxy authorization". Proxy >authentication makes it sound like the feature can be used by a >proxy to authenticate its users. > > > Jeffrey Hutzelman wrote: >>> If the authorization identity transmitted during the authentication >>> protocol exchange is not the empty string, this is typically referred >>> to as "proxy authentication". >> >> Personally, I refer to this as "proxy authorization". Proxy >> authentication makes it sound like the feature can be used by a >> proxy to authenticate its users. > > The same argument can be made for "proxy authorization". We are > talking about "authentication by proxy", not "authentication to a > proxy". And yes, we're really talking about authorization, not > authentication, but it's not really "authorization by proxy"; it's > just authorization. > > The terminology is pretty bad. It's not clear to me that we need a > name for this at all. But I'm pretty sure the phrase "proxy > authentication" has been in use for a while, and to change it might > cause more confusion than leaving it alone. So, I will leave it as is. Alexey From owner-ietf-sasl Wed Oct 8 05:38:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcaKP043368 for ; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98CcaCQ043367 for ietf-sasl-bks; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcZKP043356 for ; Wed, 8 Oct 2003 05:38:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:38:34 +0100 Message-ID: <3F840549.3040101@isode.com> Date: Wed, 08 Oct 2003 13:38:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>> 5. Protocol profile requirements >>> >>> In order to use this specification, a protocol definition MUST supply >>> the following information: >>> >>> A service name, to be selected from the IANA registry of "service" >>> elements for the GSSAPI host-based service name form. [GSSAPI] This >>> service name is made available to the authentication mechanism. >>> >>> The registry is available at the URL >>> "http://www.iana.org/assignments/gssapi-service-names" A definition >> > Paragraph break. Yes, this is already fixed in my copy. >>> A definition of the method by which the authentication protocol >>> exchange is carried out, including how the challenges and responses >>> are encoded, how the server indicates completion or failure of the >>> exchange, how the client aborts an exchange, and how the exchange >>> method interacts with any line length limits in the protocol. >>> >>> The command SHOULD have a method for the server to include an >>> optional challenge with a success notification. This allows the >>> server to avoid a round trip when using a mechanism which is defined >>> to have the server send additional data along with the indication of >>> successful completion. See section 6.2 of this document for further >>> information. >> > What command? Who says "the method by which the authentication > protocol exchange is carried out" is a command? s/The command/The > exchange method/ Yes. >>> 8.3. Change control >>> >>> Once a SASL mechanism registration has been published by IANA, the >>> author may request a change to its definition. The change request >>> follows the same procedure as the registration request. >> > This sounds a lot like the stringprep loophole, and it makes me nervous. Can you be more specific in what do you want to be changed. Would you rather reference the SASL WG as the Change Controller? >>> In certain situations, it is reasonable to use SASL underneath one of >>> these Transport Security services. The transport service would >>> secure the connection, either service would authenticate the client, >>> and SASL would negotiate the authorization identity. The SASL >>> negotiation would be what moves the protocol from "unauthenticated" >>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>> explicitly intended to handle the case where the transport service >>> secures the connection and authenticates the client and SASL >>> negotiates the authorization identity. >>> >>> When using SASL underneath a sufficiently strong Transport Security >>> service, a SASL security layer would most likely be redundant. The >>> client and server would thus probably want to negotiate off the use >>> of a SASL security layer. >> > > Please don't say this without a _lot_ more text explaining when it is > safe. A common configuration is to run SASL under TLS, using SASL for > client authentication and negotation of the authorization identity. > In this configuration, it is _not_ safe to skip using a SASL security > layer if the client did not check the server's certificate (there is a > tunnelling MitM attack), and it's not a particularly good idea even if > the server cert was checked, because the client's authentication is > still not bound to the encryption keys used at the TLS layer. > > We already have problems with people who think it is actively bad to > use a SASL security layer under TLS. The result is that some insecure > configurations are now widely deployed. Let's not encourage this any > further. Should I just drop this paragraph? >>> The IANA is directed to modify the SASL mechanisms registry as >>> follows: >> >> >> Please reword this to be not so demanding. For example, >> It is requested that IANA update the SASL mechanisms registry >> as follows: > > > It's not demanting; it's perfectly reasonable usage. The IANA works > for the IETF; it is appropriate for the IETF, in the form of a > standards-track document, to direct it to make changes to a registry. > It is also common usage. I've already changed this to be "nicer" to IANA ;-). > Put the TOC at the _top_ of the document, just after the abstract. > See the "Tabel of Contents" section at > http://www.rfc-editor.org/policy.html This is editorial and I don't want to spend time doing this at this stage. I am going to sort this out with the RFC editor directly. Alexey From owner-ietf-sasl Wed Oct 8 06:33:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXCKP046247 for ; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DXCSS046246 for ietf-sasl-bks; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXBKP046240 for ; Wed, 8 Oct 2003 06:33:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:33:05 +0100 Message-ID: <3F841210.7030700@isode.com> Date: Wed, 08 Oct 2003 14:33:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >My main gripe here is that the I-D implied incorrectly that >the IETF character set policy RECOMMENDs protocols be able >to use UTF-8 when the police that protocols are REQUIRED >to be able to use UTF-8. > >I think both these "Per IETF character set policy" statements >should be deleted. Inserting a note like shown below might >be appropriate. > > >> The character encoding scheme used >> >> >(see [CHARSET-POLICY]for IETF policy regarding character sets in IETF protocols) > > > >> for transmitting an authorization identity over protocol is >> specified in each authentication mechanism (with the >> authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> I've changed the first reference as you suggested, and the last to: Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). > > >>>> Per IETF character set >>>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>>> these and other strings in UTF-8 [UTF-8]. >>>> >>>> >>>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>>not support UTF-8 transfer of character data. >>>[CHARSET-POLICY] says: >>> Protocols MUST be able to use the UTF-8 charset, which consists of >>> the ISO 10646 coded character set combined with the UTF-8 character >>> encoding scheme, as defined in [10646] Annex R (published in >>> Amendment 2), for all text. >>> >>> >>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. >>Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. >> >>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> >> From owner-ietf-sasl Wed Oct 8 06:44:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiNKP046617 for ; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DiNVd046616 for ietf-sasl-bks; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiJKP046606 for ; Wed, 8 Oct 2003 06:44:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h98DiBo5027156; Wed, 8 Oct 2003 09:44:11 -0400 (EDT) Message-ID: <3F84154B.7080006@oceana.com> Date: Wed, 08 Oct 2003 09:46:51 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 7 Oct 2003, Ken Murchison wrote: > >>FWIW, I wanted to make the challenge strings used by M$ products a >>SHOULD and those originally intended by c-client a MAY. Mark is against >>making c-client [semi-]uncompliant, which I can also agree with. > > > Especially since c-client is the first, reference, and most widely > deployed implementation of the LOGIN mechanism; and was written by its > inventor. I'm not going to argue numbers, but I'm guessing that there are a significant number of deployed Outlook clients. ;) > I think that c-client's needs are more important that the evil empire's, > and that it would be reprehensible to change specifications to match a > broken implementation in evil empireware. Your comment seems somewhat self serving, but I also find it distasteful to have to cater to M$. The problem is that LOGIN was never a standard, and M$ took it and did their (incorrect) own thing. Since the cat is already out of the bag, and I don't think we can get M$ to change their code, we have to deal with it. > I have never encountered the reported problems with evil empireware. This is probably because c-client isn't used in any SMTP server code (at least AFAIK). AFAIK, the challenge strings are only an issue with Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a SHOULD/MUST for SMTP server code only. I don't think this will make c-client noncompliant, will it? We probably need more input from others on the list, since Mark and I are just rehashing discussions that we've already had. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Oct 8 06:59:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx1KP047180 for ; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Dx1Gc047179 for ietf-sasl-bks; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx0KP047174 for ; Wed, 8 Oct 2003 06:59:00 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:59:01 +0100 Message-ID: <3F841823.6010502@isode.com> Date: Wed, 08 Oct 2003 14:58:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have an impression that there are two many little things to change so that we will need a new Last Call anyway. Is my perception correct? If it is, I will issue a new revision shortly. Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): 1). IANA considerations and registering a familily of SASL mechanisms. 2). Clarification on replacing a security layer 3). Realm 4). Other minor editorial issues. Alexey From owner-ietf-sasl Wed Oct 8 06:58:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwCKP047147 for ; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DwCW6047146 for ietf-sasl-bks; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwBKP047141 for ; Wed, 8 Oct 2003 06:58:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:58:10 +0100 Message-ID: <3F8417F0.6000407@isode.com> Date: Wed, 08 Oct 2003 14:58:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>7. The EXTERNAL mechanism >> >> The mechanism name associated with external authentication is >> "EXTERNAL". >> >> The client sends an initial response with the UTF-8 encoding of the >> authorization identity. The form of the authorization identity is >> further restricted by the application-level protocol's SASL profile. >> >> The server uses information, external to SASL, to determine whether >> the client is authorized to authenticate as the authorization >> identity. >> >> > >It may be appropriate to note that the client can make no >assumptions as what information the server uses in determining >client authorization. E.g., just because TLS was established, >doesn't mean the server will use TLS-provided information. > > Done. The new text reads: The system providing this external information may be, for example, IPSec or TLS. However, the client can make no assumptions as to what information the server can use in determining client authorization. E.g., just because TLS was established, doesn't mean that the server will use the information provided by TLS. >>7.2. Example >> >> The following is an example of an EXTERNAL authentication in the SMTP >> protocol [SMTP-AUTH]. >> >> > >Replace [SMTP-AUTH] with an informative reference to the SMTP base >specification. Insert [SMTP-AUTH] after the word "profile" below. > Done. Alexey From owner-ietf-sasl Wed Oct 8 07:19:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98EJnKP048151 for ; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98EJnH8048149 for ietf-sasl-bks; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98EJiKP048140 for ; Wed, 8 Oct 2003 07:19:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa18273; 8 Oct 2003 10:19 EDT Date: Wed, 08 Oct 2003 10:19:29 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <3F840549.3040101@isode.com> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 08, 2003 13:38:33 +0100 Alexey Melnikov wrote: >>>> 8.3. Change control >>>> >>>> Once a SASL mechanism registration has been published by IANA, the >>>> author may request a change to its definition. The change request >>>> follows the same procedure as the registration request. >>> >> This sounds a lot like the stringprep loophole, and it makes me nervous. > > Can you be more specific in what do you want to be changed. No. Perhaps I'm being paranoid, but the concern is that if mechanism FOO gets registered and implemented, no one should be able to come along later and change FOO to mean some other, non-compatible mechanism. Maybe it's not worth worrying about.. In any case, no, I can't be more specific; I don't know what change could make this better, and I don't think I was really asking for one. It just makes me nervous. > Would you rather reference the SASL WG as the Change Controller? No, especially since the SASL WG will likely conclude within the foreseeable future. >>>> In certain situations, it is reasonable to use SASL underneath one of >>>> these Transport Security services. The transport service would >>>> secure the connection, either service would authenticate the client, >>>> and SASL would negotiate the authorization identity. The SASL >>>> negotiation would be what moves the protocol from "unauthenticated" >>>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>>> explicitly intended to handle the case where the transport service >>>> secures the connection and authenticates the client and SASL >>>> negotiates the authorization identity. >>>> >>>> When using SASL underneath a sufficiently strong Transport Security >>>> service, a SASL security layer would most likely be redundant. The >>>> client and server would thus probably want to negotiate off the use >>>> of a SASL security layer. >>> >> >> Please don't say this without a _lot_ more text explaining when it is >> safe. A common configuration is to run SASL under TLS, using SASL for >> client authentication and negotation of the authorization identity. >> In this configuration, it is _not_ safe to skip using a SASL security >> layer if the client did not check the server's certificate (there is a >> tunnelling MitM attack), and it's not a particularly good idea even if >> the server cert was checked, because the client's authentication is >> still not bound to the encryption keys used at the TLS layer. >> >> We already have problems with people who think it is actively bad to >> use a SASL security layer under TLS. The result is that some insecure >> configurations are now widely deployed. Let's not encourage this any >> further. > > Should I just drop this paragraph? Yeah, IMHO it would be reasonable to just drop the paragraph starting "When using SASL underneath..." >> Put the TOC at the _top_ of the document, just after the abstract. >> See the "Tabel of Contents" section at >> http://www.rfc-editor.org/policy.html > > This is editorial and I don't want to spend time doing this at this stage. > I am going to sort this out with the RFC editor directly. Fair enough. From owner-ietf-sasl Wed Oct 8 08:35:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZKKP051880 for ; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98FZKF7051879 for ietf-sasl-bks; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZJKP051870 for ; Wed, 8 Oct 2003 08:35:19 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZBaZ018004; Wed, 8 Oct 2003 08:35:11 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZB5b002839; Wed, 8 Oct 2003 08:35:11 -0700 Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F84154B.7080006@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> 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: On Wed, 8 Oct 2003, Ken Murchison wrote: > > Especially since c-client is the first, reference, and most widely > > deployed implementation of the LOGIN mechanism; and was written by its > > inventor. > I'm not going to argue numbers, but I'm guessing that there are a > significant number of deployed Outlook clients. ;) Even if Outlook may be more widespread, there are millions of deployed Pine clients (we have the numbers). c-client is more than just client code; it's also the engine behind UW imapd and ipop3d. UW imapd is the most widely deployed IMAP server. > Your comment seems somewhat self serving, Well, I could say the same for many comments from ... Let's not go here. > but I also find it distasteful > to have to cater to M$. > The problem is that LOGIN was never a standard, > and M$ took it and did their (incorrect) own thing. LOGIN was not documented because I followed the rules. IESG said "no more plaintext password authentication mechanisms." IESG didn't offer any wiggle room the way. Politics allowed PLAIN to be snuck through but not LOGIN (which preceeded PLAIN by 3 1/2 years). If you're going to cater to Microsoft's bugs, then much of IMAP needs to be thrown out because of broken behavior in their software. Microsoft should be made to fix their bugs instead. I would like to see the security people redefine TLS so that that the maximum payload is 5 bytes less than 16K (rather than 16K), since Microsoft requires that. > This is probably because c-client isn't used in any SMTP server code (at > least AFAIK). AFAIK, the challenge strings are only an issue with > Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a > SHOULD/MUST for SMTP server code only. I don't think this will make > c-client noncompliant, will it? I am working an an SMTP server. I don't think that an SMTP-only kludge to accomodate a bug is appropriate when there is another alternative (that is, PLAIN). The correct answer is that if Outlook has problems using LOGIN, then it can always use PLAIN. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Wed Oct 8 09:24:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOxKP055202 for ; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98GOxTG055201 for ietf-sasl-bks; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOvKP055196 for ; Wed, 8 Oct 2003 09:24:58 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 17:24:57 +0100 Message-ID: <3F843A58.20103@isode.com> Date: Wed, 08 Oct 2003 17:24:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org, Peter Saint-Andre Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>>> When using SASL underneath a sufficiently strong Transport Security >>>>> service, a SASL security layer would most likely be redundant. The >>>>> client and server would thus probably want to negotiate off the use >>>>> of a SASL security layer. >>>> >>> Please don't say this without a _lot_ more text explaining when it is >>> safe. A common configuration is to run SASL under TLS, using SASL for >>> client authentication and negotation of the authorization identity. >>> In this configuration, it is _not_ safe to skip using a SASL security >>> layer if the client did not check the server's certificate (there is a >>> tunnelling MitM attack), and it's not a particularly good idea even if >>> the server cert was checked, because the client's authentication is >>> still not bound to the encryption keys used at the TLS layer. >>> >>> We already have problems with people who think it is actively bad to >>> use a SASL security layer under TLS. The result is that some insecure >>> configurations are now widely deployed. Let's not encourage this any >>> further. >> >> Should I just drop this paragraph? > > Yeah, IMHO it would be reasonable to just drop the paragraph starting > "When using SASL underneath..." Done. Alexey From owner-ietf-sasl Wed Oct 8 10:40:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HelKP059213 for ; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HelkI059212 for ietf-sasl-bks; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HejKP059207 for ; Wed, 8 Oct 2003 10:40:46 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id E3F3C63EB6; Wed, 8 Oct 2003 12:40:46 -0500 (CDT) Date: Wed, 8 Oct 2003 12:40:46 -0500 From: Peter Saint-Andre To: xmppwg@jabber.org Cc: Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031008174046.GB31898@jabber.org> References: <3F8334ED.80504@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8334ED.80504@isode.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Oct 07, 2003 at 10:49:33PM +0100, Alexey Melnikov wrote: > I would like to raise several SASL related issues in XMPP document. > (Sorry for crosspost and sorry for being late with reviewing this.) No apologies necessary -- your feedback is appreciated. > 1). > > 7. The initiating entity MUST provide an authzid during SASL > > negotiation. The authzid-value MUST be a valid JID of the form > > (i.e., a domain identifier only) for servers and of the > > form (i.e., node identifier, domain > > identifier, and resource identifier) for clients. The initiating > > entity MAY process the authzid-value in accordance with the rules > > defined in Addressing Scheme (Section 3) before providing it to > > the receiving entity, but is NOT REQUIRED to do so; however, the > > receiving entity MUST verify that the authzid-value provided by > > the initiating entity conforms to the rules defined therein. > > Not all SASL mechanisms are capable of transmitting authorization > identity, so this requirement might be problematic. > > Also, the revision of RFC 2222 says that the client must not specify > authorization-id unless it wants to impersonate some other entity: > > As a client might not have the same information as the server, > clients SHOULD NOT themselves try to derive authorization identities > from authentication identities when clients could instead transmit an > authorization identity of the empty string. > > So, the text should be reworded reflect that an authorization identity > is optional and that if one is provided, it is in the form described above. My understanding from an earlier thread on the XMPP WG list was that providing the authorization identity in this manner was the approach preferred by the SASL community. I think the fundamental issue here is that for XMPP clients, the authorization identity is a "full JID" (i.e., node@host/resource) that is asserted by the connecting client, not derived by the server. Perhaps this usage is not consistent with the definition of authorization identity in RFC 2222? We'd have to look at the implications of this for client assertion of a full JID (perhaps this should be defined only in draft-ietf-xmpp-im). > 2). > > > This series of challenge/response pairs continues until one of three > > things happens: > > > > 1. The initiating entity aborts the handshake by sending an > > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > > namespace to the receiving entity. Upon receiving the > > element, the receiving entity MUST terminate the TCP connection. > > I think the requirement to drop TCP connection is unreasonable here. > There are several valid reasons why the client may retry failed > authentication: > 1). User typed in a wrong password, the client should retry the same > SASL mechanism a reasonable number of times. > 2). The client invoked a SASL mechanism that reported that it can't be > used because of misconfiguration (e.g. kerberos configuration file is > missing). The client than sends to the server and tries another > mechanism. This seems reasonable. I think we were attempting to ensure that the connecting entity could not abuse the opened TCP connection for an unspecified period of time. > 3). > > > 3. The receiving entity reports success of the handshake by sending > > a element qualified by the > > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > > entity; this element MAY optionally contain character data (in > > SASL terminology "additional data with success"). Upon receiving > > the element, the initiating entity MUST initiate a new > > stream by sending an opening XML stream header to the receiving > > entity (it is not necessary to send a closing > > element first, since the receiving entity and initiating entity > > MUST consider the original stream to be closed upon sending or > > receiving the element). Upon receiving the new stream > > header from the initiating entity, the receiving entity MUST > > respond by sending a new XML stream header to the initiating > > entity, along with any remaining available features (but NOT > > including the STARTTLS feature or any authentication mechanisms) > > or an empty features element (to signify that no additional > > features are available); note that any such additional features > > are not defined herein, and MUST be defined by the relevant > > extension to XMPP. > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > successful SASL authentication. > Some of them require that the client compares the list of the advertised > mechanism with the one before the authentication. > This is done to prevent man-in-the-middle attacks when an attacker > removes strong SASL mechanisms from the list of supported mechanisms. > (Whether this check is useful in practice is another matter. I am not > sure whether anybody implements it). OK, I'll look at what those other protocols require, and how they word the requirement. It seems good to have this check in place. > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. Thanks for the suggested text. > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) I see no strong reason to relax the requirement just for XMPP. > 5). > >6.3 SASL Errors > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > Do you mean invalid base64 encoding here or something else? It could be invalid base64 encoding, but we were thinking especially that the decoded response is not consistent with the challenge format required by the selected SASL mechanism. > 6). > > >6.3 SASL Errors > > > > The following SASL-related error conditions are defined: > > > > o -- The receiving entity acknowledges an > > element sent by the initiating entity; sent in response to the > > element. > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > or with initial challenge data. Example: SASL PLAIN mechanism. > > > o -- The mechanism chosen by the initiating > > entity may be used only if the stream is already encrypted; sent > > in response to the element. > > > > o -- The authzid provided by the initiating > > entity is invalid, either because it is incorrectly formatted or > > because the initiating entity does not have permissions to > > authorize that ID; sent in response to a element. > > or with initial challenge data. > > > o -- The initiating entity did not provide a > > mechanism or requested a mechanism that is not supported by the > > receiving entity; sent in response to the element. > > > > o -- The realm provided by the initiating entity > > (in mechanisms that support the concept of a realm) does not match > > one of the hostnames served by the receiving entity; sent in > > response to a element. > > or with initial challenge data. > > > o -- The mechanism requested by the initiating > > entity is weaker than server policy permits for that initiating > > entity; sent in response to the element. > > or with initial challenge data. > > > o -- The authentication failed because the > > initiating entity did not provide valid credentials (this includes > > the case of an unknown username); sent in response to a > element. > > or with initial challenge data. I've fixed these in my working copy. > 7). > > >12.4 Order of Layers > > > > The order of layers in which protocols MUST be stacked is as follows: > > > > 1. TCP > > > > 2. TLS > > > > 3. SASL > > > > 4. XMPP > > > > The rationale for this order is that TCP is the base connection layer > > used by all of the protocols stacked on top of TCP, TLS is often > > provided at the operating system layer, SASL is often provided at the > > application layer, and XMPP is the application itself. > > This should be referenced in "6.4 SASL Definition" section, because it > is related to the XMPP profile of SASL. Fixed in my working copy. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From owner-ietf-sasl Wed Oct 8 10:49:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HnfKP059704 for ; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HneC2059703 for ietf-sasl-bks; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HndKP059698 for ; Wed, 8 Oct 2003 10:49:40 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id C891F151D9B; Wed, 8 Oct 2003 13:49:38 -0400 (EDT) To: Ken Murchison , "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> From: Sam Hartman Date: Wed, 08 Oct 2003 13:49:38 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 8 Oct 2003 08:35:11 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: It seems like you may want to document clearly the interoperability concern. Mention specific products as examples if it makes your text more clear. Just make sure your claims are accurate. From owner-ietf-sasl Wed Oct 8 10:57:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv3KP060293 for ; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Hv3p5060292 for ietf-sasl-bks; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv2KP060286 for ; Wed, 8 Oct 2003 10:57:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Huulg081187; Wed, 8 Oct 2003 17:56:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 22:56:38 -0700 To: iesg@ietf.org From: "Kurt D. Zeilenga" Subject: Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, SASL WG In-Reply-To: <3F8334ED.80504@isode.com> References: <3F8334ED.80504@isode.com> 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: To the IESG, I concur with Alexey's recent comments regarding XMPP's SASL Profile. I have a few addition concerns regarding this profile. The scope of my review was, due to time constraints, was limited to the profile. I not sure why the documents says that SASL and TLS security layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), but this recommendation is, I believe, flawed. There are numerous use cases where implementations SHOULD establish additional layers. For example, establishing additional SASL layers may prevent certain kinds of tunneling man-in-the-middle attacks. The requirement that initiating receiving entity drop all knowledge it learned before negotiating SASL layers (rule 5) is too broad. This could be viewed as requiring the implement to forget knowledge it gained previously in a secure manner (such as an externally established lower level (IPSEC or TLS) identity information). Likewise for rule 6. For rule 8, a normative reference to the base64 encoding algorithm should be provided. I am also concerned by the use of the term "stream encryption" in the document as this doesn't imply, in my eyes, "stream integrity". It's unclear to me which imperatives imply when encryption, integrity, and/or in combination with other security services which TLS provides. Additionally, I would like to note that the document suffers from a number of nits. As I only did a casual scan, this list is likely no where near complete. I suggest that XMMP WG members be asked to do a more careful review for nits. Acronym not spelled out in title: XMMP Citiation in abstract Used old citation style (numeric tags instead of mnemonic tags) Acronyms not spelled out on first use in Abstract: XML Table of contents too long Acronyms not spelled out on first use in body: XML, JID Confusing upper casing of words: COULD Odd use of 2119 keywords: "MAY optionally" From owner-ietf-sasl Wed Oct 8 11:25:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPvKP062655 for ; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98IPvQb062654 for ietf-sasl-bks; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPuKP062648 for ; Wed, 8 Oct 2003 11:25:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h98IOf5t013327; Wed, 8 Oct 2003 14:24:41 -0400 Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT) From: Rob Siemborski To: Peter Saint-Andre cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) In-Reply-To: <20031008174046.GB31898@jabber.org> Message-ID: References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> 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: On Wed, 8 Oct 2003, Peter Saint-Andre wrote: > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > > successful SASL authentication. > > Some of them require that the client compares the list of the advertised > > mechanism with the one before the authentication. This claim isn't true. SMTP has a MAY for this, the other protocols don't express an opinion one way or the other. I know some IMAP and POP implementations remove the capability after a successful authentication (to indicate that the AUTHENTICATE/AUTH command is no longer valid) > > This is done to prevent man-in-the-middle attacks when an attacker > > removes strong SASL mechanisms from the list of supported mechanisms. > > (Whether this check is useful in practice is another matter. I am not > > sure whether anybody implements it). > > OK, I'll look at what those other protocols require, and how they word > the requirement. It seems good to have this check in place. I'm not sure its terribly useful, since the real way to prevent this MitM attack is that a client should not use a mechanism that does not support its minimum security requirements, not find out after the fact that you have an active attacker. I will also be posting IDs within the next few days that are revisions to RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be useful to look at (hopefully they will be clearer). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 8 12:10:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAuKP064383 for ; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JAuvd064382 for ietf-sasl-bks; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAmKP064372 for ; Wed, 8 Oct 2003 12:10:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:10:25 +0100 Message-ID: <3F84611F.9020601@isode.com> Date: Wed, 08 Oct 2003 20:10:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>2). >> >> >>> This series of challenge/response pairs continues until one of three >>> things happens: >>> >>> 1. The initiating entity aborts the handshake by sending an >>> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' >>> namespace to the receiving entity. Upon receiving the >>> element, the receiving entity MUST terminate the TCP connection. >>> >>> >>I think the requirement to drop TCP connection is unreasonable here. >>There are several valid reasons why the client may retry failed >>authentication: >>1). User typed in a wrong password, the client should retry the same >>SASL mechanism a reasonable number of times. >>2). The client invoked a SASL mechanism that reported that it can't be >>used because of misconfiguration (e.g. kerberos configuration file is >>missing). The client than sends to the server and tries another >>mechanism. >> >> > >This seems reasonable. I think we were attempting to ensure that the >connecting entity could not abuse the opened TCP connection for an >unspecified period of time. > Closing connection or refusing to perform any tasks after a certain number of failures are two common implementation practice in SMTP and other protocols. I think you should mention them, but don't require everyone to implement them. >>3). >> >> >>> 3. The receiving entity reports success of the handshake by sending >>> a element qualified by the >>> 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating >>> entity; this element MAY optionally contain character data (in >>> SASL terminology "additional data with success"). Upon receiving >>> the element, the initiating entity MUST initiate a new >>> stream by sending an opening XML stream header to the receiving >>> entity (it is not necessary to send a closing >>> element first, since the receiving entity and initiating entity >>> MUST consider the original stream to be closed upon sending or >>> receiving the element). Upon receiving the new stream >>> header from the initiating entity, the receiving entity MUST >>> respond by sending a new XML stream header to the initiating >>> entity, along with any remaining available features (but NOT >>> including the STARTTLS feature or any authentication mechanisms) >>> or an empty features element (to signify that no additional >>> features are available); note that any such additional features >>> are not defined herein, and MUST be defined by the relevant >>> extension to XMPP. >>> >>> >>Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a >>successful SASL authentication. >>Some of them require that the client compares the list of the advertised >>mechanism with the one before the authentication. >>This is done to prevent man-in-the-middle attacks when an attacker >>removes strong SASL mechanisms from the list of supported mechanisms. >>(Whether this check is useful in practice is another matter. I am not >>sure whether anybody implements it). >> >> > >OK, I'll look at what those other protocols require, and how they word >the requirement. It seems good to have this check in place. > I don't have a strong feeling about this. I am just emphasizing the difference between other protocols and XMPP in this case. A security person should comment on this. >>4). There was a recent discussion on the bugtraq mailing list about >>handling invalid base64 data. It turned out that different >>implementations handle >>this differently, for example: >>... >> >>(You might decide to relax this for XMPP and to allow spaces and/or >>CRLFs anywhere in the data.) >> >> > >I see no strong reason to relax the requirement just for XMPP. > This is fine. I was just thinking about a base64 encoder that enforces a line length limit and will insert CRLF automatically. >>5). >> >> >>>6.3 SASL Errors >>> >>> o -- The data provided by the initiating entity >>> could not be processed, e.g. because does not adhere to the >>> protocol for the requested mechanism; sent in response to the >>> element. >>> >>> >>Do you mean invalid base64 encoding here or something else? >> >> > >It could be invalid base64 encoding, but we were thinking especially >that the decoded response is not consistent with the challenge format >required by the selected SASL mechanism. > > Challenge format is specific to a SASL mechanism. As far as the protocol using SASL is concerned, invalid SASL mechanism format is not different from "authentication failure". An error from a SASL mechanism is different from an error resulting in inability to decode base64 data. These errors happen at different layers, so they should have different error tags. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 8 12:32:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JW1KP065291 for ; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JW1Zi065290 for ietf-sasl-bks; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JVxKP065282 for ; Wed, 8 Oct 2003 12:31:59 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> Date: Wed, 08 Oct 2003 20:31:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 8 13:21:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL8KP066772 for ; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98KL8Dg066771 for ietf-sasl-bks; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL7KP066766 for ; Wed, 8 Oct 2003 13:21:07 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id A832AAC0A; Wed, 8 Oct 2003 13:28:14 -0700 (PDT) To: xmppwg@jabber.org Cc: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 13:28:14 -0700 In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Kurt D. Zeilenga" writes: > I concur with Alexey's recent comments regarding XMPP's SASL > Profile. I have a few addition concerns regarding this profile. > The scope of my review was, due to time constraints, was limited > to the profile. > > I not sure why the documents says that SASL and TLS security > layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this recommendation is, I believe, flawed. There are numerous use > cases where implementations SHOULD establish additional layers. > For example, establishing additional SASL layers may prevent > certain kinds of tunneling man-in-the-middle attacks. Could you describe some of them? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 13:46:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk3KP067429 for ; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kk3Xn067428 for ietf-sasl-bks; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk2KP067421 for ; Wed, 8 Oct 2003 13:46:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Kk3lg082611; Wed, 8 Oct 2003 20:46:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 01:45:45 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> 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: At 04:52 AM 10/8/2003, Alexey Melnikov wrote: >>> In >>> order to avoid noninteroperability due to differing normalizations, >>> when a mechanism specifies that a string authentication identity or >>> password used as input to a cryptographic function (or used for >>> comparison) it SHOULD specify that the string first be prepared using >>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>> [StringPrep]. This should be done by both the client (upon getting >>> user input or retrieving a value from configuration) and by the >>> server (upon receiving the value from the client). >>> >> >>What's the point of this duplicate preparation? Why not do it only >>at the server side? >> >Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. Alexey, the current text suggests that client (1) prep the value before sending, the server then preps it (2) again (before comparing it to the store value, which also should be prep'ed (3) either before storing it or before each compare). We need to REQUIRE that mechanisms specify how character strings are to be prepared for comparison and RECOMMEND that they use SASLprep for simple user names and passwords. We should not suggest that mechanisms should do both (1) and (2). (1) and (3) OR (2) or (3) are sufficient to ensure proper matching. Kurt From owner-ietf-sasl Wed Oct 8 13:53:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr5KP067641 for ; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kr5X1067639 for ietf-sasl-bks; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr3KP067634 for ; Wed, 8 Oct 2003 13:53:04 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h98Kr0js010724 for ; Wed, 8 Oct 2003 15:53:00 -0500 Received: from att.com (unknown[135.210.35.140](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031008205022gw100lr6v3e> (Authid: tony); Wed, 8 Oct 2003 20:50:22 +0000 Message-ID: <3F84792B.1000301@att.com> Date: Wed, 08 Oct 2003 16:52:59 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011022 Netscape6/6.2 X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: xmppwg@jabber.org CC: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> In-Reply-To: <3F8334ED.80504@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: White space and CRLFs were specifically allowed in the original MIME base64 specification because of: line length limitations in the underlying protocols gateways that would add or subtract white space willy-nilly it was useful being able to work with base64 data in small chunks when doing development and debugging The first two issues don't apply here, but the last one certainly still does. So I'd recommend that whitespace and CRLFs be ignored. Tony Hansen tony@att.com Alexey Melnikov wrote: > The IESG wrote: > >> The IESG has received a request from the Extensible Messaging and >> Presence Protocol WG to consider the following document: >> >> - 'XMPP Core ' >> as a Proposed Standard > > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. > > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) From owner-ietf-sasl Wed Oct 8 14:02:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L25KP068097 for ; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98L25rp068096 for ietf-sasl-bks; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L24KP068091 for ; Wed, 8 Oct 2003 14:02:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98L26lg082716; Wed, 8 Oct 2003 21:02:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 02:01:48 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: SASL WG In-Reply-To: <3F841823.6010502@isode.com> References: <3F841823.6010502@isode.com> 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: At 06:58 AM 10/8/2003, Alexey Melnikov wrote: >I have an impression that there are two many little things to change so that we will need a new Last Call anyway. >Is my perception correct? Yes. Given the large number of issues, I prefer to give you as fairly wide latitude to make the changes you believe are appropriate. Once a new I-D is ready, we'll then ask the WG to review the I-D to see consensus supports the changes made and the document as a whole. >If it is, I will issue a new revision shortly. Great! >Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): >1). IANA considerations and registering a familily of SASL mechanisms. You might look at BCP 64 (RFC 3383) guidelines for OID descriptors and families of OID descriptors as an example. >2). Clarification on replacing a security layer I would like to hear folks comments on the appropriateness of uninstalling layers after a failed subsequent exchange. >3). Realm I have not yet heard any arguments to keep the realm text. Kurt From owner-ietf-sasl Wed Oct 8 15:04:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4ZKP070106 for ; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98M4YaP070105 for ietf-sasl-bks; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4XKP070100 for ; Wed, 8 Oct 2003 15:04:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98M4Xlg083031; Wed, 8 Oct 2003 22:04:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009030341.02bc0108@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:04:16 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> 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: At 07:19 AM 10/8/2003, Jeffrey Hutzelman wrote: >>Would you rather reference the SASL WG as the Change Controller? > >No, especially since the SASL WG will likely conclude within the foreseeable future. The IESG should have change control mechanisms registered by Standards Action. Kurt From owner-ietf-sasl Wed Oct 8 16:14:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEKKP072462 for ; Wed, 8 Oct 2003 16:14:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NEKZN072458 for ietf-sasl-bks; Wed, 8 Oct 2003 16:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEIKP072453 for ; Wed, 8 Oct 2003 16:14:19 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NEETO017641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:14:17 -0400 (EDT) Message-ID: <3F849A43.6020508@columbia.edu> Date: Wed, 08 Oct 2003 19:14:11 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090408090503010507000209" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090408090503010507000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >To the IESG, > >I concur with Alexey's recent comments regarding XMPP's SASL >Profile. I have a few addition concerns regarding this profile. >The scope of my review was, due to time constraints, was limited >to the profile. > >I not sure why the documents says that SASL and TLS security >layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >but this recommendation is, I believe, flawed. There are numerous use >cases where implementations SHOULD establish additional layers. >For example, establishing additional SASL layers may prevent >certain kinds of tunneling man-in-the-middle attacks. > > The "security" is specific to the SASL encryption and integrity protection; not authentication. Clearly, SASL authentication might be used to help detect a man-in-the-middle attack. If you are arguing that SASL encryption/integrity protection should be used on top of TLS encryption/integrity protection, the only reason for doing so is that you do not trust the TLS encryption/integrity protection. I do not see where the man-in-the-middle attack would be coming from? >The requirement that initiating receiving entity drop all knowledge >it learned before negotiating SASL layers (rule 5) is too broad. >This could be viewed as requiring the implement to forget knowledge >it gained previously in a secure manner (such as an externally >established lower level (IPSEC or TLS) identity information). >Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are actively providing encryption/integrity protection. In this situation, it is known that TLS is not in use. I doubt it is known whether or not IPSec is in use for the entire communication path. Therefore, all information obtained prior to the establishment of encryption/integrity protection must be considered suspect. I believe the problem is one of language. Can we replace all references to "security layer" to read "data protection layer"? >I am also concerned by the use of the term "stream encryption" >in the document as this doesn't imply, in my eyes, "stream >integrity". It's unclear to me which imperatives imply when >encryption, integrity, and/or in combination with other security >services which TLS provides. > > I agree. We are not concerned with Stream Encryption but Data Protection. Replace "Stream Encryption" with "Data Protection" throughout. I have not completed a security review of these documents as yet. I am simply responding to Kurt's comments. Jeffrey Altman --------------ms090408090503010507000209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMTQxMVowIwYJKoZIhvcNAQkEMRYEFPSFDtAa4rTl gsvSQ23L6JnMGdqZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAJL99vPLNN9ZLX+NXMt5FZ6G8loGh zTc412pdHSq2PnQWkH/IRwbLb0riGgm1FIUPx85msJgIxHlbzuioX670UivRi5esVZJitT0H MMa6NtTc2+Mt391srr4T0QdhglgJUaZ0181nhm1dQzwNZmZ8A+JGWtbWqeceyg7axT2lOg32 rNFAiemS+i9C1kUiROICpXwjiqYg2qvXH2rV3ffKrYHfeTG9KWBZRWgqlcYDO2hMDQz+oa1b VknnzdTZXeiq7KgH2CJZMqfpuqYUPBudNSZ+ny9ojGxucpmuHkvxuG4+UApPCup8VBfVcO1e bJIzwCN9mbE7YEi3mPCCqeFYLQAAAAAAAA== --------------ms090408090503010507000209-- From owner-ietf-sasl Wed Oct 8 16:09:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9rKP072180 for ; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98N9rG4072179 for ietf-sasl-bks; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9qKP072174 for ; Wed, 8 Oct 2003 16:09:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98N9qlg083607; Wed, 8 Oct 2003 23:09:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:41:49 -0700 To: EKR From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> 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: At 01:28 PM 10/8/2003, Eric Rescorla wrote: >"Kurt D. Zeilenga" writes: >> I concur with Alexey's recent comments regarding XMPP's SASL >> Profile. I have a few addition concerns regarding this profile. >> The scope of my review was, due to time constraints, was limited >> to the profile. >> >> I not sure why the documents says that SASL and TLS security >> layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >> but this recommendation is, I believe, flawed. There are numerous use >> cases where implementations SHOULD establish additional layers. >> For example, establishing additional SASL layers may prevent >> certain kinds of tunneling man-in-the-middle attacks. >Could you describe some of them? XMPP's TLS profile allows establishment of TLS even though the implementation's certificate verification has failed: If the above methods fail, the certificate SHOULD be presented to a human (e.g., an end user or server administrator) for approval; if presented, the receiver MUST deliver the entire certificate chain to the human, who SHOULD be given the option to store the Root CA certificate (not the service or End Entity certificate) and to not be queried again regarding acceptance of the certificate for some reasonable period of time. Given the likelihood that the end user will inappropriately accept the certificate, attackers can easily insert a TLS-protected machine in the middle. Given this, it is quite reasonable for implementors to offer (and deployers to demand) additional safeguards. Kurt From owner-ietf-sasl Wed Oct 8 16:37:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbmKP073194 for ; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NbmRc073193 for ietf-sasl-bks; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbkKP073181 for ; Wed, 8 Oct 2003 16:37:47 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NbegG021882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:37:44 -0400 (EDT) Message-ID: <3F849FC1.1080104@columbia.edu> Date: Wed, 08 Oct 2003 19:37:37 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600070607010700010909" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050600070607010700010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 01:28 PM 10/8/2003, Eric Rescorla wrote: > > >>"Kurt D. Zeilenga" writes: >> >> >>>I concur with Alexey's recent comments regarding XMPP's SASL >>>Profile. I have a few addition concerns regarding this profile. >>>The scope of my review was, due to time constraints, was limited >>>to the profile. >>> >>>I not sure why the documents says that SASL and TLS security >>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>but this recommendation is, I believe, flawed. There are numerous use >>>cases where implementations SHOULD establish additional layers. >>>For example, establishing additional SASL layers may prevent >>>certain kinds of tunneling man-in-the-middle attacks. >>> >>> >>Could you describe some of them? >> >> > >XMPP's TLS profile allows establishment of TLS even though the >implementation's certificate verification has failed: > If the above methods fail, the certificate SHOULD be presented > to a human (e.g., an end user or server administrator) for > approval; if presented, the receiver MUST deliver the entire > certificate chain to the human, who SHOULD be given the option > to store the Root CA certificate (not the service or End Entity > certificate) and to not be queried again regarding acceptance of > the certificate for some reasonable period of time. > >Given the likelihood that the end user will inappropriately >accept the certificate, attackers can easily insert a >TLS-protected machine in the middle. Given this, it is quite >reasonable for implementors to offer (and deployers to demand) >additional safeguards. > >Kurt > > If the policy requirement of the deployers is to not accept the risk that the end user will accept certificate chains which cannot be verified by algorithmic means, then the policy should fail the certificate validation without presenting the certificates to the end user. The TLS session at that point must be aborted. At this point the TCP session must be closed. When XMPP attempts to reconnect, it must not attempt to establish a TLS session and in turn must attempt to negotiate a SASL mechanism which provides encryption/integrity protection. There is zero benefit to negotiating both TLS and SASL encryption/integrity protection. Btw, if it is possible for SASL to validate the TLS Client and Server Finished messages as computed by both the client and server, this can be performed during SASL authentication to detect a man-in-the-middle attack. This is the process which is used in TELNET START-TLS when combined with TELNET AUTH. Jeffrey Altman --------------ms050600070607010700010909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMzczN1owIwYJKoZIhvcNAQkEMRYEFL7qB6VLKFhA xcvIVRWzNb7OwJiYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAnbQCkWQGl0WeHwIi1zvOG7Gx2LK0 ITzK27cRdxMy9nvy5ZRMW8oYxUNoMghWjAqwvsMnoBFkeUUnqCajwU/KCcAasU7liZAus95p i4pAt8ja4O0+i8YimxPJCW1AryYsTXHdZJOD8ejXrQEOpCd6ZoTWnBjC1YWsWqg+ru4VI+ip M1oLJ+97Xs0F7EAoTP92Bjmog47ugTVtMsGvHcWFqWZk7kes5jsIKNrdjRqQKDtcgiCC+84T XtnAL05PH1JgG953sq8ABwtddTCwG6uzJlsPv5tiZxTI7HwBzhHhOjesSTYh9BushM9KTDeM nIiXLVE/XvBpjhV7Fwa+woXzqAAAAAAAAA== --------------ms050600070607010700010909-- From owner-ietf-sasl Wed Oct 8 17:25:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990PAKP074524 for ; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990PAcl074523 for ietf-sasl-bks; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990P8KP074518 for ; Wed, 8 Oct 2003 17:25:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h990P1lg084317; Thu, 9 Oct 2003 00:25:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008172120.03d58f10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 17:24:30 -0700 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: <3F849FC1.1080104@columbia.edu> References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> <3F849FC1.1080104@columbia.edu> 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: At 04:37 PM 10/8/2003, Jeffrey Altman wrote: >Kurt D. Zeilenga wrote: > >>At 01:28 PM 10/8/2003, Eric Rescorla wrote: >> >> >>>"Kurt D. Zeilenga" writes: >>> >>> >>>>I concur with Alexey's recent comments regarding XMPP's SASL >>>>Profile. I have a few addition concerns regarding this profile. >>>>The scope of my review was, due to time constraints, was limited >>>>to the profile. >>>> >>>>I not sure why the documents says that SASL and TLS security >>>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>>but this recommendation is, I believe, flawed. There are numerous use >>>>cases where implementations SHOULD establish additional layers. >>>>For example, establishing additional SASL layers may prevent >>>>certain kinds of tunneling man-in-the-middle attacks. >>>> >>>Could you describe some of them? >>> >> >>XMPP's TLS profile allows establishment of TLS even though the >>implementation's certificate verification has failed: >> If the above methods fail, the certificate SHOULD be presented >> to a human (e.g., an end user or server administrator) for >> approval; if presented, the receiver MUST deliver the entire >> certificate chain to the human, who SHOULD be given the option >> to store the Root CA certificate (not the service or End Entity >> certificate) and to not be queried again regarding acceptance of >> the certificate for some reasonable period of time. >> >>Given the likelihood that the end user will inappropriately >>accept the certificate, attackers can easily insert a >>TLS-protected machine in the middle. Given this, it is quite >>reasonable for implementors to offer (and deployers to demand) >>additional safeguards. >> >>Kurt >If the policy requirement of the deployers is to not accept the risk >that the end user will accept certificate chains which cannot be verified >by algorithmic means, The policy might be to mitigate the risk that users won't do the appropriate checks by requiring an additional layer of security. >There is zero benefit to negotiating both TLS and SASL encryption/integrity >protection. I disagree. Multiple layer defenses have benefits. Kurt From owner-ietf-sasl Wed Oct 8 17:47:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990lmKP075378 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990lmFa075377 for ietf-sasl-bks; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990llKP075371 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D663F151D9B; Wed, 8 Oct 2003 20:47:49 -0400 (EDT) To: xmppwg@jabber.org Cc: "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> From: Sam Hartman Date: Wed, 08 Oct 2003 20:47:49 -0400 In-Reply-To: <3F849A43.6020508@columbia.edu> (Jeffrey Altman's message of "Wed, 08 Oct 2003 19:14:11 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: Do we actually need to have this argument here? I tend to agree with Kurt but it's not clear that having this discussion will actually influence the draft. Jeff, do you see anything wrong with allowing a SASL security layer and TLS to be used in conjunction? If I'm reading your argument right, you have not actually presented any argument against this configuration, you have just argued that Kurt's reason for wanting to do so is not correct. From owner-ietf-sasl Wed Oct 8 20:40:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993euKP080566 for ; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h993eudj080565 for ietf-sasl-bks; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993etKP080554 for ; Wed, 8 Oct 2003 20:40:55 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 20:49:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h993ejXg001235; Wed, 8 Oct 2003 20:40:46 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 20:45:24 -0700 From: "Joseph Salowey" To: "'EKR'" , Cc: , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 20:40:43 -0700 Message-ID: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 03:45:24.0730 (UTC) FILETIME=[C59D05A0:01C38E17] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 1:28 PM > To: xmppwg@jabber.org > Cc: iesg@ietf.org; SASL WG > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > "Kurt D. Zeilenga" writes: > > I concur with Alexey's recent comments regarding XMPP's > SASL Profile. > > I have a few addition concerns regarding this profile. The > scope of my > > review was, due to time constraints, was limited to the profile. > > > > I not sure why the documents says that SASL and TLS security layers > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this > > recommendation is, I believe, flawed. There are numerous use cases > > where implementations SHOULD establish additional layers. > For example, > > establishing additional SASL layers may prevent certain kinds of > > tunneling man-in-the-middle attacks. > Could you describe some of them? > If the TLS tunnel is only server authenticated and the client supports a particular SASL method (perhaps even in a different protocol)that provides mutual authentication both inside and outside a TLS tunnel there is a vulnerability. In this case if only the message protection of TLS is used you cannot be sure that the client endpoint of the TLS tunnel is the same client endpoint that the server authenticated with SASL. To mitigate this problem you can: - Use the protection from the inner SASL method - Have the SASL authentication mechanism authenticate the TLS Session ID or some similar parameter - Require different credentials be used by a SASL mechanism when operating inside or outside a TLS tunnel. Joe > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > From owner-ietf-sasl Wed Oct 8 21:13:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DVKP081670 for ; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994DVOc081669 for ietf-sasl-bks; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DUKP081664 for ; Wed, 8 Oct 2003 21:13:30 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 151AEAC09; Wed, 8 Oct 2003 21:20:35 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 21:20:35 -0700 In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > -----Original Message----- > > From: owner-ietf-sasl@mail.imc.org > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > Sent: Wednesday, October 08, 2003 1:28 PM > > To: xmppwg@jabber.org > > Cc: iesg@ietf.org; SASL WG > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > "Kurt D. Zeilenga" writes: > > > I concur with Alexey's recent comments regarding XMPP's > > SASL Profile. > > > I have a few addition concerns regarding this profile. The > > scope of my > > > review was, due to time constraints, was limited to the profile. > > > > > > I not sure why the documents says that SASL and TLS security layers > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > but this > > > recommendation is, I believe, flawed. There are numerous use cases > > > where implementations SHOULD establish additional layers. > > For example, > > > establishing additional SASL layers may prevent certain kinds of > > > tunneling man-in-the-middle attacks. > > Could you describe some of them? > > > > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. How's that again? Please explain the network topology you're considering here. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 22:10:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995ARKP084945 for ; Wed, 8 Oct 2003 22:10:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995AQCr084944 for ietf-sasl-bks; Wed, 8 Oct 2003 22:10:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995APKP084936 for ; Wed, 8 Oct 2003 22:10:25 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h995AAHU013767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 01:10:16 -0400 (EDT) Message-ID: <3F84EDAE.1060801@columbia.edu> Date: Thu, 09 Oct 2003 01:10:06 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey CC: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060502010409050807070001" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060502010409050807070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > >Ok. I might be misunderstanding something, here is a summary: > >A client C that is willing to use SASL mechanism X both inside and >outside a TLS tunnel. >A server S that supports a server authenticated TLS tunnel and then >authenticates the client using SASL mechanism X within the tunnel. >An attacker M who can act as a TLS client and a SASL server for >mechanism X. > >The network topology/deployment must allow for M to trick C into trying >to authenticate to him using SASL Mechanism X (without TLS) while M >simultaneously establishes a TLS connection with S. > >M establishes a TLS session with S >M tricks C into trying to authenticate to him using SASL mechanism X >without TLS protection (these first steps could happen in the reverse >order) >M forwards the SASL exchange from C to S and vice versa. >The SASL authentication will succeed and S will believe that the >endpoint of the TLS tunnel is C instead of M (For some mechanisms M may >have to spoof S's address in order for the authentication to complete). >M can disconnect from C and continue sending messages to S. >S thinks the messages from M originate from C. > >Joe > > > As far as I am aware, the endpoints negotiating the TLS tunnel are identical to endpoints negotiating SASL. Both TLS and SASL are negotiated as part of the same connect/accept operation. Jeffrey Altman --------------ms060502010409050807070001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTA1MTAwNlowIwYJKoZIhvcNAQkEMRYEFO1axPFRmWNP 67RIy8XDMKetb+FYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEADXQ1FtqhFe5OdSd/cDovPQGISHaw BLzXgvYSVukAr/0cgPQJJxMdLnR0GGyH52tV30C7C1cTL7KKAZ4RXtrhejAIUQzshGbBkCa8 wCqMV7nFKEX92ETM1BLM40FF5DEjs9f3BBgCedi9yDHuKte9XVniF7NkOVZ9sUZ3uqmrzKGO vTk70+sDgyCcL+qMrA+iXdaQJqhVZc3LXS0BsqsQ+MNvOPn4NfGjjmaLXM/Gh8k8/32cq2HL Wu5kPgOE9w4bKD5/Zb+wdy4zd8oJgG+wM940Nx3OBvBd9D+nfwaBNMqqDE6N210vzAb9+MW0 4gW8gFmh+G1Zl61qVK4tJDoZTgAAAAAAAA== --------------ms060502010409050807070001-- From owner-ietf-sasl Wed Oct 8 21:53:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rdKP082836 for ; Wed, 8 Oct 2003 21:53:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994rc4k082835 for ietf-sasl-bks; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rcKP082829 for ; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:01:43 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h994rXJs005754; Wed, 8 Oct 2003 21:53:33 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 21:58:12 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 21:53:32 -0700 Message-ID: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 04:58:12.0976 (UTC) FILETIME=[F14A7700:01C38E21] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 9:21 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > > -----Original Message----- > > > From: owner-ietf-sasl@mail.imc.org > > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > > Sent: Wednesday, October 08, 2003 1:28 PM > > > To: xmppwg@jabber.org > > > Cc: iesg@ietf.org; SASL WG > > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > > > > > "Kurt D. Zeilenga" writes: > > > > I concur with Alexey's recent comments regarding XMPP's > > > SASL Profile. > > > > I have a few addition concerns regarding this profile. The > > > scope of my > > > > review was, due to time constraints, was limited to the profile. > > > > > > > > I not sure why the documents says that SASL and TLS security > > > > layers > > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > > but this > > > > recommendation is, I believe, flawed. There are numerous use > > > > cases > > > > where implementations SHOULD establish additional layers. > > > For example, > > > > establishing additional SASL layers may prevent certain kinds of > > > > tunneling man-in-the-middle attacks. > > > Could you describe some of them? > > > > > > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > How's that again? Please explain the network topology you're > considering here. > Ok. I might be misunderstanding something, here is a summary: A client C that is willing to use SASL mechanism X both inside and outside a TLS tunnel. A server S that supports a server authenticated TLS tunnel and then authenticates the client using SASL mechanism X within the tunnel. An attacker M who can act as a TLS client and a SASL server for mechanism X. The network topology/deployment must allow for M to trick C into trying to authenticate to him using SASL Mechanism X (without TLS) while M simultaneously establishes a TLS connection with S. M establishes a TLS session with S M tricks C into trying to authenticate to him using SASL mechanism X without TLS protection (these first steps could happen in the reverse order) M forwards the SASL exchange from C to S and vice versa. The SASL authentication will succeed and S will believe that the endpoint of the TLS tunnel is C instead of M (For some mechanisms M may have to spoof S's address in order for the authentication to complete). M can disconnect from C and continue sending messages to S. S thinks the messages from M originate from C. Joe From owner-ietf-sasl Wed Oct 8 22:09:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959NKP084730 for ; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9959Nlx084729 for ietf-sasl-bks; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959MKP084719 for ; Wed, 8 Oct 2003 22:09:22 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 22:16:31 -0700 In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ietf-sasl Wed Oct 8 22:19:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JtKP086958 for ; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995Jtea086956 for ietf-sasl-bks; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JsKP086904 for ; Wed, 8 Oct 2003 22:19:54 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:28:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h995JncZ023880; Wed, 8 Oct 2003 22:19:49 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 22:24:28 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 22:19:47 -0700 Message-ID: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 05:24:28.0752 (UTC) FILETIME=[9C86CD00:01C38E25] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 10:17 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > How's that again? Please explain the network topology you're > > > considering here. > > > > > > > Ok. I might be misunderstanding something, here is a summary: > > > > A client C that is willing to use SASL mechanism X both inside and > > outside a TLS tunnel. A server S that supports a server > authenticated > > TLS tunnel and then authenticates the client using SASL mechanism X > > within the tunnel. An attacker M who can act as a TLS client and a > > SASL server for mechanism X. > > > > The network topology/deployment must allow for M to trick C into > > trying to authenticate to him using SASL Mechanism X (without TLS) > > while M simultaneously establishes a TLS connection with S. > > > > M establishes a TLS session with S > > M tricks C into trying to authenticate to him using SASL mechanism X > > without TLS protection (these first steps could happen in > the reverse > > order) > > M forwards the SASL exchange from C to S and vice versa. > > The SASL authentication will succeed and S will believe that the > > endpoint of the TLS tunnel is C instead of M (For some > mechanisms M may > > have to spoof S's address in order for the authentication > to complete). > > M can disconnect from C and continue sending messages to S. > > S thinks the messages from M originate from C. > > Yes, this will work. But here's the thing: > > This only works if the client would have been prepared to do > this weak mechanism over a non-TLS connection. Generally the > client knows when it expects to do TLS and when it doesn't. > Agreed. If the client only uses this mechanism over TLS then this is not a problem. How easy this is to enforce depends upon the deployment environment, it may be reasonable to assume for XMPP (I'm not very familiar with XMPP). I'm not completely sure, but with some mechanisms using the same mechanism without TLS in a different protocol may lead to the same problem (If the mechanism does not authenticate the protocol/service context). Joe From owner-ietf-sasl Wed Oct 8 23:24:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OvKP009626 for ; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h996OvRV009624 for ietf-sasl-bks; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OsKP009606 for ; Wed, 8 Oct 2003 23:24:56 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h996OaMV011034; Wed, 8 Oct 2003 23:24:36 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id h996PrH25214; Wed, 8 Oct 2003 23:25:53 -0700 (PDT) Message-Id: <200310090625.h996PrH25214@katroo.Sendmail.COM> To: "Joseph Salowey" From: Philip Guenther Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard In-reply-to: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> References: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> Date: Wed, 08 Oct 2003 23:22:20 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: >> -----Original Message----- >> From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On ... >> This only works if the client would have been prepared to do >> this weak mechanism over a non-TLS connection. Generally the >> client knows when it expects to do TLS and when it doesn't. > >Agreed. If the client only uses this mechanism over TLS then this is >not a problem. How easy this is to enforce depends upon the deployment >environment, it may be reasonable to assume for XMPP (I'm not very >familiar with XMPP). I'm not completely sure, but with some mechanisms >using the same mechanism without TLS in a different protocol may lead to >the same problem (If the mechanism does not authenticate the >protocol/service context). For those who don't watch the ietf-announce list or didn't have their interest perked by the announcement, a discussion of this problem in the context of EAP can be found in: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt The Compound Authentication Binding Problem ... Abstract There are several motivations for using compound authentication methods using tunnels, but man-in-the-middle attacks are possible in certain circumstances when they are used, without cryptographically binding the methods together. At the time of writing this document, several protocols being proposed within the IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP. This document studies the problems and suggests potential solutions to mitigate them. (I have nothing to do with this document; it just seems extremely relevant and fairly thorough on the point under discussion. Perhaps SASL over TLS should be added to the list in the quoted abstract?) Philip Guenther guenther@sendmail.com From owner-ietf-sasl Thu Oct 9 02:51:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p8KP057701 for ; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h999p8l1057700 for ietf-sasl-bks; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p2KP057689 for ; Thu, 9 Oct 2003 02:51:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 10:50:55 +0100 Message-ID: <3F852F7D.7030206@isode.com> Date: Thu, 09 Oct 2003 10:50:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> Content-Type: multipart/alternative; boundary="------------030505020004070308000607" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030505020004070308000607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>2). Clarification on replacing a security layer >> >> > >I would like to hear folks comments on the appropriateness of >uninstalling layers after a failed subsequent exchange. > This is not the issue. What you are talking about violates SASL spec. The issues is whether to keep the old security layer or remove it a). in protocols that allow for reauthentication (e.g. LDAP and HTTP) b). after a second or subsequent successful reauthentication. Alexey --------------030505020004070308000607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
2). Clarification on replacing a security layer
    

I would like to hear folks comments on the appropriateness of
uninstalling layers after a failed subsequent exchange.
This is not the issue. What you are talking about violates SASL spec.

The issues is whether to keep the old security layer or remove it
a). in protocols that allow for reauthentication (e.g. LDAP and HTTP)
b). after a second or subsequent successful reauthentication.

Alexey

--------------030505020004070308000607-- From owner-ietf-sasl Thu Oct 9 03:36:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaLKP060119 for ; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99AaLRu060118 for ietf-sasl-bks; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaIKP060113 for ; Thu, 9 Oct 2003 03:36:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 11:35:31 +0100 Message-ID: <3F8539F1.3020106@isode.com> Date: Thu, 09 Oct 2003 11:35:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman CC: xmppwg@jabber.org, "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> In-Reply-To: <3F849A43.6020508@columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Altman wrote: >> The requirement that initiating receiving entity drop all knowledge >> it learned before negotiating SASL layers (rule 5) is too broad. >> This could be viewed as requiring the implement to forget knowledge >> it gained previously in a secure manner (such as an externally >> established lower level (IPSEC or TLS) identity information). >> Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are > actively providing encryption/integrity protection. In this > situation, it is known that TLS is not in use. I doubt it is known > whether or not IPSec is in use for the entire communication path. > Therefore, all information obtained prior to the establishment of > encryption/integrity protection must be considered suspect. > > I believe the problem is one of language. Can we replace all > references to "security layer" to read "data protection layer"? "security layer" is a SASL term, so changing it to something else will cause additional confusion. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Thu Oct 9 07:34:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYsKP069730 for ; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYsZQ069729 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKQ069717 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:36 +0100 Message-ID: <3F848CD6.9010804@isode.com> Date: Wed, 08 Oct 2003 23:16:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: SASL WG Subject: Replacing a SASL security layer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>> Below the term "realm" has the meaning as defined in the section 5. >>> A security layer that remains in effect when a client, which already >>> has authenticated and established the security layer with "Realm A", >>> authenticates to "Realm B", without negotiating a new security layer, >>> enables "Realm B" to make guesses about previously observed >>> ciphertext using the server's SASL engine as an oracle. "Realm B" may >>> observe how known cleartext is encrypted. >>> >>> +---------+ +---------+ >>> | | | | >>> | Realm B | | Realm A | >>> | | | | >>> +---------+ +---------+ >>> | ^ | >>> | : +-----------+ | >>> Traffic from | : | Encryption| | Traffic from A >>> B to client +-------->| end point |<-------+ to client >>> : | (SSL/SASL)| >>> : +-----------+ >>> : | >>> : | >>> : +---+ >>> : | | >>> : | | >>> : | | Encryption tunnel, e.g. SASL or >>> SSL, >>> : | | between the server >> >>> encrypted | | Separate tunnels to different >>> traffic between | | clients. >>> Realm A and client +---+ >>> | >>> | >>> +-----------> Traffic to clients >> > > This discussion is confusing and makes no sense to me. SASL doesn't > protect traffic between "realms" and clients; it protects traffic > between _servers_ and clients. This needs to be reworded so it makes > sense, in terms of entities known to the SASL framework. A "realm" is > not such an entity; it is no more than part of the autentication > identities used by some mechanisms, and has no place outside the > mechainsm specification. > > Put another way, and ignoring the issue of "realms"; the above > description makes so little sense to me that I cannot evaluate its > validity or understand what attack we are trying to avoid. Ignore for a moment any relationship of realm to DIGEST-MD5, GSSAPI or any other SASL mechanism. Let's use the definition I have in the document: Conceptually, realm is the name of a collection of user's accounts. Realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication mechanisms and/or authorization database. For example, a proxy/frontend can use different realms for different servers/backends it represents. So, each "realm" ("a protection space") is served by a separate server (proxy example above) or a separate process/plugin (frontend-backend example). Does it make more sense now? Alexey From owner-ietf-sasl Thu Oct 9 07:34:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYrKP069723 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYra7069722 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKP069717 for ; Thu, 9 Oct 2003 07:34:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:35 +0100 Message-ID: <3F848A1A.6020006@isode.com> Date: Wed, 08 Oct 2003 23:05:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , Jeffrey Hutzelman , Hallvard B Furuseth CC: SASL WG Subject: SASL Realms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. (...) The realm value is a case- >> insensitive string, generally assigned by the origin server, which >> >> > It seems to me it is not rfc2222bis' business to define realms as > case-insensitive. The mechanism definitions can do that. I think > rfc2222bis should only say that it usually is case-insensitive, or > maybe say that it "SHOULD" be. As it is, a mechanism can define a > "case- sensitive realm" if it wants to anyway, provided it confuses > the issue by calling it something else than a "realm". Kurt D. Zeilenga wrote: >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. >> >> > >I think this SHOULD is not appropriate. First, interoperability is >not harmed by protocol profiles not providing such guidance. Secondly, >realms should be viewed as part of multi-component authentication >identity form. That is, in DIGEST-MD5, the authentication identity >is composed of two parts, the user's name (username) and the user's >realm (realm). Having profiles overload the semantics of the >any component of the authentication identity breaks the separation >of mechanism and profile. > > Jeffrey Hutzelman wrote: >>> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >>> of realm. >> >> >> I think it unwise to enter into a discussion of realms here. >> Realm syntax and semantics are, for mechanisms which have realms, >> mechanism specific. The mechanism specification should state how >> they are to be compared. The mechanism specification should state >> how they are to constructed and used in the mechanism and, where >> appropriate, state any protocol profiling requirements. (Note: >> I'd likely doubt any mechanism attempt to state protocol profiling >> requirements as this breaks SASL's separation of profile and >> mechanism). > > I agree. A realm is just part of the authentication identities used > by certain mechanisms. It is mechanism-specific, and a discussion of > realms is irrelevant to protocol profiling. Ok, the reason why I've added this text in the first place is because a lot of protocol implementors misunderstand what the realm is and is not. Unfortunately the original text in the DIGEST-MD5 document is too vague to be useful. Recent discussion on LDAP mailing list proves this. I was trying to clarify this, but your are right that the text doesn't belong to the base SASL specification. I will be adding a section to DIGEST-MD5 that tries to give some examples of realm usage. >>> A protocol profile SHOULD provide a guidance how realms are to be >>> constructed and used in the protocol and MAY further restrict its >>> syntax and protocol-specific semantics. >> > Absolutely not. Protocols may decide to include some concept of realm > in their authorization identities, but they have no business > whatsoever defining the semantics of authentication identities. That > is the responsibility of the mechanism. Alexey From owner-ietf-sasl Thu Oct 9 08:09:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9CKP070984 for ; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99F9CC1070983 for ietf-sasl-bks; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9BKP070976 for ; Thu, 9 Oct 2003 08:09:11 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99F8SVo025764; Thu, 9 Oct 2003 08:08:28 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99F8R2o010016; Thu, 9 Oct 2003 09:08:27 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99F4WQx021341; Thu, 9 Oct 2003 08:04:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99F4UFL021340; Thu, 9 Oct 2003 08:04:30 -0700 (PDT) Date: Thu, 9 Oct 2003 08:04:30 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009150430.GD17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. > > To mitigate this problem you can: > > - Use the protection from the inner SASL method > - Have the SASL authentication mechanism authenticate the TLS Session ID > or some similar parameter > - Require different credentials be used by a SASL mechanism when > operating inside or outside a TLS tunnel. Why does this sound really familiar? Ah, because one solution is to "bind" one layer (SASL) to the key exchange and negotiation of the other (TLS) to prove that there's no MITM at the lower layer (TLS) - which, of course, relies on an MITM's inability to make the key exchange/nego look the same on both side of the lower layer channel. In the GSS-API we call this channel bindings. Perhaps SASL should have The second solution you give is an attempt at doing just this sort of binding. Unfortunately, a TLS MITM can make the TLS session ID be the same on both sides of the tunnel - that's because in TLS the server assigns the session ID which, in turn, is not bound or required to be bound in any way to the TLS key exchange / negotiation. So you can't use TLS session IDs as channel bindings. Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 08:37:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FboKP072070 for ; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FboXr072069 for ietf-sasl-bks; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FbnKP072063 for ; Thu, 9 Oct 2003 08:37:49 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 08:38:44 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h99FbcYb003490; Thu, 9 Oct 2003 08:37:39 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Oct 2003 08:42:18 -0700 From: "Joseph Salowey" To: "'Nicolas Williams'" Cc: "'EKR'" , , , "'SASL WG'" Subject: RE: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Date: Thu, 9 Oct 2003 08:37:37 -0700 Message-ID: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 15:42:18.0614 (UTC) FILETIME=[EBE2D960:01C38E7B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Thursday, October 09, 2003 8:05 AM > To: Joseph Salowey > Cc: 'EKR'; xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: SASL channel bindings (was Re: [xmppwg] Last Call: > 'XMPP Core' to Proposed Standard) > > > On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > > > To mitigate this problem you can: > > > > - Use the protection from the inner SASL method > > - Have the SASL authentication mechanism authenticate the > TLS Session > > ID or some similar parameter > > - Require different credentials be used by a SASL mechanism when > > operating inside or outside a TLS tunnel. > > Why does this sound really familiar? Ah, because one > solution is to "bind" one layer (SASL) to the key exchange > and negotiation of the other > (TLS) to prove that there's no MITM at the lower layer (TLS) > - which, of course, relies on an MITM's inability to make the > key exchange/nego look the same on both side of the lower > layer channel. [Joe] Yes, this is all too familiar > > In the GSS-API we call this channel bindings. Perhaps SASL > should have > > The second solution you give is an attempt at doing just this > sort of binding. > > Unfortunately, a TLS MITM can make the TLS session ID be the > same on both sides of the tunnel - that's because in TLS the > server assigns the session ID which, in turn, is not bound or > required to be bound in any way to the TLS key exchange / > negotiation. So you can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice (although in would probably work in the case outlined, it will fail if the attacker can trick the client into accepting it as a valid TLS endpoint, but this is a different problem). In any case SASL might benefit from channel bindings, although one has to be careful with channel bindings (for example binding to addresses tends to cause problems). Maybe it is possible to temporarily turn on SASL integrity services to authenticate binding information. I don't think that SASL intends for the security layer to be removed after it starts, but I didn't find a place in the draft where it explicitly forbids it. If it is allowed then applications which negotiate TLS can use this binding technique. > Cheers, > > Nico > -- > From owner-ietf-sasl Thu Oct 9 08:44:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiWKP072767 for ; Thu, 9 Oct 2003 08:44:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FiVDM072766 for ietf-sasl-bks; Thu, 9 Oct 2003 08:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiUKP072760 for ; Thu, 9 Oct 2003 08:44:30 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99FiCHU024300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 11:44:14 -0400 (EDT) Message-ID: <3F85824A.5050806@columbia.edu> Date: Thu, 09 Oct 2003 11:44:10 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000703080003050300080103" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000703080003050300080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > >>If the TLS tunnel is only server authenticated and the client supports a >>particular SASL method (perhaps even in a different protocol)that >>provides mutual authentication both inside and outside a TLS tunnel >>there is a vulnerability. In this case if only the message protection >>of TLS is used you cannot be sure that the client endpoint of the TLS >>tunnel is the same client endpoint that the server authenticated with >>SASL. >> >>To mitigate this problem you can: >> >>- Use the protection from the inner SASL method >>- Have the SASL authentication mechanism authenticate the TLS Session ID >>or some similar parameter >>- Require different credentials be used by a SASL mechanism when >>operating inside or outside a TLS tunnel. >> >> > >Why does this sound really familiar? Ah, because one solution is to >"bind" one layer (SASL) to the key exchange and negotiation of the other >(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of >course, relies on an MITM's inability to make the key exchange/nego look >the same on both side of the lower layer channel. > >In the GSS-API we call this channel bindings. Perhaps SASL should have > >The second solution you give is an attempt at doing just this sort of >binding. > >Unfortunately, a TLS MITM can make the TLS session ID be the same on >both sides of the tunnel - that's because in TLS the server assigns the >session ID which, in turn, is not bound or required to be bound in any >way to the TLS key exchange / negotiation. So you can't use TLS session >IDs as channel bindings. > >Cheers, > >Nico > > The channel binding would be made utilizing the TLS Client and Server Finished Messages. If both the client and server concatenate those messages in a well defined order, they can then attempt to verify that both the client and server have the same bytes. This is how TELNET AUTH binds to TLS when STARTTLS is used. The benefit of this is that we would get mutual authentication from SASL which would allow TLS to be used in anonymous-DH mode completely removing the need to have or validate X.509 certificates. Unfortunately, SASL does not have this functionality at the current time. I very much think it should. If it did, this entire discussion of the use of SASL Security Layers on top of TLS could just go away. I completely understand why the SASL folks want to be able to use a SASL Security Layer on top of TLS when they do not have the ability to bind to lower layers. Unfortunately, if SASL Security Layers are always to be used then I believe that TLS should never be negotiated. To do so adds nothing to the strength of the security of the session, increases the complexity, wastes CPU cycles, and spreads FUD regarding the trustworthiness of TLS. The lack of trust is not caused by TLS, but by the inability of SASL to verify a previously known shared secret between two parties. Jeffrey Altman Jeffrey Altman --------------ms000703080003050300080103 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTE1NDQxMFowIwYJKoZIhvcNAQkEMRYEFD2f/UNQ//7B jVMPyxGXkRLLUiiFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAv64q4pAT7kLCPtc/XIZuvm9jPAZ5 I792NJQ4KNAMn6BNdU1VGVm3ViBfqPRc7GqFo34dojUmhqxVj3epCWIVccmLQZeRsAWE/u46 eq/KF965kuSCsflGLFIWjGJWGK+e5hUtGSGTrzkeHVcWDxXkeobEtn393sdAwSq2tOj8N8Ef VHVOf6JWd76GWpGvOW4bk/NWAQg40BU2IWxrlc/e5uHht+ki+0UGJxqJyaVJpom6WpU2CQhq Mb74UgCxM4Z4nTI2rTfEgKwjMAsiMbXd3WCRspazsBmc0xpziVqAdL9fwDk4BZSePWwhYBal 0lD91cM4x9tHcsVXPtMpXPBopQAAAAAAAA== --------------ms000703080003050300080103-- From owner-ietf-sasl Thu Oct 9 09:19:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074402 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GJZlr074401 for ietf-sasl-bks; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074396 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99GIqVo006146; Thu, 9 Oct 2003 09:18:52 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GIp58014068; Thu, 9 Oct 2003 10:18:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GEuQx021373; Thu, 9 Oct 2003 09:14:56 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GEtZZ021372; Thu, 9 Oct 2003 09:14:55 -0700 (PDT) Date: Thu, 9 Oct 2003 09:14:55 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009161455.GF17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <20031009150430.GD17088@binky.central.sun.com> <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote: Nico> Why does this sound really familiar? Ah, because one solution is Nico> to "bind" one layer (SASL) to the key exchange and negotiation of Nico> the other (TLS) to prove that there's no MITM at the lower layer Nico> (TLS) - which, of course, relies on an MITM's inability to make Nico> the key exchange/nego look the same on both side of the lower Nico> layer channel. > [Joe] Yes, this is all too familiar > > > Nico> In the GSS-API we call this channel bindings. Perhaps SASL should Nico> have [I meant to say "Perhaps SASL should have a channel bindings facility."] Nico> Unfortunately, a TLS MITM can make the TLS session ID be the same Nico> on both sides of the tunnel - that's because in TLS the server Nico> assigns the session ID which, in turn, is not bound or required to Nico> be bound in any way to the TLS key exchange / negotiation. So you Nico> can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice > (although in would probably work in the case outlined, it will fail if > the attacker can trick the client into accepting it as a valid TLS > endpoint, but this is a different problem). > > In any case SASL might benefit from channel bindings, although one has > to be careful with channel bindings (for example binding to addresses > tends to cause problems). Maybe it is possible to temporarily turn on > SASL integrity services to authenticate binding information. I don't > think that SASL intends for the security layer to be removed after it > starts, but I didn't find a place in the draft where it explicitly > forbids it. If it is allowed then applications which negotiate TLS can > use this binding technique. It's probably not possible to add a channel bindings facility to SASL at this point, but it should be possible to describe how applications should do channel binding with SASL, more or less as you describe. And as you point out, the traditional use of GSS-API channel bindings to bind to network addresses causes problems, and, I might add, isn't really secure. Therefore we need to generally address channel bindings for the channels one might like to bind to: - What to use as channel bindings for SSHv2? Easy, the SSHv2 session ID! - What to use as channel bindings for TLS? TLS defines no suitable value. So one may have to be constructed (e.g., hash of all TLS session setup messages). - What to use as channel bindings for IKEv1 IPsec? Don't. IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding to the previous or original IKE_SA - so that when the IKE_SA expires so do the bindings. - What to use as channel bindings for IKEv2 IPsec? IKEv2 rekeying does bind the new SA to the previous one, so binding to IPsec SAs negotiated with IKEv2 is ok, but we need to define the what to use as the channel bindings. I've asked the IPSEC WG to define a value for use as channel bindings, but so far they are ignoring me. Ultimately, the same octets of which signatures are exchanged in the AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft) can be used as channel bindings, or, rather, a hash thereof. - What to use as channel bindings for Kerberos V-protected tunnels? Again, nothing useful for this is provided in RFC1510. But who wants this? :) Still something could be defined (e.g., a hash of the AP exchange messages). - What to use as channel bindings for GSS-API-protected tunnels? Same thing. I'd propose: the ret_flags of the context and a hash of the byte-wise concatenation of the context tokens used to initialize the context, in order. - What to use as channel bindings for SASL-protected tunnels? Again, same thing... Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 09:29:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GTpKP074978 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GTpid074977 for ietf-sasl-bks; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GToKP074969 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h99GT4X0024940; Thu, 9 Oct 2003 09:29:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GT42o017514; Thu, 9 Oct 2003 10:29:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GP8Qx021381; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GP8iN021380; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Date: Thu, 9 Oct 2003 09:25:07 -0700 From: Nicolas Williams To: Jeffrey Altman Cc: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009162507.GG17088@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> <3F85824A.5050806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F85824A.5050806@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 11:44:10AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > >The second solution you give is an attempt at doing just this sort of > >binding. > > > >Unfortunately, a TLS MITM can make the TLS session ID be the same on > >both sides of the tunnel - that's because in TLS the server assigns the > >session ID which, in turn, is not bound or required to be bound in any > >way to the TLS key exchange / negotiation. So you can't use TLS session > >IDs as channel bindings. > > The channel binding would be made utilizing the TLS Client and Server > Finished Messages. If both the client and server concatenate those > messages in a well defined order, they can then attempt to verify that > both the client and server have the same bytes. This is how TELNET AUTH > binds to TLS when STARTTLS is used. The benefit of this is that we > would get mutual authentication from SASL which would allow TLS to be > used in anonymous-DH mode completely removing the need to have or > validate X.509 certificates. Yeah - I offer as much in the post I just followed up with. This sort of thing is extremely valuable. The NFSv4 WG is quite interested in channel bindings as a way to offload session cryptographic protection from RPCSEC_GSS/GSS-API to IPsec and others. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt (The I-D will be updated soon, I hope, and will include much improved text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well nonces and an additional 1/2 round-trip for the CCM-* pseudo- mechanisms' context tokens so as to make their context tokens un-replayable independently of the underlying, real mechanisms' context tokens' replayability.) > Unfortunately, SASL does not have this functionality at the current > time. I very much think it should. If it did, this entire discussion > of the use of SASL Security Layers on top of TLS could just go away. The discussion of what to use as channel bindings to TLS would still have to be had, though you point out that TELNET already solves that particular problem in a way that others could leverage. But that still leaves other channels to discuss (e.g., IPsec) - see my other followup to Joe. > I completely understand why the SASL folks want to be able to use a SASL > Security Layer on top of TLS when they do not have the ability to bind > to lower layers. Unfortunately, if SASL Security Layers are always to > be used then I believe that TLS should never be negotiated. To do so > adds nothing to the strength of the security of the session, increases > the complexity, wastes CPU cycles, and spreads FUD regarding the > trustworthiness of TLS. The lack of trust is not caused by TLS, but by > the inability of SASL to verify a previously known shared secret between > two parties. I agree. But note that SASL doesn't have to "verify a previously ..." - it just has to verify a value, public or not, that could not be made the same for both parties by an MITM at the lower layer. Cheers, Nico -- From owner-ietf-sasl Thu Oct 9 15:18:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIIZA094244 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99MIIG3094243 for ietf-sasl-bks; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from server.kniep.nl (node-c-9223.a2000.nl [62.194.146.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIFZA094229 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from dick@kniep.nl) Received: from server.kniep.nl (localhost [127.0.0.1]) by server.kniep.nl (Postfix) with ESMTP id 4055D3342F9 for ; Thu, 9 Oct 2003 18:22:10 -0400 (EDT) Subject: Sasl problems From: Dick Kniep To: SASL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Oct 2003 00:22:09 +0200 Message-Id: <1065738130.31142.2.camel@server.kniep.nl> Mime-Version: 1.0 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi List, This is my first post on the sasl list, I am no guru on SASl, so please be gentle. We have installed a Kolab server (groupware with Sasl, postfix, cyrus imap etc.) Install went smoothly, but we cannot log on. I have posted to the kolab mailinglist, but got no answer whatsoever. So, next is my original post to the kolab mailinglist. If anyone can help, please do so. Since the original occurrance of the error, I have tried to remove the user 'dick' completely from the system, defining it again etc. All to no avail. ++++ Original message to Kolab mailinglist ++++ We have a strange phenomenon where we cannot get access to the server. We have entered a userid in the management module. This works OK (or so it seems) Next we try to login, but then we get a message that the userid is not authorized. The password is correct. When we look in the logs of SASL the following messages are shown: -------------------------- Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth failure: [user=dick] [service=imap] [realm=] [mech=ldap] -------------------------- It says that there are more definitions of the user 'dick'. If that is the case how can we verify that? If not what could be the problem than???? Please help Kind regards, D. Kniep From owner-ietf-sasl Thu Oct 9 15:38:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc2ZA094765 for ; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Mc2Am094764 for ietf-sasl-bks; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc1ZA094759 for ; Thu, 9 Oct 2003 15:38:01 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 79992151D9B; Thu, 9 Oct 2003 18:38:03 -0400 (EDT) To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> From: Sam Hartman Date: Thu, 09 Oct 2003 18:38:03 -0400 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> (Nicolas Williams's message of "Thu, 9 Oct 2003 08:04:30 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey Nicolas> wrote: >> If the TLS tunnel is only server authenticated and the client >> supports a particular SASL method (perhaps even in a different >> protocol)that provides mutual authentication both inside and >> outside a TLS tunnel there is a vulnerability. In this case if >> only the message protection of TLS is used you cannot be sure >> that the client endpoint of the TLS tunnel is the same client >> endpoint that the server authenticated with SASL. >> >> To mitigate this problem you can: >> >> - Use the protection from the inner SASL method - Have the SASL >> authentication mechanism authenticate the TLS Session ID or >> some similar parameter - Require different credentials be used >> by a SASL mechanism when operating inside or outside a TLS >> tunnel. Nicolas> Why does this sound really familiar? Ah, because one Nicolas> solution is to "bind" one layer (SASL) to the key Nicolas> exchange and negotiation of the other (TLS) to prove that Nicolas> there's no MITM at the lower layer (TLS) - which, of Nicolas> course, relies on an MITM's inability to make the key Nicolas> exchange/nego look the same on both side of the lower Nicolas> layer channel. Nicolas> In the GSS-API we call this channel bindings. Perhaps Nicolas> SASL should have I wish SASL had this feature a lot. It's clearly out of scope for both the XMPP working group and for the SASL working group. From owner-ietf-sasl Thu Oct 9 16:42:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng4ZA098040 for ; Thu, 9 Oct 2003 16:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Ng3EW098039 for ietf-sasl-bks; Thu, 9 Oct 2003 16:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng2ZA098034 for ; Thu, 9 Oct 2003 16:42:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h99Ng4lg044945; Thu, 9 Oct 2003 23:42:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009163323.0388c3b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 16:41:32 -0700 To: Dick Kniep From: "Kurt D. Zeilenga" Subject: Re: Sasl problems Cc: SASL WG In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> References: <1065738130.31142.2.camel@server.kniep.nl> 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: Dick, As list is reserved for discussions regarding standardization of SASL, your post is off-topic. You should instead direct your post to a forum which supports the particular software you are using. I note that Cyrus SASL mailing list information can be found at . Thanks, Kurt (SASL WG co-chair) At 03:22 PM 10/9/2003, Dick Kniep wrote: >Hi List, > >This is my first post on the sasl list, I am no guru on SASl, so please >be gentle. > >We have installed a Kolab server (groupware with Sasl, postfix, cyrus >imap etc.) Install went smoothly, but we cannot log on. I have posted to >the kolab mailinglist, but got no answer whatsoever. So, next is my >original post to the kolab mailinglist. If anyone can help, please do >so. > >Since the original occurrance of the error, I have tried to remove the >user 'dick' completely from the system, defining it again etc. All to no >avail. > >++++ Original message to Kolab mailinglist ++++ > >We have a strange phenomenon where we cannot get access to the server. > >We have entered a userid in the management module. This works OK (or so >it seems) Next we try to login, but then we get a message that the >userid is not authorized. The password is correct. When we look in the >logs of SASL the following messages are shown: > >-------------------------- > >Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or >more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). >Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth >failure: [user=dick] [service=imap] [realm=] [mech=ldap] > >-------------------------- > >It says that there are more definitions of the user 'dick'. >If that is the case how can we verify that? >If not what could be the problem than???? > >Please help > >Kind regards, >D. Kniep From owner-ietf-sasl Thu Oct 9 16:56:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu4ZA098325 for ; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Nu4uF098324 for ietf-sasl-bks; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu3ZA098315 for ; Thu, 9 Oct 2003 16:56:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h99Ntvo5020961; Thu, 9 Oct 2003 19:56:00 -0400 (EDT) Message-ID: <3F85F58C.3000905@oceana.com> Date: Thu, 09 Oct 2003 19:55:56 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dick Kniep CC: SASL WG Subject: Re: Sasl problems References: <1065738130.31142.2.camel@server.kniep.nl> In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrong list. This list is for discussion of the design of SASL and its mechanisms, not the implementations. Try: cyrus-sasl@lists.andrew.cmu.edu and/or info-cyrus@lists.andrew.cmu.edu Dick Kniep wrote: > Hi List, > > This is my first post on the sasl list, I am no guru on SASl, so please > be gentle. > > We have installed a Kolab server (groupware with Sasl, postfix, cyrus > imap etc.) Install went smoothly, but we cannot log on. I have posted to > the kolab mailinglist, but got no answer whatsoever. So, next is my > original post to the kolab mailinglist. If anyone can help, please do > so. > > Since the original occurrance of the error, I have tried to remove the > user 'dick' completely from the system, defining it again etc. All to no > avail. > > ++++ Original message to Kolab mailinglist ++++ > > We have a strange phenomenon where we cannot get access to the server. > > We have entered a userid in the management module. This works OK (or so > it seems) Next we try to login, but then we get a message that the > userid is not authorized. The password is correct. When we look in the > logs of SASL the following messages are shown: > > -------------------------- > > Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or > more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). > Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth > failure: [user=dick] [service=imap] [realm=] [mech=ldap] > > -------------------------- > > It says that there are more definitions of the user 'dick'. > If that is the case how can we verify that? > If not what could be the problem than???? > > Please help > > Kind regards, > D. Kniep > > > > > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 9 19:53:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r8ZA003688 for ; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A2r828003687 for ietf-sasl-bks; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r3ZA003682 for ; Thu, 9 Oct 2003 19:53:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9A2r1lg046810; Fri, 10 Oct 2003 02:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 19:52:29 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Replacing a SASL security layer Cc: Jeffrey Hutzelman , SASL WG In-Reply-To: <3F848CD6.9010804@isode.com> References: <3F848CD6.9010804@isode.com> 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: A concern here is that a number of application profiles specify (and developers have implemented) SASL layers such that established layers cannot be deinstalled except to install new layers. Changing this now will naturally introduce some interoperability, so we need to be sure that the change is well justified. I wonder if it might be better to not to change the protocol but, instead, just document the security consideration. Kurt From owner-ietf-sasl Fri Oct 10 02:45:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jrZA081146 for ; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9jrOC081145 for ietf-sasl-bks; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jlZA081138 for ; Fri, 10 Oct 2003 02:45:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 10 Oct 2003 10:45:40 +0100 Message-ID: <3F867FC1.90704@isode.com> Date: Fri, 10 Oct 2003 10:45:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >A concern here is that a number of application profiles >specify (and developers have implemented) SASL layers such >that established layers cannot be deinstalled except to install >new layers. > I am only aware of one protocol that might do that: LDAP. > Changing this now will naturally introduce some >interoperability, so we need to be sure that the change is well >justified. > I don't believe anybody implements this right anyway (please, do let me know if I am right). > I wonder if it might be better to not to change the >protocol but, instead, just document the security consideration. > I would like to allow new protocols to allow to deinstall the security layer when none is negotiated. RFC 2222 prohibits this. IMHO, it is fine if an existing protocol doesn't do that (and documents the issue in Security considerations), but there is no point of forcing brokeness on new protocols. Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Fri Oct 10 02:46:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kEZA081162 for ; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9kECt081160 for ietf-sasl-bks; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-12.noos.net [212.198.2.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kCZA081154 for ; Fri, 10 Oct 2003 02:46:13 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 9850079 invoked by uid 0); 10 Oct 2003 09:45:46 -0000 Received: (qmail 8715980 invoked by uid 0); 9 Oct 2003 07:19:39 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with SMTP for ; 9 Oct 2003 07:19:39 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 6E11663FD9; Thu, 9 Oct 2003 00:10:03 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by hades.jabber.org (Postfix) with ESMTP id 1E90F63D7C for ; Thu, 9 Oct 2003 00:09:27 -0500 (CDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> From: Eric Rescorla In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org X-Reply-To: EKR List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Oct 2003 22:16:31 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg From owner-ietf-sasl Fri Oct 10 08:41:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfMZA098198 for ; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AFfMuC098197 for ietf-sasl-bks; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-02.noos.net [212.198.2.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfKZA098189 for ; Fri, 10 Oct 2003 08:41:21 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 3714922 invoked by uid 0); 10 Oct 2003 15:40:43 -0000 Received: (qmail 3205723 invoked by uid 0); 8 Oct 2003 19:32:14 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for ; 8 Oct 2003 19:32:14 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 51F8863FB6; Wed, 8 Oct 2003 14:32:09 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hades.jabber.org (Postfix) with ESMTP id 2461763FB0; Wed, 8 Oct 2003 14:31:36 -0500 (CDT) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre Cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 20:31:34 +0100 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg From owner-ietf-sasl Mon Oct 13 08:45:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjII7037188 for ; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFjIM5037187 for ietf-sasl-bks; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjGI7037180 for ; Mon, 13 Oct 2003 08:45:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9DFjH5t022347 for ; Mon, 13 Oct 2003 11:45:17 -0400 Date: Mon, 13 Oct 2003 11:45:17 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: rfc2254bis/rfc2554bis 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: I'd like to point members of this working group at the following two documents which are intended as revisions to the SMTP/POP3 SASL profiles: draft-siemborski-rfc1734bis-00.txt draft-siemborski-rfc2554bis-00.txt The aims here are to clarify the specifications to result in fewer interoperability problems. The two big concerns that I am aware of being how implementations deal with client-send-first and (in the case of SMTP) servers rejecting the AUTH= parameter to MAIL FROM when the session is not authenticated. I will be updating these drafts to point at rfc2222bis in their first revision. I'd also like to hear any other comments. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Oct 13 10:19:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJLI7039891 for ; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DHJLZk039890 for ietf-sasl-bks; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJKI7039885 for ; Mon, 13 Oct 2003 10:19:20 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJL7R019978 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJLX0023277 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHJK0I013308 for ; Mon, 13 Oct 2003 13:19:20 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHJJs4000506; Mon, 13 Oct 2003 13:19:19 -0400 Date: Mon, 13 Oct 2003 13:19:19 -0400 Message-Id: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Greg Hudson To: ietf-sasl@imc.org Subject: Some implementor's notes Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm writing these notes in hopes that they will provide insight on possible barriers to SASL's adoption. When I created the custom Subversion protocol, I decided to use SASL for authentication because I liked the concept and because I dislike the properties of X.509 certificates, which (via TLS) are the only real alternative that I know of. I started out by implementing ANONYMOUS and EXTERNAL myself, since those are trivial. I figured for the real meat, I would use a library, since in an ideal world applications have no business implementing authentication systems. Unfortunately, I'm finding the Cyrus library unsuitable (I'll detail the reasons for this at the end, since it's implementation-specific) and I can't use the gsasl library in Subversion since it is covered by the GPL. So, since there have been a lot of calls for password authentication, I thought maybe I would implement one of the shared-secret systems without stream protection; Subversion's utility libraries already include an MD5 implementation, so I figured I wouldn't need to introduce any complicated pieces of code. First, I looked into CRAM-MD5. It doesn't authenticate the server and it doesn't leave the window open for stream protection, but those issues aren't critical. I found the following sources of hidden complexity: * The processing of the secret (pad to 64 bytes or digest and then pad to 64 bytes) is clunky and has no value in an MD5 context as far as I know. * I find it important to avoid storing passwords in clear text, since people often use the same password for multiple systems. To accomplish this, you need an MD5 implementation which supports saving intermediate states. * The current draft mandates the use of RFC 3454, a 91-page RFC I don't understand and which does not look trivial to implement. I'm sure there are real issues with internationalized usernames and passwords, but the blow-up in complexity seems astounding. Faced with these problems and a general sense of guilt at the idea of implementing a weak system, I turned to DIGEST-MD5. I found that while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the digests, it comes with a burdensome level of complexity which is unrelated to its conceptual security properties. In particular: * It introduces the concepts of realms, subsequent authentication, and authorization IDs, none of which seem to be important functionality for a generic shared-secret authentication scheme, and all of which could (I think) be handled out of band. Fortunately, it's not too difficult to avoid supporting those features. * Messages are composed of key-value pairs which do not obey a consistent syntax for the value, so parsing them is hard. (I'm not convinced that Cyrus's implementation is correct, particularly for skipping over auth-param values.) * Length-counted strings would be easier to parse than quoted strings while remaining human-readable. * Implicit allowance for linear whitespace has no intrinsic value and renders implementations more complicated and error-prone. * It is not specified whether the serv-type, host, and digest-uri values are required. (Cyrus treats digest-uri as required but not the other two, probably because it's not specified what you should do with an unspecified digest-uri when computing the digests.) It is not made clear what security value, if any, these parameters have; to "detect accidental connection to the incorrect server" is not an important function for an authentication scheme. * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems like a very burdensome requirement to place on the protocol for the sake of a very implementation-specific convenience. One can avoid this complexity by not supporting UTF-8, but that in itself is unfortunate. Most of this complexity is there to provide wire similarity between DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling justification for requiring a tenfold expansion in code size over what would be required to compute the digests and do basic parsing. Because of this complexity, I am likely to go back to CRAM-MD5, ignoring the RFC 3454 requirement in the current draft. I'm not sure what SASL can do at this point to reduce the implementation burdens, but I have to say that I am sorely disappointed. When one is designing a security system, one should compromise simplicity only in the name of security. As promised, here are my major issues with the Cyrus SASL implementation: * As I've discussed before, if you're a library invoking the SASL library, there's no way to ensure thread-safety while remaining compatible with other libraries invoking SASL. * The getopt interface seems to be a barrier to successfully documenting or internationalizing an application's configuration system. * The API does not successfully hide the complexity of the underlying mechanisms, such as digest-md5's realms. (By "hide" here I don't mean the API shouldn't support them, but that you should have to go to extra effort to use them, instead of having to go to extra effort to ignore them.) * The secrets database is kept in a database format which depends on the build of the library. If you go from one build to another (say, by upgrading versions of Red Hat) and the new build uses a different database, your server stops working and you get a cryptic error. That seems totally unacceptable, and I wonder how existing users of the library are dealing with it. * The secrets database keeps secrets in plain text, which I find unacceptable due to the amount of password-sharing users do. From owner-ietf-sasl Mon Oct 13 11:11:14 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBEI7042435 for ; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DIBElS042434 for ietf-sasl-bks; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBDI7042429 for ; Mon, 13 Oct 2003 11:11:13 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DIBAo8025711 for ; Mon, 13 Oct 2003 14:11:14 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DI61Fp029761 for ; Mon, 13 Oct 2003 14:06:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHxtjW004447 for ; Mon, 13 Oct 2003 13:59:56 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHxrL6000520; Mon, 13 Oct 2003 13:59:53 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: ietf-sasl@imc.org In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066067993.30290.58.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 13:59:53 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 13:19, Greg Hudson wrote: > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) Whoops, this was based on a misreading of the syntax for auth-param (I read it as being "auth-param=token=value" instead of just "token=value"). So, ignore that point. From owner-ietf-sasl Mon Oct 13 13:41:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf7I7047402 for ; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DKf7xo047401 for ietf-sasl-bks; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf6I7047395 for ; Mon, 13 Oct 2003 13:41:06 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9DKf0P5036838; Mon, 13 Oct 2003 14:41:01 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Mon, 13 Oct 2003 14:41:00 -0600 From: Lyndon Nerenberg To: Greg Hudson , ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <2147483647.1066056060@[192.168.42.6]> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > * I find it important to avoid storing passwords in clear text, > since people often use the same password for multiple systems. To > accomplish this, you need an MD5 implementation which supports > saving intermediate states. That's an implementation issue, and not a CRAM-MD5 problem. [More on this below.] > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. 3454 is a bit verbose, but from an implementation standpoint it's really not that complicated. There's no getting away from stringprep. The alternative solution of restricting everything to US-ASCII is a non-starter. With the IETF heavily leaning towards stringprep for all new protocol work, you shouldn't have any trouble finding libraries that will assist with the UTF coding issues. > Because of this complexity, I am likely to go back to CRAM-MD5, > ignoring the RFC 3454 requirement in the current draft. Please don't. We have enough trouble as it is with implementations sending non-ASCII strings in CRAM-MD5. Without the ability to specify the character set in use, interoperability suffers greatly. stringprep solves this problem. > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. If you don't trust the OS to protect this data then your only option is to use a SASL mechanism that doesn't require plain text equivalent secrets. This is SASL mechanism specific, and not an artifact of the Cyrus implementation. --lyndon From owner-ietf-sasl Mon Oct 13 14:16:17 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGHI7049390 for ; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DLGH0W049389 for ietf-sasl-bks; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGGI7049368 for ; Mon, 13 Oct 2003 14:16:16 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLGHSX018273; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLG3hk009695; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DLC0jW003985; Mon, 13 Oct 2003 17:12:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DLBvN6000604; Mon, 13 Oct 2003 17:11:57 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: Lyndon Nerenberg Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1066056060@[192.168.42.6]> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <2147483647.1066056060@[192.168.42.6]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066079516.30290.91.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 17:11:57 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 16:41, Lyndon Nerenberg wrote: > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > If you don't trust the OS to protect this data then your only option is > to use a SASL mechanism that doesn't require plain text equivalent > secrets. This is SASL mechanism specific, and not an artifact of the > Cyrus implementation. The issue is not how much the OS can be trusted; it's how much the owner of the server can be trusted. Ideally, the user should be able to provide the secret to the server owner in such a way that the server owner cannot reuse it with other services. On further consideration, even if CRAM-MD5 secrets are kept in intermediate form, that form can be reused with other CRAM-MD5 services, so that's maybe not so useful. However, a DIGEST-MD5 password in intermediate form can only be used with another DIGEST-MD5 service if the username and realm matches. I'm not really sure what the common practice is for realm names, but if they're commonly related to the server hostname then the secret shouldn't be reusable in practice. From owner-ietf-sasl Tue Oct 14 03:36:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAauI7038856 for ; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EAau2m038855 for ietf-sasl-bks; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAasI7038849 for ; Tue, 14 Oct 2003 03:36:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 11:36:49 +0100 Message-ID: <3F8BD1BF.4080001@isode.com> Date: Tue, 14 Oct 2003 11:36:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: >... > >First, I looked into CRAM-MD5. It doesn't authenticate the server and >it doesn't leave the window open for stream protection, but those >issues aren't critical. I found the following sources of hidden >complexity: > >... > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as well (at least it will when I publish a new revision) > >Faced with these problems and a general sense of guilt at the idea of >implementing a weak system, I turned to DIGEST-MD5. I found that >while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes >the digests, it comes with a burdensome level of complexity which is >unrelated to its conceptual security properties. In particular: > > * It introduces the concepts of realms, subsequent authentication, > and authorization IDs, none of which seem to be important > functionality for a generic shared-secret authentication scheme, > and all of which could (I think) be handled out of band. > Fortunately, it's not too difficult to avoid supporting those > features. > > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) > I suggest you try to find a case that breaks stuff. It is more constructive than saying that something doesn't (or may not) work. > * Length-counted strings would be easier to parse than quoted > strings while remaining human-readable. > > * Implicit allowance for linear whitespace has no intrinsic value > and renders implementations more complicated and error-prone. > Yes. There are historical reasons why this happened. It was a compromise between design and something that could have been implemented by one big vendor. It was supposed to become a replacement for another seriously broken SASL mechanism NTLM. > * It is not specified whether the serv-type, host, and digest-uri > values are required. > They are required to be sent, but the receiver SHOULD (but not required to) verify it. If the text is not clear, let me know and I will try to fix it. > (Cyrus treats digest-uri as required but not > the other two, probably because it's not specified what you should > do with an unspecified digest-uri when computing the digests.) It > is not made clear what security value, if any, these parameters > have; to "detect accidental connection to the incorrect server" is > not an important function for an authentication scheme. > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > like a very burdensome requirement to place on the protocol for > the sake of a very implementation-specific convenience. One can > avoid this complexity by not supporting UTF-8, but that in itself > is unfortunate. > >Most of this complexity is there to provide wire similarity between >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling >justification for requiring a tenfold expansion in code size over what >would be required to compute the digests and do basic parsing. > > See above. >Because of this complexity, I am likely to go back to CRAM-MD5, >ignoring the RFC 3454 requirement in the current draft. I'm not sure >what SASL can do at this point to reduce the implementation burdens, >but I have to say that I am sorely disappointed. When one is >designing a security system, one should compromise simplicity only in >the name of security. > SASL has nothing to do with your problem (well, very little to do). SASL is just a framework. If you don't like mechanisms that are currently available, you can write a new one and try to make it deployed. >As promised, here are my major issues with the Cyrus SASL >implementation: > > * As I've discussed before, if you're a library invoking the SASL > library, there's no way to ensure thread-safety while remaining > compatible with other libraries invoking SASL. > > * The getopt interface seems to be a barrier to successfully > documenting or internationalizing an application's configuration > system. > Why? > * The API does not successfully hide the complexity of the > underlying mechanisms, such as digest-md5's realms. (By "hide" > here I don't mean the API shouldn't support them, but that you > should have to go to extra effort to use them, instead of having > to go to extra effort to ignore them.) > Yes, this is a bit unfortunate, but I had exactly the same problem trying to write a different SASL implementation. > > * The secrets database is kept in a database format which depends on > the build of the library. > Shouldn't really. Secrets are usually stored in sasldb backend, the format is quite stable at this point and shouldn't change very much over the time. > If you go from one build to another > (say, by upgrading versions of Red Hat) and the new build uses a > different database, your server stops working and you get a > cryptic error. That seems totally unacceptable, and I wonder how > existing users of the library are dealing with it. > > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. > > Alexey From owner-ietf-sasl Tue Oct 14 07:54:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs7I7050838 for ; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EEs7O5050837 for ietf-sasl-bks; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs1I7050822 for ; Tue, 14 Oct 2003 07:54:01 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9QYh-0007AW-8m; Tue, 14 Oct 2003 16:53:59 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9QXB-0006bE-Dt; Tue, 14 Oct 2003 16:52:25 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9QX7-0003E1-00; Tue, 14 Oct 2003 16:52:21 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 16:52:21 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>4.1. Authentication protocol exchange >>> >>> A SASL mechanism is responsible for conducting an authentication >>> protocol exchange. This consists of a series of server challenges >>> and client responses, >>> >> >>Does this mean that the initial auth command from the client is not >>considered part of the authentication protocol exchange? >> > Does it matter in this section? Well, that's where "authentication protocol exchange" seems to be defined. It matters if other documents refer to "the authentication protocol exchange". Anyway, I think I found the answer in section 6.1. The initial auth command from the client is not part of the exchange, but the optional "response" in the auth command is. >>>4.2. Authorization identities and proxy authentication >>> >>> (...) >>> The character encoding scheme used for transmitting an authorization >>> identity over protocol is specified in each authentication mechanism >>> (with the authentication mechanism's blob being further >> ^^^^ >> >>What's a blob? I don't think it's 'something ill-defined or amorphous', >>like the dictionary says:-) >> > I've changed this to "data". I still don't know _which_ data you are talking about. >>> A protocol profile MAY further refine the definition of an >>> authorization identity by adding additional syntactic restrictions >>> and protocol-specific semantics. >> >>Add a paragraph break here, since the following is a new item. Remove >>"A protocol profile MUST specify" to just make the following a new item >>in the list of things that must be specified. >> >>> A protocol profile MUST specify the >>> form of the authorization identity (as it is protocol specific, as >>> > I would rather not do this, as this is a single logic item. OK. >>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>top. >> > I've added a sentence about this in the introduction section. I'm pretty sure you will still need to insert the words "Obsoletes: rfc 2222" in the header sometime, though I don't remember where this is stated. -- Hallvard From owner-ietf-sasl Tue Oct 14 08:01:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1jI7051200 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EF1jJu051199 for ietf-sasl-bks; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1iI7051193 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Qg8-0000BM-Pt; Tue, 14 Oct 2003 17:01:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9Qfz-0006hy-SS; Tue, 14 Oct 2003 17:01:31 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Qfy-0003FW-00; Tue, 14 Oct 2003 17:01:30 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt In-Reply-To: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:01:30 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >> draft-ietf-sasl-plain-02.txt says that >> >> The client leaves >> the authorization identity empty if it wishes the server to derive the >> authorization identity from the provided authentication identity. >> >> and >> >> Note that the parameters provided to the Authorize function are not >> prepared. >> >> so I think the pseudo-code for empty authzid should say >> authzid = DeriveAuthzid(authcid); >> and not >> authzid = DeriveAuthzid(pAuthcid); > > I think the current psuedo-code is correct, the first > quoted text is misleading. I don't feel strongly about this, but the original wording seems right to me. authzid is not prepared, so neither does it use the prepared version of authcid. And that way, PLAIN(authzid = "", authcid = X, password) does the same as PLAIN(authzid = X, authcid = X, password). Your way, it does not. That seems wrong to me. -- Hallvard From owner-ietf-sasl Tue Oct 14 08:33:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXII7052605 for ; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFXIfG052604 for ietf-sasl-bks; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXHI7052597 for ; Tue, 14 Oct 2003 08:33:17 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9RAf-0003aB-3F; Tue, 14 Oct 2003 17:33:13 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9RAb-0005Iv-1b; Tue, 14 Oct 2003 17:33:09 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9RAX-0003Jn-00; Tue, 14 Oct 2003 17:33:05 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:33:05 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> 3). Realm > > I have not yet heard any arguments to keep the realm text. I found it useful, since I had no clear idea what a realm was. The text is just too demanding. How about making the text purely informational, without any SHOULD or MUST? -- Hallvard From owner-ietf-sasl Tue Oct 14 08:53:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr2I7053298 for ; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFr2bK053297 for ietf-sasl-bks; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr1I7053292 for ; Tue, 14 Oct 2003 08:53:01 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EFr2lg099937; Tue, 14 Oct 2003 15:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014083522.03aaed50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 08:52:24 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> 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: At 08:01 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >>> draft-ietf-sasl-plain-02.txt says that >>> >>> The client leaves >>> the authorization identity empty if it wishes the server to derive the >>> authorization identity from the provided authentication identity. >>> >>> and >>> >>> Note that the parameters provided to the Authorize function are not >>> prepared. >>> >>> so I think the pseudo-code for empty authzid should say >>> authzid = DeriveAuthzid(authcid); >>> and not >>> authzid = DeriveAuthzid(pAuthcid); >> >> I think the current psuedo-code is correct, the first >> quoted text is misleading. > >I don't feel strongly about this, but the original wording seems >right to me. authzid is not prepared, No, the psuedo-code does not prepare the authzid. The authzid is prepared, it's just prepared by other code. I'll qualify the note with "by this code". >so neither does it >use the prepared version of authcid. The authzid is derived from the prepared authcid to ensure that all representations of the authentication identity produce the same authzid. This, I think, is important. >And that way, >PLAIN(authzid = "", authcid = X, password) does the same as >PLAIN(authzid = X, authcid = X, password). These are not necessarily equivalent. That is, authzid may not be in the same form as the authcid and may require different preparation. The psuedo code (and notes) are intended to reflect this. Kurt From owner-ietf-sasl Tue Oct 14 09:45:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjdI7055767 for ; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGjduk055766 for ietf-sasl-bks; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjcI7055761 for ; Tue, 14 Oct 2003 09:45:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EGjdlg000478; Tue, 14 Oct 2003 16:45:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014093409.03ab2c98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 09:44:46 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> 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: At 08:33 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> 3). Realm >> >> I have not yet heard any arguments to keep the realm text. > >I found it useful, since I had no clear idea what a realm was. >The text is just too demanding. How about making the text purely >informational, without any SHOULD or MUST? I think the primary concern is that the text introduces a concept with is particular to one or more mechanisms and hence is out of place. Seems better to move the text into the DIGEST-MD5 specification as it seems to following the DIGEST-MD5 concept of a realm. Other mechanisms also have realm concepts, but it's not clear to me that they are the same as DIGEST-MD5's. Kurt From owner-ietf-sasl Tue Oct 14 11:55:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItwI7060032 for ; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EItwpO060031 for ietf-sasl-bks; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItuI7060025 for ; Tue, 14 Oct 2003 11:55:56 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:53 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Oct 2003 11:55:53 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 14 Oct 2003 11:55:49 -0700 Content-class: urn:content-classes:message Subject: RE: Some implementor's notes MIME-Version: 1.0 Date: Tue, 14 Oct 2003 11:55:33 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_00A0_01C3924A.12E99900"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460539473B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Some implementor's notes thread-index: AcOSQgF/OFFnSNWNQjyVIpppTMaRZwAQhPMA From: "Paul Leach" To: "Alexey Melnikov" , "Greg Hudson" Cc: X-OriginalArrivalTime: 14 Oct 2003 18:55:49.0960 (UTC) FILETIME=[C8DA6480:01C39284] 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_000_00A0_01C3924A.12E99900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SASL's version of Digest has that clunky syntax so that it is possible to share an implementation with HTTP digest. HTTP digest couldn't get cleaned up when HTTP 1.1 was being worked on because some people claimed there were significant deployments of an earlier version. The "subsequent auth" feature was a request from client authors of apps where reconnects are frequent and the desire was to make them efficient. (POP3 clients are or used to be typical examples.) > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Alexey Melnikov > Sent: Tuesday, October 14, 2003 3:37 AM > To: Greg Hudson > Cc: ietf-sasl@imc.org > Subject: Re: Some implementor's notes > > > Greg Hudson wrote: > > >... > > > >First, I looked into CRAM-MD5. It doesn't authenticate the > server and > >it doesn't leave the window open for stream protection, but those > >issues aren't critical. I found the following sources of hidden > >complexity: > > > >... > > > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > > don't understand and which does not look trivial to implement. > > I'm sure there are real issues with internationalized usernames > > and passwords, but the blow-up in complexity seems astounding. > > > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as > well (at least it will when I publish a new revision) > > > > >Faced with these problems and a general sense of guilt at > the idea of > >implementing a weak system, I turned to DIGEST-MD5. I found > that while > >DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the > >digests, it comes with a burdensome level of complexity which is > >unrelated to its conceptual security properties. In particular: > > > > * It introduces the concepts of realms, subsequent authentication, > > and authorization IDs, none of which seem to be important > > functionality for a generic shared-secret authentication scheme, > > and all of which could (I think) be handled out of band. > > Fortunately, it's not too difficult to avoid supporting those > > features. > > > > * Messages are composed of key-value pairs which do not obey a > > consistent syntax for the value, so parsing them is hard. (I'm > > not convinced that Cyrus's implementation is correct, > particularly > > for skipping over auth-param values.) > > > I suggest you try to find a case that breaks stuff. It is > more constructive than saying that something doesn't (or may > not) work. > > > * Length-counted strings would be easier to parse than quoted > > strings while remaining human-readable. > > > > * Implicit allowance for linear whitespace has no intrinsic value > > and renders implementations more complicated and error-prone. > > > Yes. There are historical reasons why this happened. > It was a compromise between design and something that could > have been implemented by one big vendor. > It was supposed to become a replacement for another seriously > broken SASL mechanism NTLM. > > > * It is not specified whether the serv-type, host, and digest-uri > > values are required. > > > They are required to be sent, but the receiver SHOULD (but > not required > to) verify it. If the text is not clear, let me know and I > will try to fix it. > > > (Cyrus treats digest-uri as required but not > > the other two, probably because it's not specified what > you should > > do with an unspecified digest-uri when computing the > digests.) It > > is not made clear what security value, if any, these parameters > > have; to "detect accidental connection to the incorrect > server" is > > not an important function for an authentication scheme. > > > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > > like a very burdensome requirement to place on the protocol for > > the sake of a very implementation-specific convenience. One can > > avoid this complexity by not supporting UTF-8, but that in itself > > is unfortunate. > > > >Most of this complexity is there to provide wire similarity between > >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling > >justification for requiring a tenfold expansion in code size > over what > >would be required to compute the digests and do basic parsing. > > > > > See above. > > >Because of this complexity, I am likely to go back to CRAM-MD5, > >ignoring the RFC 3454 requirement in the current draft. I'm > not sure > >what SASL can do at this point to reduce the implementation burdens, > >but I have to say that I am sorely disappointed. When one > is designing > >a security system, one should compromise simplicity only in > the name of > >security. > > > SASL has nothing to do with your problem (well, very little to do). > SASL is just a framework. If you don't like mechanisms that > are currently available, you can write a new one and try to > make it deployed. > > >As promised, here are my major issues with the Cyrus SASL > >implementation: > > > > * As I've discussed before, if you're a library invoking the SASL > > library, there's no way to ensure thread-safety while remaining > > compatible with other libraries invoking SASL. > > > > * The getopt interface seems to be a barrier to successfully > > documenting or internationalizing an application's configuration > > system. > > > Why? > > > * The API does not successfully hide the complexity of the > > underlying mechanisms, such as digest-md5's realms. (By "hide" > > here I don't mean the API shouldn't support them, but that you > > should have to go to extra effort to use them, instead of having > > to go to extra effort to ignore them.) > > > Yes, this is a bit unfortunate, but I had exactly the same > problem trying to write a different SASL implementation. > > > > > * The secrets database is kept in a database format which > depends on > > the build of the library. > > > Shouldn't really. Secrets are usually stored in sasldb > backend, the format is quite stable at this point and > shouldn't change very much over the time. > > > If you go from one build to another > > (say, by upgrading versions of Red Hat) and the new build uses a > > different database, your server stops working and you get a > > cryptic error. That seems totally unacceptable, and I wonder how > > existing users of the library are dealing with it. > > > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > > > > Alexey > > > > ------=_NextPart_000_00A0_01C3924A.12E99900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlHDCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBmcwggYooAMCAQICCiFlQmAA AgAAAJYwCQYHKoZIzjgEAzBvMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1Jl ZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVW IFdpbjJLIElzc3VlIENBMB4XDTAzMDgyMTE3MDcyM1oXDTA0MDgyMDE3MDcyM1owQjErMCkGCSqG SIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTETMBEGA1UEAxMKUGF1bCBMZWFj aDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0xTvP/FlC8fgJAIfma5S5qyOlX9cEBVW6Pow YiSkWaKsfecw/fFg8olmGrV6STKTv0mxvvJgz6VprvvRgPc9/lavEa7Dg5BpW3bbEIWto40DvaqB gl9QZ9Ad+mtNFD5XyMO3Bw8JKiZgy1GIXerH6LQ+rTXmCQeqG/jVeOxoFiUCAwEAAaOCBJEwggSN MAsGA1UdDwQEAwIFoDAdBgNVHQ4EFgQUIaL8rFmdmJIbwYUpAThTsFPTjXowKQYJKwYBBAGCNxQC BBweGgBTAG0AYQByAHQAYwBhAHIAZABVAHMAZQByMIGUBgNVHSMEgYwwgYmAFCAZq9iZaHr5hoL6 cnmH00RgUUXvoWWkYzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQL EwVOdGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMoIK LgdxZgAFAAACIzCCAa4GA1UdHwSCAaUwggGhMIHioIHfoIHchoHZbGRhcDovLy9DTj1OVERFViUy MFdpbjJLJTIwSXNzdWUlMjBDQSgxKSxDTj1udGRldjJrY2EsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29y cCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBcoFqgWIZWaHR0cDovL250ZGV2MmtjYS5udGRl di5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFdpbjJLJTIwSXNzdWUlMjBD QSgxKS5jcmwwXKBaoFiGVmh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvTlRERVYlMjBXaW4ySyUyMElzc3VlJTIwQ0EoMSkuY3JsMIIBaQYIKwYBBQUH AQEEggFbMIIBVzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPU5UREVWJTIwV2luMkslMjBJc3N1 ZSUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRp ZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhQYIKwYBBQUH MAKGeWh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv bnRkZXYya2NhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFdpbjJLJTIwSXNzdWUl MjBDQSgyKS5jcnQwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwQGCCsGAQUFBwMCMFMG A1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1 bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTAJBgcqhkjOOAQDAy4AMCsCE0S2SLEdb4WEJv055mWF zOTOP/MCFFKWyliMgynk36EVIBHy8sw1aqfLMIIGlzCCBlagAwIBAgIKLgdxZgAFAAACIzAJBgcq hkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2 MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4XDTAyMTAx MTE3MDg1NloXDTA0MTAxMTE3MTg1NlowbzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU5UREVWMR0wGwYDVQQD ExROVERFViBXaW4ySyBJc3N1ZSBDQTCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQCTCC1vMkOpDkgx MJmlg1rQPpIRgEdDJNoJMpf47nK1k2QMx4tBoKaHhWPcxyblUTiWEz/ahR9Pb027PZS+l3Hg11Zn CkUDWv+Ua+x7HgRn88y219o5g5KLvXfXP66hargC7sip9Zs+qN1OMqrg6aKRNynCxav2lTghPQBO 4gc+LwIVANmVGNJGOMKtxSR5S3dlI7slhj0rAoGAVEWozto8isIYr5QbAWkAHlzfc2tX+2RhE/oa lqehpAtFfvDeWau/csQQ3QWZI46spI7ebyvGiOVbLF5HQMxAJ2fBC0XZBLM82YgeKuOfVYwam6gs TiYm24oKz7VbdofyCfjelJRXT2mJEeUonMaKbAySJySfQuELBvKxCUC7lqADgYQAAoGAFiRVn6Ny rDG1yvxstlatKvIt3Pd3oU148+jngq4lE6L7DCia91idkKfri321sSLZJpRWjw0tBXyV6PhX1Ofy cM04WMpYttjpgtYy31cMXmnnMgxC+jAYcOwYp6ecTGVxNRuZNzez3xmwZ9z82SfRCqmDh1EMNXYr QR0H4VUHI+ajggOIMIIDhDASBgkrBgEEAYI3FQEEBQIDAQACMB0GA1UdDgQWBBQgGavYmWh6+YaC +nJ5h9NEYFFF7zAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTivgNw1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAw ggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9y ZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNz PWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRwOi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0 LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGlj YTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NO PU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIu bnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWlj cm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUp LmNydDAJBgcqhkjOOAQDAzAAMC0CFHNk8vkyGD3GAmwPvUg1m5fVyfGTAhUAhnex7TIppYeW5OMY qJonfdc4Z5UwggaoMIIGEaADAgECAgor++JGAAMAMgjEMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERF ViBJU1NVRTMgQ0EwHhcNMDMwODIxMTcwNzExWhcNMDQwODIwMTcwNzExWjCBsDETMBEGCgmSJomT 8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNv cnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGln aHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqoW5IwY+zVFVnkEXvyXTr2NUw9BIh1G5Prz/7ICp7EF4y T3KXY5VXzfTgSaq3PofyDHpgtxz/mKKYyLxHiXYoovpCajquTpTyr3dlPpj6bkLpAHH7wWR3VvyX G3bzbYePZpkBho4/qI7SZhRhKJH8Jr4WgtcpMB+WZonry1GRZQIDAQABo4IEKzCCBCcwCwYDVR0P BAQDAgeAMB0GA1UdDgQWBBSd1h+ZKvVxSfNGOZpADzy9ClfE0jA+BgkrBgEEAYI3FQcEMTAvBicr BgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYK/nPZ8ht7mgFQCAXgCAQEwHwYDVR0jBBgwFoAU i9HNYfHpr468kdBA6im/5i6FQFcwggGIBgNVHR8EggF/MIIBezCCAXegggFzoIIBb4aBz2xkYXA6 Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSgyKSxDTj1XSElDQTMsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZNaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9OVERFVkNSTHMvTlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcmyGTGh0 dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ U1NVRTMlMjBDQSgyKS5jcmwwggFUBggrBgEFBQcBAQSCAUYwggFCMIHFBggrBgEFBQcwAoaBuGxk YXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRp b25BdXRob3JpdHkweAYIKwYBBQUHMAKGbGh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3Nv ZnQuY29tL0NlcnRFbnJvbGwvV0hJQ0EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUy MElTU1VFMyUyMENBKDMpLmNydDATBgNVHSUEDDAKBggrBgEFBQcDBDAtBgNVHSAEJjAkMCIGICsG AQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVAYMRMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH AwQwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRldi5taWNyb3NvZnQuY29t gRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMA0GCSqGSIb3DQEBBQUAA4GBAH/THraMU6d3 3PRTCS9MWY9ECxgGz/q4JBjPeHGdBKdcH3zjo291rfdmP8iqjekjHPC5Q7Mk2pghYt5IeksAdKNF PoPNOMaDVAM1BBMczPerfR1VA/jpltBeNrKc+X+en2VBlHVXTF/WDix7cgiVSKuO4njAykP1sCck FLpQVeTpMIIIGzCCBwOgAwIBAgIKKMbncgABAAAANTANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYg U0EgUm9vdCBDQTAeFw0wMjEwMTAxNjMzMDBaFw0wNTEwMTAxNjQzMDBaMGExCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRl cm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMIIBtzCCASsGByqGSM44BAEwggEeAoGBAPoSz3u7 mLB5rhlH5CE5AalrBl6Ntst+vZLNPRPhI8ABrNuHKYWlR6hWd/ikP5IMgDQr7DUpJrrdv4Z2T1pJ PVEHIxCua3HTX/o+XVGTZXdBv4x+OhHLmt11KcTy9B+0tpg3psJC4m+taONabd+yw/EB9AoPldGd HoGBBSGOdALjAhUAmE+UPbJ1WtXpFK2UwmM6G/zo60MCgYBmyg997xQQPnCr4IraxqUi5sXXsvSP vimwO/UEFxJwAiWS8OUunvnh7Gd0/scD5YNkVAsbRYF+XNgyYVCsYusC1LH8DvoOzq4Hz8lg9K/2 kA80v2Skr4DH1EFM2JG3J9Hbq362Dk9i8V6HAZEA/P8kB9/J+cI1LoXlWtfw5uaCmAOBhQACgYEA okrSViTIQt7ZG0Ytjr2GLccq5bTzDsmUdROQz1qi9eb5cOIYa2YXgE6cmZTIIFOLx6bPdgbwZSAs OfBQofQoLG3vJeQcGsA/vj7wzjmzlaImYsBF9OZRFKl7C3r/TLShHXBTQHo16zcCGuLCXhQvOsrj JhlKvhvR5fMmNpOK4jmjggRTMIIETzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTivgNw1Ysg 0kFEaq/myHdxWiUAHzALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwQABTAjBgkrBgEEAYI3 FQIEFgQU1lIoN1kh422F4hJqLWNtqmi8a0AwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUiMnNnJw6IoDq5C3aFUcv9fvEvJswggGZBgNVHR8EggGQMIIBjDCCAYigggGEoIIB gIaB2WxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKSxDTj13aGljYXNhcm9vdGNh LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGUWh0dHA6 Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFNB JTIwUm9vdCUyMENBKDEpLmNybIZPaHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybDCCAekGCCsGAQUFBwEB BIIB2zCCAdcwgcgGCCsGAQUFBzAChoG7bGRhcDovLy9DTj1OVERFViUyMFNBJTIwUm9vdCUyMENB LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhAYIKwYBBQUHMAKGeGh0 dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDCBggYIKwYBBQUHMAKGdmh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYl MjBTQSUyMFJvb3QlMjBDQSgxKS5jcnQwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBBQUA A4IBAQA0wmQlGbxPwheWF+0oj8v1hjBbV13gmBK/2Oy0q2OcgC/o+GSkKK+5S36xOxTvVIBio37P i6jtJI8WneO9ONcLQK5NHuUV3j9FFtCM2TnLbq/OJHu+rKrYIBRYAjn3y6oWPaZQnH1Ug6Qa54AC El1bocfKBM6bVNlJKnB+WRpnwb4MrXQinvr0rYrlYH+Z7xECHo+aJ9qnp7cXXzELF57Y9qBBbqY5 keifWFfX+NxhFpRrgwtS6LtdIPOInQLG2kPoY8QafHvTSBj4IuSxdaN+d0d9n1ODnN4IKRhRYiVS pwP7aoLrK3FelYjdLEH7XQC2q+T41duYgNhWl0Dkf26XMYIC6TCCAuUCAQEwWTBLMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYg SVNTVUUzIENBAgor++JGAAMAMgjEMAkGBSsOAwIaBQCgggHmMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAxNDE4NTUzM1owIwYJKoZIhvcNAQkEMRYEFPdbwOnO ppyG4GuX9P7P1EX02u5RMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGMBgkrBgEEAYI3EAQxfzB9MG8xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4G A1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOVERFVjEdMBsGA1UE AxMUTlRERVYgV2luMksgSXNzdWUgQ0ECCiFlQmAAAgAAAJYwgY4GCyqGSIb3DQEJEAILMX+gfTBv MQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1p Y3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVWIFdpbjJLIElzc3VlIENBAgoh ZUJgAAIAAACWMA0GCSqGSIb3DQEBAQUABIGAXpjbVOG6vEm8Ft/Id52KsowOHebp+rsm2uWqmYHx hJih28lSm+GAR57zi2xIbBoqOEoeps9m2GJ8ocbREn41peis80LNw9j26gyfJwurdyss2FkHZ3HW cOW9gJr7w6WCtz1DZ2oYZeBYiYUpZBGdxeOHopRnSXgU0rc0WY6RKysAAAAAAAA= ------=_NextPart_000_00A0_01C3924A.12E99900-- From owner-ietf-sasl Tue Oct 14 13:41:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfcI7064250 for ; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EKfcsS064249 for ietf-sasl-bks; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfaI7064242 for ; Tue, 14 Oct 2003 13:41:37 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Vz5-0007Y2-J3 for ietf-sasl@imc.org; Tue, 14 Oct 2003 22:41:35 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9Vz4-0006b5-5H; Tue, 14 Oct 2003 22:41:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Vz3-00041y-00; Tue, 14 Oct 2003 22:41:33 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis issues Date: Tue, 14 Oct 2003 22:41:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are various editorial and non-editorial comments for draft-ietf-sasl-rfc2831bis-02.txt. > Table of Contents > 3.8 CBC MODE ATTACKS............................................. Missing page number. > 1.1 Conventions and Notation > This specification uses the same ABNF notation and lexical > conventions as HTTP/1.1 specification; see section 7. ...as well as some named rules defined there (section 7.2). > The value of a quoted string constant as an octet string does not > include any terminating null character ...which the C language adds. [For readers who don't know C, if any.] > 2.1.1 Step One > > The server starts by sending a challenge. How does it know that it should do that? > nonce > Note > that since the string is passed as a quoted string, the > double-quote and backslash? > character is not allowed unless escaped (see section > 7.2). I think this applies to other quoted strings than the nonce. > server_maxbuf ("maximal ciphertext buffer size") > Let call "maximal cleartext buffer size" (or "maximal sender > size") the maximal size of a cleartext buffer that, after being "Let call"? Should be "Call", or "Let .... be", I think. > charset > This directive, if present, specifies that the server supports > UTF-8 [UTF-8] encoding for the username, realm and password. If > present, the username, realm and password are in Unicode, prepared > using the "SASLPrep" profile [SASLPrep] of the "stringprep" > algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not > present, the username, realm and password MUST be encoded in ISO > 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). There is no username and password sent by the server. Do you mean the _client_ MUST send them in UTF-8 if "charset" is given by the server? > cipher-opts > "qop-options" directive, in which case the "3des" cipher is > mandatory-to-implement. I suggest you remove the "-"s in mandatory-to-implement. > 2.1.2 Step Two > digest-uri > Indicates the principal name of the service with which the client > wishes to connect, formed from the serv-type, host, and serv-name. > For example, the FTP service on "ftp.example.com" would have a > "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from > the example above would have a "digest-uri" value of > "SMTP/mail3.example.com/example.com". > > Servers SHOULD check that the supplied value is correct. This will > detect accidental connection to the incorrect server, as well as some > redirection attacks. It is also so that clients will be trained to > provide values that will work with implementations that use a shared > back-end authentication service that can provide server > authentication. > > The serv-type component should match the service being offered. The > host component should match one of the host names of the host on > which the service is running, or it's IP address. Servers SHOULD NOT > normally support the IP address form, because server authentication > by IP address is not very useful; they should only do so if the DNS > is unavailable or unreliable. The serv-name component should match > one of the service's configured service names. > > This directive may appear at most once; if multiple instances are > present, the client should abort the authentication exchange. > > Note: In the HTTP use of Digest authentication, the digest-uri is the > URI (usually a URL) of the resource requested -- hence the name of > the directive. Is this entire section about digest-uri? If so, most of it should be indented. > authzid > The server SHOULD verify the correctness of an authzid as > specified by the corresponding SASL protocol profile. Which corresponding SASL profile? > 2.2 Subsequent Authentication > > If the client has previously authenticated to the server, and > remembers the values of username, realm, nonce, nonce-count, cnonce, ^^^^^^^^ > and qop that it used in that authentication, and the SASL profile for > a protocol permits an initial client response, then it MAY perform > "subsequent authentication", as defined in this section. What's the point of authenticating again with the same username? Auth with a _different_ username would be more interesting. > 2.2.2 Step Two > If the response is valid, the server MAY choose to deem that > authentication has succeeded. However, if it has been too long since > the previous authentication, or for any o including the next > subsequent authentication, between the client and the server MUST be > integrity protected. I don't understand the text starting with "or from any o". > Using as a base session key the value of H(A1) > as defined above need a "," here > Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the > received value; the message is discarded if they differ. The > receiver's sequence counter is incremented if they match. Doesn't the server send a response? How does the client know that the authentication is completed? > 2.4 Confidentiality Protection > > If the server sent a "cipher-opts" directive and the client responded > with a "cipher" directive, then subsequent messages between the > client and the server MUST be confidentiality protected. What is confidentiality protection? > The IV used to send/receive the initial buffer You might say "Initialization Vector (IV)" again here, it's been a while since you mentined what an IV is. > SEAL(Ki, Kc, SeqNum, msg) = > {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001, > SeqNum} SEAL? That is never used in this document. > 5.1 Normative references > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > [Unicode] The Unicode Consortium, "The Unicode Standard, Version Indent "The". > [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC > 2279, Janyary 1998. Indent "Yergeau". > [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Unindent "Hinden". > [FIPS] National Institute of Standards and Technology, "DES Modes of Indent "National". > [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", Indent "Daemen". > 5.2 Informative references > [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", Indent "Kaliski". > [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: Indent "Moeller". > 7.1 Augmented BNF Since <"> means to enclose a literal, you might replace other <">s with <'>s in this section. E.g. > rule1 | rule2 > Elements separated by a bar ("|") are alternatives, e.g., "yes | > no" will accept yes or no. Elements separated by a bar ('|') are alternatives, e.g., 'yes | no' will accept yes or no. > #rule > ( *LWS element *( *LWS "," *LWS element )) Should this really be asymmetric, or should it be ( element *( *LWS "," *LWS element )) or ( *LWS element *( *LWS "," *LWS element ) *LWS ) ? > 7.2 Basic Rules > OCTET = s/character/byte/, I think. A byte in a multi-byte UTF-8 character is not normally considered a character. > 8 Sample Code > for (scan = base; scan < end; ++scan) { > if (*scan > 0xC3) break; /* abort if outside 8859-1 */ > if (*scan >= 0xC0 && *scan <= 0xC3) { > if (++scan == end || *scan < 0x80 || *scan > 0xBF) > break; /* * Handle invalid UTF-8-like sequences, e.g. '\0' * encoded as "\xC0\x80". Accepting such sequences * is a security risk, according to [UTF-8]. */ if (*scan < 0xC2) return an error or something; Error return also requires the return type of the function to be changed, and a 'return success' at the end. Maybe another way is to simply not translate invalid UTF-8 strings to iso8859-1. This should also be discussed in the section which says that UTF-8 should be converted to iso8859-1 when possible. > } > } -- Hallvard From owner-ietf-sasl Wed Oct 15 03:58:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwXI7072093 for ; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FAwX2N072092 for ietf-sasl-bks; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwVI7072086 for ; Wed, 15 Oct 2003 03:58:31 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9jMK-0002Bu-Qs for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:28 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9jMG-0006WN-Em for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:24 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9jMB-0006DA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:19 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis: A2 when qop-value=token Date: Wed, 15 Oct 2003 12:58:19 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2831bis 2.1.1 "Step One" says: qop-options = "qop" "=" <"> qop-list <"> qop-list = 1#qop-value qop-value = "auth" | "auth-int" | "auth-conf" | token 2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is "auth", "auth-int" and "auth-conf", but not when it is . -- Hallvard From owner-ietf-sasl Wed Oct 15 04:31:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVOI7073131 for ; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBVO6x073130 for ietf-sasl-bks; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVMI7073120 for ; Wed, 15 Oct 2003 04:31:23 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9js8-0006Cl-JA for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:20 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9js5-0005N7-KS for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9js5-0006IA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: re-negotiating SASL security layer Date: Wed, 15 Oct 2003 13:31:17 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis section 6.3 "Multiple authentications" says: If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer must be removed. Exactly when is the old layer canceled? If an old layer is active and the client starts to negotiate a new layer, it may not know when to expect the response from the server. So the layer can't be canceled by starting a new negotiation. It could be canceled after receipt of the first response from the server. Or after the completed SASL negotiation, which would be performed with the old layer in effect. I don't know how easy that would be to implement, or if it would interfere with the definitions of some SASL mechanisms to have two mechanisms active at the same time. Another way would for the layers themselves contain a 'cancel layer' operation, which may only be used just before negotiating a new layer and before closing the connection. Then the SASL negotiation could be performed without mixing the old and the new SASL mechanism, and the layer could only be re-negotiated if the old layer had such a 'cancel layer' operation. -- Hallvard From owner-ietf-sasl Wed Oct 15 04:33:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXZI7073224 for ; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBXZT0073223 for ietf-sasl-bks; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXYI7073218 for ; Wed, 15 Oct 2003 04:33:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:33:36 +0100 Message-ID: <3F8D308B.5050208@isode.com> Date: Wed, 15 Oct 2003 12:33:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2831bis 2.1.1 "Step One" says: > > qop-options = "qop" "=" <"> qop-list <"> > qop-list = 1#qop-value > qop-value = "auth" | "auth-int" | "auth-conf" | > token > >2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >"auth", "auth-int" and "auth-conf", but not when it is . > Hi Hallvard, Token is specifically for future extensions, if you see a qop value you don't recognize - you have to ignore it. If you recognize nothing, you have to fail the authentication exchange. Do you want any clarifications on this to be added to the document. (I will go through your big message over weekend). Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Wed Oct 15 04:52:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq9I7073626 for ; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBq93X073625 for ietf-sasl-bks; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq7I7073620 for ; Wed, 15 Oct 2003 04:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:52:08 +0100 Message-ID: <3F8D34E4.4020607@isode.com> Date: Wed, 15 Oct 2003 12:52:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2222bis section 6.3 "Multiple authentications" says: > > If a security layer is in effect > and a subsequent SASL negotiation selects a second security layer, > then the second security layer replaces the first. If a security > layer is in effect and a subsequent SASL negotiation selects no > security layer, the original security layer must be removed. > >Exactly when is the old layer canceled? > >If an old layer is active and the client starts to negotiate a new >layer, it may not know when to expect the response from the server. >So the layer can't be canceled by starting a new negotiation. > No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully. Each profile document must document exactly when this takes place. A subsuquent authentication takes place while an old security layer is still in effect. >It could be canceled after receipt of the first response from the >server. Or after the completed SASL negotiation, which would be >performed with the old layer in effect. I don't know how easy that >would be to implement, or if it would interfere with the definitions of >some SASL mechanisms to have two mechanisms active at the same time. > >Another way would for the layers themselves contain a 'cancel layer' >operation, which may only be used just before negotiating a new layer >and before closing the connection. Then the SASL negotiation could be >performed without mixing the old and the new SASL mechanism, and the >layer could only be re-negotiated if the old layer had such a 'cancel >layer' operation. > > Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 11:43:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh7I7026999 for ; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IIh72l026998 for ietf-sasl-bks; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh5I7026992 for ; Sat, 18 Oct 2003 11:43:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 19:43:25 +0100 Message-ID: <3F915345.8070201@isode.com> Date: Sat, 18 Oct 2003 15:50:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>>4.1. Authentication protocol exchange >>>> >>>> A SASL mechanism is responsible for conducting an authentication >>>> protocol exchange. This consists of a series of server challenges >>>> and client responses, >>>> >>>> >>>> >>>Does this mean that the initial auth command from the client is not >>>considered part of the authentication protocol exchange? >>> >>> >>> >>Does it matter in this section? >> > >Well, that's where "authentication protocol exchange" seems to be >defined. It matters if other documents refer to "the authentication >protocol exchange". > >Anyway, I think I found the answer in section 6.1. The initial auth >command from the client is not part of the exchange, but the optional >"response" in the auth command is. > Sorry, this makes little sense to me. Semantically the initial response *is* part of an authentication exchange. It is just an optimization to avoid a round trip. > > >>>>4.2. Authorization identities and proxy authentication >>>> >>>> (...) >>>> The character encoding scheme used for transmitting an authorization >>>> identity over protocol is specified in each authentication mechanism >>>> (with the authentication mechanism's blob being further >>>> >>>> >>> ^^^^ >>> >>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>like the dictionary says:-) >>> >>> >>I've changed this to "data". >> >> > >I still don't know _which_ data you are talking about. > > Data is defined (and specific to) by each SASL mechanism. >>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>top. >>> >>> >>> >>I've added a sentence about this in the introduction section. >> >> > >I'm pretty sure you will still need to insert the words "Obsoletes: rfc >2222" in the header sometime, though I don't remember where this is >stated. > I think this is going to be added by a RFC editor. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 12:57:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJvAI7029677 for ; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IJvAxB029676 for ietf-sasl-bks; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJv4I7029670 for ; Sat, 18 Oct 2003 12:57:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 20:57:18 +0100 Message-ID: <3F919B07.6050909@isode.com> Date: Sat, 18 Oct 2003 20:56:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 04:52 AM 10/8/2003, Alexey Melnikov wrote: > > >>>> In >>>> order to avoid noninteroperability due to differing normalizations, >>>> when a mechanism specifies that a string authentication identity or >>>> password used as input to a cryptographic function (or used for >>>> comparison) it SHOULD specify that the string first be prepared using >>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>> [StringPrep]. This should be done by both the client (upon getting >>>> user input or retrieving a value from configuration) and by the >>>> server (upon receiving the value from the client). >>>> >>>> >>>> >>>What's the point of this duplicate preparation? Why not do it only >>>at the server side? >>> >>> >>> >>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> > >Alexey, the current text suggests that client (1) prep the >value before sending, the server then preps it (2) again >(before comparing it to the store value, which also should >be prep'ed (3) either before storing it or before each compare). > Ok, I am with you now. IMHO, as a server writer, I would do (2) anyway. But of course this is my personal opinion. However there is one case when all three may make sense. Imagine that there are two clients that use PLAIN. One of the prepares username/password, the other one doesn't. If the server also does preparation, it will be able to interoperate with both clients. > >We need to REQUIRE that mechanisms specify how character strings >are to be prepared for comparison and RECOMMEND that they use >SASLprep for simple user names and passwords. > >We should not suggest that mechanisms should do both (1) and >(2). (1) and (3) OR (2) or (3) are sufficient to ensure >proper matching. > IMHO, this is a responsibility of the client, so I will clarify that. But I will add that the server "MAY prepare". Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ From owner-ietf-sasl Sat Oct 18 13:06:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6rI7029838 for ; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IK6rm5029837 for ietf-sasl-bks; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6lI7029831 for ; Sat, 18 Oct 2003 13:06:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:07:07 +0100 Message-ID: <3F919D54.7070306@isode.com> Date: Sat, 18 Oct 2003 21:06:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> In-Reply-To: <3F919B07.6050909@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > >>>>> In >>>>> order to avoid noninteroperability due to differing normalizations, >>>>> when a mechanism specifies that a string authentication identity or >>>>> password used as input to a cryptographic function (or used for >>>>> comparison) it SHOULD specify that the string first be prepared using >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>> [StringPrep]. >>>> The new text after that reads: There are three entities that has to deal with this issue: a client (upon getting user input or retrieving a value from configuration), a server (upon receiving the value from the client) and a utility that is able to store passwords/hashes in a database that can be later used by the server. The preparation must be done by the client and the utility and may be done by the server. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. >>>>> This should be done by both the client (upon getting >>>>> user input or retrieving a value from configuration) and by the >>>>> server (upon receiving the value from the client). >>>>> >>>> >>>> What's the point of this duplicate preparation? Why not do it only >>>> at the server side? >>> >>> Because if the client doesn't do that, the hash calculated on the >>> server will not match the one calculated on the client. >> >> Alexey, the current text suggests that client (1) prep the >> value before sending, the server then preps it (2) again >> (before comparing it to the store value, which also should >> be prep'ed (3) either before storing it or before each compare). > > Ok, I am with you now. > > IMHO, as a server writer, I would do (2) anyway. But of course this is > my personal opinion. > > However there is one case when all three may make sense. Imagine that > there are two clients that use PLAIN. > One of the prepares username/password, the other one doesn't. If the > server also does preparation, it will be able to interoperate with > both clients. > >> We need to REQUIRE that mechanisms specify how character strings >> are to be prepared for comparison and RECOMMEND that they use >> SASLprep for simple user names and passwords. >> >> We should not suggest that mechanisms should do both (1) and >> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >> proper matching. > > IMHO, this is a responsibility of the client, so I will clarify that. > But I will add that the server "MAY prepare". Alexey From owner-ietf-sasl Sat Oct 18 13:10:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAsI7029921 for ; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IKAsvw029920 for ietf-sasl-bks; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAnI7029911 for ; Sat, 18 Oct 2003 13:10:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:10:59 +0100 Message-ID: <3F919E3C.2040504@isode.com> Date: Sat, 18 Oct 2003 21:10:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >Simon raised this issue to me privately... but I think it needs >broader discussion (given that it is a technical issue). > >At 02:19 PM 10/2/2003, Simon Josefsson wrote: > > >>* The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing). >> >> > >That is, what should the implementation do if the message it receives >is malformed? > >I note that this issue is likely not unique to ANONYMOUS. So, maybe >it should be dealt with in base SASL specification. > >I'm thinking a malformed message should be treated as a protocol >error in the application protocol. > I agree. However, can you be more specific what do you want me to add to the base spec. Alexey From owner-ietf-sasl Thu Oct 23 06:14:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEDI7062616 for ; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NDEDrr062615 for ietf-sasl-bks; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEBI7062603 for ; Thu, 23 Oct 2003 06:14:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17392; Thu, 23 Oct 2003 09:14:02 -0400 (EDT) Message-Id: <200310231314.JAA17392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-08.txt Date: Thu, 23 Oct 2003 09:14:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-08.txt Pages : 37 Date : 2003-10-22 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nystrom-http-sasl-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nystrom-http-sasl-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Oct 27 03:08:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB84I7043644 for ; Mon, 27 Oct 2003 03:08:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RB84Cl043643 for ietf-sasl-bks; Mon, 27 Oct 2003 03:08:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB7tI7043626 for ; Mon, 27 Oct 2003 03:08:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Mon, 27 Oct 2003 11:08:03 +0000 Message-ID: <3F9C2F32.1060004@isode.com> Date: Sun, 26 Oct 2003 20:31:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Here are various editorial and non-editorial comments for >draft-ietf-sasl-rfc2831bis-02.txt. > > >>Table of Contents >> >> >> 3.8 CBC MODE ATTACKS............................................. >> >> > >Missing page number. > Yes, I was lazy. I was changing text a lot, so I had to spend a lot of time fixing page numbers when doing each revision. So I just gave up. >>1.1 Conventions and Notation >> >> >> This specification uses the same ABNF notation and lexical >> conventions as HTTP/1.1 specification; see section 7. >> >> > >...as well as some named rules defined there (section 7.2). > 7 implies 7.2. >> The value of a quoted string constant as an octet string does not >> include any terminating null character >> >> > >...which the C language adds. > >[For readers who don't know C, if any.] > > IMHO, readers who don't know C will not care about this comment anyway, because it doesn't add any additional information. >>2.1.1 Step One >> >> The server starts by sending a challenge. >> >> > >How does it know that it should do that? > The client always starts first (according to SASL). If the client doesn't includes an initial response, the server will know. Can you suggest any clarification text here? >> nonce >> Note >> that since the string is passed as a quoted string, the >> double-quote >> >> > >and backslash? > Actually, I've changed ABNF to disallow double-quotes or backslashes. So, this should be removed. >> character is not allowed unless escaped (see section >> 7.2). >> >> > >I think this applies to other quoted strings than the nonce. > Yes, but it is especially problematic for nonces, as people just generate binary data and than forget to quote it. >> server_maxbuf ("maximal ciphertext buffer size") >> >> > > > >> Let call "maximal cleartext buffer size" (or "maximal sender >> size") the maximal size of a cleartext buffer that, after being >> >> > >"Let call"? Should be "Call", or "Let .... be", I think. > Ok. >> charset >> This directive, if present, specifies that the server supports >> UTF-8 [UTF-8] encoding for the username, realm and password. If >> present, the username, realm and password are in Unicode, prepared >> using the "SASLPrep" profile [SASLPrep] of the "stringprep" >> algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not >> present, the username, realm and password MUST be encoded in ISO >> 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). >> >> > >There is no username and password sent by the server. Do you mean the >_client_ MUST send them in UTF-8 if "charset" is given by the server? > Yes. >> cipher-opts >> >> >> "qop-options" directive, in which case the "3des" cipher is >> mandatory-to-implement. >> >> > >I suggest you remove the "-"s in mandatory-to-implement. > This is a term used in SASL. By using "-" I am trying to emphasize this. >>2.1.2 Step Two >> >> >> digest-uri >> Indicates the principal name of the service with which the client >> wishes to connect, formed from the serv-type, host, and serv-name. >> For example, the FTP service on "ftp.example.com" would have a >> "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from >> the example above would have a "digest-uri" value of >> "SMTP/mail3.example.com/example.com". >> >> Servers SHOULD check that the supplied value is correct. This will >> detect accidental connection to the incorrect server, as well as some >> redirection attacks. It is also so that clients will be trained to >> provide values that will work with implementations that use a shared >> back-end authentication service that can provide server >> authentication. >> >> The serv-type component should match the service being offered. The >> host component should match one of the host names of the host on >> which the service is running, or it's IP address. Servers SHOULD NOT >> normally support the IP address form, because server authentication >> by IP address is not very useful; they should only do so if the DNS >> is unavailable or unreliable. The serv-name component should match >> one of the service's configured service names. >> >> This directive may appear at most once; if multiple instances are >> present, the client should abort the authentication exchange. >> >> Note: In the HTTP use of Digest authentication, the digest-uri is the >> URI (usually a URL) of the resource requested -- hence the name of >> the directive. >> >> > >Is this entire section about digest-uri? If so, most of it should be >indented. > > >> authzid >> >> >> The server SHOULD verify the correctness of an authzid as >> specified by the corresponding SASL protocol profile. >> >> > >Which corresponding SASL profile? > I meant that any protocol using SASL should verify authorization identity as specified in the SASL profile for the protocol. Any suggestion how to make this clear? >>2.2 Subsequent Authentication >> >> If the client has previously authenticated to the server, and >> remembers the values of username, realm, nonce, nonce-count, cnonce, >> >> > ^^^^^^^^ > > >> and qop that it used in that authentication, and the SASL profile for >> a protocol permits an initial client response, then it MAY perform >> "subsequent authentication", as defined in this section. >> >> > >What's the point of authenticating again with the same username? Auth >with a _different_ username would be more interesting. > This is a case of fast reauthentication using a different TCP connection. This is similar to resuming a TLS session. >>2.2.2 Step Two >> >> >> If the response is valid, the server MAY choose to deem that >> authentication has succeeded. However, if it has been too long since >> the previous authentication, or for any o including the next >> subsequent authentication, between the client and the server MUST be >> integrity protected. >> >> > >I don't understand the text starting with "or from any o". > The text in my copy says: If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication. So I am not sure where have you found this. >> Using as a base session key the value of H(A1) >> as defined above >> >> > >need a "," here > Ok. >> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >> received value; the message is discarded if they differ. >> >> The >> receiver's sequence counter is incremented if they match. >> >> > >Doesn't the server send a response? How does the client know that the >authentication is completed? > This whole section talks about protecting data when authentication is already complete. > ... > >>5.1 Normative references >> >> >> [RFC 2222] Myers, J., "Simple Authentication and Security Layer >> (SASL)", RFC 2222, October 1997. >> >> > >Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > Fixed, thanks. >... > >> ( *LWS element *( *LWS "," *LWS element )) >> >> > >Should this really be asymmetric, or should it be > ( element *( *LWS "," *LWS element )) >or > ( *LWS element *( *LWS "," *LWS element ) *LWS ) > I can go for the last proposal. At least it seems to be the original intent. >? > > > >>7.2 Basic Rules >> >> > > > >> OCTET = >> >> > >s/character/byte/, I think. > I actually disagree in this case. A byte has 8 bits by definition. > A byte in a multi-byte UTF-8 character >is not normally considered a character. > I am not talking about Unicode characters here. Thank you for your comments. In the meantime I will work (and think more) on the rest of them. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ From owner-ietf-sasl Mon Oct 27 11:03:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3wI7068824 for ; Mon, 27 Oct 2003 11:03:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJ3w5U068823 for ietf-sasl-bks; Mon, 27 Oct 2003 11:03:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3pI7068808 for ; Mon, 27 Oct 2003 11:03:52 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECec-0003C4-9J; Mon, 27 Oct 2003 20:03:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECeZ-00026i-JM; Mon, 27 Oct 2003 20:03:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECeZ-00023k-00; Mon, 27 Oct 2003 20:03:47 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:03:47 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>1.1 Conventions and Notation >>> >>> This specification uses the same ABNF notation and lexical >>> conventions as HTTP/1.1 specification; see section 7. >> >>...as well as some named rules defined there (section 7.2). >> > 7 implies 7.2. True. Please add '...and named rules', though. Those are not notation or lexical conventions. >>> The value of a quoted string constant as an octet string does not >>> include any terminating null character >> >>...which the C language adds. >> >>[For readers who don't know C, if any.] >> > IMHO, readers who don't know C will not care about this comment anyway, > because it doesn't add any additional information. Disagree. For such readers, this comment adds a confusing reference to a null character which they can't find elsewhere in the draft. It might be better to just delete the sentence, though. >>>2.1.1 Step One >>> >>> The server starts by sending a challenge. >> >>How does it know that it should do that? >> > The client always starts first (according to SASL). If the client > doesn't includes an initial response, the server will know. > > Can you suggest any clarification text here? 'The server starts by sending a challenge after the client indicates that SASL negotiatin should start'? >>>2.1.2 Step Two >>> authzid >>> >>> >>> The server SHOULD verify the correctness of an authzid as >>> specified by the corresponding SASL protocol profile. >>> >>> >> >>Which corresponding SASL profile? >> > I meant that any protocol using SASL should verify authorization > identity as specified in the SASL profile for the protocol. Any > suggestion how to make this clear? Using your words, The server SHOULD verify the correctness of an authzid as specified by the SASL profile for the protocol. >>>2.2 Subsequent Authentication >>> >>> If the client has previously authenticated to the server, and >>> remembers the values of username, realm, nonce, nonce-count, cnonce, >> ^^^^^^^^ >>> and qop that it used in that authentication, and the SASL profile for >>> a protocol permits an initial client response, then it MAY perform >>> "subsequent authentication", as defined in this section. >> >>What's the point of authenticating again with the same username? Auth >>with a _different_ username would be more interesting. >> > This is a case of fast reauthentication using a different TCP > connection. This is similar to resuming a TLS session. Oh. Could you add 'even after closing the connection and reopening a new one' in section 2.2? >>>2.2.2 Step Two >>> >>> If the response is valid, (...) >> >>I don't understand the text starting with "or from any o". >> > The text in my copy says: > > (...) Thanks. > So I am not sure where have you found this. It's in http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt. >>> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >>> received value; the message is discarded if they differ. >>> (...) >> > This whole section talks about protecting data when authentication is > already complete. Not in the published draft. There, this sentence occurs in section 2.2.2. But there is no section between 2.2.2 and 2.4, so I guess this part of the published draft got garbled. >>>7.2 Basic Rules >> >>> OCTET = >> >>s/character/byte/, I think. >> > I actually disagree in this case. A byte has 8 bits by definition. No it hasn't. That's why the term 'octet' was invented. A byte is an addressable machine unit, which is _usually_ 8 bits nowadays. >> A byte in a multi-byte UTF-8 character >>is not normally considered a character. >> > I am not talking about Unicode characters here. A 'character' is part of a character set. Which character set is it supposed to be part of here, if not UTF-8? Maybe you are thinking of C, where the 'byte' type is called (unsigned) char? -- Hallvard From owner-ietf-sasl Mon Oct 27 11:15:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFQI7069534 for ; Mon, 27 Oct 2003 11:15:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJFQxt069533 for ietf-sasl-bks; Mon, 27 Oct 2003 11:15:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFPI7069525 for ; Mon, 27 Oct 2003 11:15:25 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AECpm-0004Ni-Ps; Mon, 27 Oct 2003 20:15:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AECpk-0005yD-Mz; Mon, 27 Oct 2003 20:15:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECpj-00025D-00; Mon, 27 Oct 2003 20:15:19 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F919D54.7070306@isode.com> References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:15:19 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >>>>> In > >>>>> order to avoid noninteroperability due to differing normalizations, > >>>>> when a mechanism specifies that a string authentication identity or > >>>>> password used as input to a cryptographic function (or used for > >>>>> comparison) it SHOULD specify that the string first be prepared using > >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm > >>>>> [StringPrep]. > >>>> > The new text after that reads: > > There are three entities that has to deal with this issue: a client > (upon getting user input or retrieving a value from configuration), a server > (upon receiving the value from the client) and a utility that is able to > store > passwords/hashes in a database that can be later used by the server. > The preparation must be done by the client and the utility and may be > done by the > server. If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. I like Kurt's suggestion better: The mechanism must define where preparation is done. That way clients using mechanisms like PLAIN can leave as much work as possible to the server. >>> Alexey, the current text suggests that client (1) prep the >>> value before sending, the server then preps it (2) again >>> (before comparing it to the store value, which also should >>> be prep'ed (3) either before storing it or before each compare). >> >> Ok, I am with you now. >> >> IMHO, as a server writer, I would do (2) anyway. But of course this is >> my personal opinion. I see no reason to prepare a string which we know already has been prepared (if the client works correctly). I guess it doesn't hurt to allow that, but what you are saying is that if the client sends incorrect data (it doesn't prepare when it should do so), auth on your server would succeed anyway. Put that way, I'm not sure if that is a bug or a feature. BTW, the server can't do (2) with mechanisms like DIGEST-MD5, where it never sees the plain password from the client. I got that wrong too in my original message. >>> We should not suggest that mechanisms should do both (1) and >>> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >>> proper matching. >> >> IMHO, this is a responsibility of the client, Disagree. It's the responsibility of the mechanism defintion to say where it should happen. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:21:08 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL8I7069814 for ; Mon, 27 Oct 2003 11:21:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJL8U0069813 for ietf-sasl-bks; Mon, 27 Oct 2003 11:21:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL6I7069806 for ; Mon, 27 Oct 2003 11:21:07 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AECvJ-0004vJ-MX; Mon, 27 Oct 2003 20:21:05 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AECvG-0006ok-AO; Mon, 27 Oct 2003 20:21:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECvG-00025S-00; Mon, 27 Oct 2003 20:21:02 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F915345.8070201@isode.com> References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:21:02 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >>>Hallvard B Furuseth wrote: >>> >>>>>4.1. Authentication protocol exchange >>Anyway, I think I found the answer in section 6.1. The initial auth >>command from the client is not part of the exchange, but the optional >>"response" in the auth command is. >> > Sorry, this makes little sense to me. > Semantically the initial response *is* part of an authentication > exchange. That's what I wrote. >>>>>4.2. Authorization identities and proxy authentication >>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an authorization >>>>> identity over protocol is specified in each authentication mechanism >>>>> (with the authentication mechanism's blob being further >>>> ^^^^ >>>> >>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>like the dictionary says:-) >>>> >>>I've changed this to "data". >> >>I still don't know _which_ data you are talking about. >> > Data is defined (and specific to) by each SASL mechanism. Is the text in the ()'s just saying that the SASL mechanism restricts the data sent between client and server to more than just being random strings in the character encoding scheme? Well, of course. Why mention that at all? If not, I still don't understand what this () is saying. >>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>top. >>>> >>>I've added a sentence about this in the introduction section. >> >>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>2222" in the header sometime, though I don't remember where this is >>stated. >> > I think this is going to be added by a RFC editor. > > I couldn't find anything saying so. I did find rfc2223 (Instructions > to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks > you to insert. rfc2223 does say that the RFC Editor may make some > changes, but preferably as few as possible, and it doesn't mention > that one. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:23:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNJI7069893 for ; Mon, 27 Oct 2003 11:23:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJNIm9069892 for ietf-sasl-bks; Mon, 27 Oct 2003 11:23:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNHI7069885 for ; Mon, 27 Oct 2003 11:23:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECxQ-00059f-K2; Mon, 27 Oct 2003 20:23:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECxN-0004NX-58; Mon, 27 Oct 2003 20:23:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECxM-00025m-00; Mon, 27 Oct 2003 20:23:12 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3F8D34E4.4020607@isode.com> References: <3F8D34E4.4020607@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:23:12 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2222bis section 6.3 "Multiple authentications" says: >> >> If a security layer is in effect >> and a subsequent SASL negotiation selects a second security layer, >> then the second security layer replaces the first. If a security >> layer is in effect and a subsequent SASL negotiation selects no >> security layer, the original security layer must be removed. >> >>Exactly when is the old layer canceled? >> >>If an old layer is active and the client starts to negotiate a new >>layer, it may not know when to expect the response from the server. >>So the layer can't be canceled by starting a new negotiation. >> > No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully. OK. Please mention that explicitly. > Each profile document must document exactly when this takes place. 'this' = 'it completed successfully', I take it. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:25:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPCI7069974 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJPCP5069973 for ietf-sasl-bks; Mon, 27 Oct 2003 11:25:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPBI7069966 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AECzG-0005M0-Be; Mon, 27 Oct 2003 20:25:10 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AECzD-0004YS-Ja; Mon, 27 Oct 2003 20:25:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECzD-00025o-00; Mon, 27 Oct 2003 20:25:07 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token In-Reply-To: <3F8D308B.5050208@isode.com> References: <3F8D308B.5050208@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:25:07 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2831bis 2.1.1 "Step One" says: >> >> qop-options = "qop" "=" <"> qop-list <"> >> qop-list = 1#qop-value >> qop-value = "auth" | "auth-int" | "auth-conf" | >> token >> >>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>"auth", "auth-int" and "auth-conf", but not when it is . > > Token is specifically for future extensions, if you see a qop value you > don't recognize - you have to ignore it. > If you recognize nothing, you have to fail the authentication exchange. > > Do you want any clarifications on this to be added to the document. Not sure. I think it would be good to mention that 'token is for future extensions' somewhere. And perhaps that these extensions must define A2, since rfc2831bis does not. -- Hallvard From owner-ietf-sasl Mon Oct 27 11:49:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnGI7071153 for ; Mon, 27 Oct 2003 11:49:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJnGCK071152 for ietf-sasl-bks; Mon, 27 Oct 2003 11:49:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnFI7071147 for ; Mon, 27 Oct 2003 11:49:15 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1BDD1515EA; Mon, 27 Oct 2003 14:49:10 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 14:49:10 -0500 In-Reply-To: <3F919B07.6050909@isode.com> (Alexey Melnikov's message of "Sat, 18 Oct 2003 20:56:55 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> IMHO, as a server writer, I would do (2) anyway. But of Alexey> course this is my personal opinion. This needs to be left up to individual mechanisms. The server definitely should not do this. I can think of mechanisms where doing (2) will break signatures of data, etc. For plain, I would probably do all three as you suggest. From owner-ietf-sasl Mon Oct 27 12:02:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2dI7071665 for ; Mon, 27 Oct 2003 12:02:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK2deT071664 for ietf-sasl-bks; Mon, 27 Oct 2003 12:02:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2cI7071659 for ; Mon, 27 Oct 2003 12:02:38 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E4D781515EB; Mon, 27 Oct 2003 15:02:37 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 15:02:37 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 27 Oct 2003 20:21:02 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Alexey Melnikov writes: >> Hallvard B Furuseth wrote: >>> Alexey Melnikov writes: >>>> Hallvard B Furuseth wrote: >>>>>> 4.1. Authentication protocol exchange >>> Anyway, I think I found the answer in section 6.1. The >>> initial auth command from the client is not part of the >>> exchange, but the optional "response" in the auth command is. >>> >> Sorry, this makes little sense to me. Semantically the initial >> response *is* part of an authentication exchange. Hallvard> That's what I wrote. >>>>>> 4.2. Authorization identities and proxy authentication >>>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an >>>>>> authorization >>>>> identity over protocol is specified in each authentication >>>>>> mechanism >>>>> (with the authentication mechanism's blob being further >>>>> ^^^^ >>>>> >>>>> What's a blob? I don't think it's 'something ill-defined or >>>>> amorphous', like the dictionary says:-) >>>>> >>>> I've changed this to "data". >>> I still don't know _which_ data you are talking about. >>> >> Data is defined (and specific to) by each SASL mechanism. Hallvard> Is the text in the ()'s just saying that the SASL Hallvard> mechanism restricts the data sent between client and Hallvard> server to more than just being random strings in the Hallvard> character encoding scheme? Well, of course. Why Hallvard> mention that at all? If not, I still don't understand Hallvard> what this () is saying. Because you want to make it clear to application protocol designers and SASL library implementers that mechanisms will be expected to restrict this data. From owner-ietf-sasl Mon Oct 27 12:08:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8dI7071881 for ; Mon, 27 Oct 2003 12:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK8dnl071880 for ietf-sasl-bks; Mon, 27 Oct 2003 12:08:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8cI7071871 for ; Mon, 27 Oct 2003 12:08:38 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RK7xxA009860; Mon, 27 Oct 2003 12:07:59 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9RK7v58012282; Mon, 27 Oct 2003 13:07:58 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9RK3qQx003840; Mon, 27 Oct 2003 12:03:52 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9RK3oR7003839; Mon, 27 Oct 2003 12:03:50 -0800 (PST) Date: Mon, 27 Oct 2003 12:03:50 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org Cc: nfsv4@ietf.org Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt] Message-ID: <20031027200350.GI24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org, nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Followups-To: nfsv4@ietf.org Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies for the cross-post; followups should NOT be cross-posted this widely. Please Cc ONLY the appropriate WG mailing list(s) on any replies. Since I am not subscribed to all of the relevant WGs' mailing lists, please Cc me in all replies.] The NFSv4 WG I-D on channel bindings needs review from several IETF WGs. This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02). We would appreciate feedback from the Cc'ed WGs on several areas as requested below. Please cc the appropriate WG lists only in your replies. The I-D announcement is included below, including the I-D Abstract. Thanks, Nico Review requests: - From all the cc'ed WGs, the security community in general and the [concluded] CAT WG mailing list: o Please review the generic definition of "channel bindings" in this I-D and the concept of "channel bindings" in general. (Use the CAT WG list and/or the NFSv4 WG list.) - From the IPSEC WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. o Please review the IPsec channel bindings construction. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPSP WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPS WG: o Please consider the channel bindings concept as a general solution to the problems with the iSCSI approach to security ("authenticate at iSCSI layer with x, y or z authentication technology, but delegate session integrity/confidentiality protection to IPsec"). See the introduction (section 1) of this I-D for a description of the problem with the iSCSI approach to security. (I realize that I'm late to the iSCSI party - my goal is not to affect the progression of the iSCSI I-Ds to Proposed Standard and publication as RFCs, far from it.) (Use the IPS WG list.) - From the TLS WG: o Please review the construction of channel bindings to TLS channels given in this I-D. (Use the TLS WG list.) - From the SECSH WG: o Please review the construction of channel bindings to SSHv2 channels given in this I-D. (Use the SECSH WG list.) - From the KRB WG: o Please review sections 3.3 and 4.5 of this I-D. (Use the KRB WG list.) - From the SASL WG: o Please review section 3.2 of this I-D. (Use the SASL WG list.) ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 24 Oct 2003 10:50:50 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt To: IETF-Announce: ; Cc: nfsv4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : On the Use of Channel Bindings to Secure Channels Author(s) : N. Williams Filename : draft-ietf-nfsv4-channel-bindings-00.txt Pages : 14 Date : 2003-10-23 This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-channel-bindings-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- From owner-ietf-sasl Mon Oct 27 13:17:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHXI7074996 for ; Mon, 27 Oct 2003 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLHX22074995 for ietf-sasl-bks; Mon, 27 Oct 2003 13:17:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHRI7074986 for ; Mon, 27 Oct 2003 13:17:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BFF3F1515E8; Mon, 27 Oct 2003 16:17:27 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> <3F867FC1.90704@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 16:17:27 -0500 In-Reply-To: <3F867FC1.90704@isode.com> (Alexey Melnikov's message of "Fri, 10 Oct 2003 10:45:37 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: >> I wonder if it might be better to not to change the protocol >> but, instead, just document the security consideration. >> Alexey> I would like to allow new protocols to allow to deinstall Alexey> the security layer when none is negotiated. RFC 2222 Alexey> prohibits this. Why do you want this? From owner-ietf-sasl Tue Oct 28 12:31:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVXI7003412 for ; Tue, 28 Oct 2003 12:31:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKVXj2003411 for ietf-sasl-bks; Tue, 28 Oct 2003 12:31:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVWI7003405 for ; Tue, 28 Oct 2003 12:31:32 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A83111515E8; Tue, 28 Oct 2003 15:31:33 -0500 (EST) To: Greg Hudson Cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Sam Hartman Date: Tue, 28 Oct 2003 15:31:33 -0500 In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> (Greg Hudson's message of "Mon, 13 Oct 2003 13:19:19 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Greg" == Greg Hudson writes: Greg> * It introduces the concepts of realms, subsequent Greg> authentication, and authorization IDs, none of which seem to Greg> be important functionality for a generic shared-secret Greg> authentication scheme, and all of which could (I think) be Greg> handled out of band. Fortunately, it's not too difficult to Greg> avoid supporting those features. I think the only point you raise that I disagree with is the idea that authorization IDs are not important. I can understand why an implementation might not want to use them, but I believe they are important for protocols to support and are something you will tend to want to add over time to an implementation. From owner-ietf-sasl Tue Oct 28 12:45:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjtI7004136 for ; Tue, 28 Oct 2003 12:45:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjtGB004135 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjrI7004130 for ; Tue, 28 Oct 2003 12:45:54 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25736; Tue, 28 Oct 2003 15:45:43 -0500 (EST) Message-Id: <200310282045.PAA25736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt Date: Tue, 28 Oct 2003 15:45:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-03.txt Pages : 11 Date : 2003-10-28 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 12:45:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjlI7004123 for ; Tue, 28 Oct 2003 12:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjlS8004122 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjjI7004115 for ; Tue, 28 Oct 2003 12:45:46 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25711; Tue, 28 Oct 2003 15:45:36 -0500 (EST) Message-Id: <200310282045.PAA25711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-04.txt Date: Tue, 28 Oct 2003 15:45:35 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-04.txt Pages : 6 Date : 2003-10-28 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 12:46:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk5I7004151 for ; Tue, 28 Oct 2003 12:46:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKk5Ip004150 for ietf-sasl-bks; Tue, 28 Oct 2003 12:46:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk2I7004144 for ; Tue, 28 Oct 2003 12:46:02 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25756; Tue, 28 Oct 2003 15:45:52 -0500 (EST) Message-Id: <200310282045.PAA25756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-03.txt Date: Tue, 28 Oct 2003 15:45:51 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-03.txt Pages : 9 Date : 2003-10-28 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Oct 28 13:18:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI7I7005384 for ; Tue, 28 Oct 2003 13:18:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLI6FW005383 for ietf-sasl-bks; Tue, 28 Oct 2003 13:18:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI5I7005378 for ; Tue, 28 Oct 2003 13:18:06 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLI6s9014556; Tue, 28 Oct 2003 16:18:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLDWal015702; Tue, 28 Oct 2003 16:13:32 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9SLDVEi010084; Tue, 28 Oct 2003 16:13:31 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9SLDTB9027808; Tue, 28 Oct 2003 16:13:29 -0500 Subject: Re: Some implementor's notes From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067375609.27762.26.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 28 Oct 2003 16:13:29 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > I think the only point you raise that I disagree with is the idea that > authorization IDs are not important. And yet, to the best of my knowledge, they are not introduced by any mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, but they each have different passwords, so they aren't analagous to DIGEST-MD5 authzids.) They are trivial to support by authenticating and then transmitting the desired authzid. So they should either be part of the protocol or part of the SASL framework, but certainly not part of SASL mechanisms. From owner-ietf-sasl Tue Oct 28 13:20:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKhI7005489 for ; Tue, 28 Oct 2003 13:20:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLKhWu005488 for ietf-sasl-bks; Tue, 28 Oct 2003 13:20:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKfI7005483 for ; Tue, 28 Oct 2003 13:20:42 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 28 Oct 2003 21:21:06 +0000 Message-ID: <3F9EDDAB.2080804@isode.com> Date: Tue, 28 Oct 2003 21:20:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt References: <200310282045.PAA25736@ietf.org> In-Reply-To: <200310282045.PAA25736@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) > Author(s) : A. Melnikov > Filename : draft-ietf-sasl-rfc2222bis-03.txt > Pages : 11 > Date : 2003-10-28 > > The updated draft deals with most (but not all) issues raised during WG Last Call. There are some mostly editorial issues left. There was a recent discussion on IMAP mailing list about adding examples to show how to encode initial response when it is/is not supported by the protocol. I will add this in the next revision. I am not going to attend IETF in Minneapolis. What is the planned agenda for the SASL meeting in Minneapolis? Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ From owner-ietf-sasl Tue Oct 28 13:51:12 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLpCI7006906 for ; Tue, 28 Oct 2003 13:51:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLpBYq006905 for ietf-sasl-bks; Tue, 28 Oct 2003 13:51:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SLpAI7006899 for ; Tue, 28 Oct 2003 13:51:11 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa04663; 28 Oct 2003 16:50 EST Date: Tue, 28 Oct 2003 16:50:44 -0500 From: Jeffrey Hutzelman To: Greg Hudson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <1116100000.1067377844@minbar.fac.cs.cmu.edu> In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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, October 28, 2003 16:13:29 -0500 Greg Hudson wrote: > > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: >> I think the only point you raise that I disagree with is the idea that >> authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, > but they each have different passwords, so they aren't analagous to > DIGEST-MD5 authzids.) They are trivial to support by authenticating and > then transmitting the desired authzid. So they should either be part of > the protocol or part of the SASL framework, but certainly not part of > SASL mechanisms. They're not introduced by this mechanism, either. Authorization identities _are_ part of the SASL framework -- a client may optionally specify the authorization identity he wishes to assume, independent of the authentication identity provided by the mechanism. It is the responsibility of the mechanism to transport the requested authzid, if there is one. -- Jeff From owner-ietf-sasl Tue Oct 28 13:48:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmnI7006761 for ; Tue, 28 Oct 2003 13:48:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLmmeA006760 for ietf-sasl-bks; Tue, 28 Oct 2003 13:48:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmlI7006754 for ; Tue, 28 Oct 2003 13:48:47 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9SLmmk4025751; Tue, 28 Oct 2003 16:48:48 -0500 Date: Tue, 28 Oct 2003 16:48:48 -0500 (EST) From: Rob Siemborski To: Greg Hudson cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Some implementor's notes In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> Message-ID: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> 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: On Tue, 28 Oct 2003, Greg Hudson wrote: > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > > I think the only point you raise that I disagree with is the idea that > > authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. In addition to DIGEST-MD5, the PLAIN, KERBEROS_V4, GSSAPI, SRP, and OTP mechanisms all support authorization identifiers. This certainly isn't something completely new introduced by DIGEST-MD5. > They are trivial to support by authenticating and then transmitting the > desired authzid. So they should either be part of the protocol or part > of the SASL framework, but certainly not part of SASL mechanisms. I admit that hindsight reveals that it would be nice for SASL to be able to support authorization ids as part of the framework -- it would solve the inconsistency introduced by CRAM-MD5. I don't think we really want to do this at the application layer either, since that repeats this work for every SASL application (having application-specific constraints on the authorization ID, however, would be fine). However, I don't think we can abandon the current deployed infrastructure to fix the SASL framework to allow this at this point. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 29 10:44:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi6kT035183 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TIi69Z035182 for ietf-sasl-bks; Wed, 29 Oct 2003 10:44:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi5kT035177 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F80E1515E8; Wed, 29 Oct 2003 13:44:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Agenda items to discuss Message-Id: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Date: Wed, 29 Oct 2003 13:44:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a lot of discussion on the list since the last IETF and I'm curious which issues actually need meeting time. I'd appreciate it if people could suggest issues that still seem to be open. Thing I think may be open or need discussion are: * Initial server challenges especially as they interact with SMTP * Security layer replacement in the base SASL spec * Authorization ID text (data vs blob, confusion about restriction, etc) * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want to develop guidance for protocol designers on this issue? I think most of the other changes that have been brought forward have been resolved; please correct me if I'm wrong. I think Greg's comments on implementing SASL have not suggested any specific changes to documents that need discussion. There's also been a lot of IDN related discussion in the Kerberos working group. So far, I don't think any of that discussion affects saslprep. If any of those issues do end up affecting saslprep, we may at least want to be aware of them. I'll review those discussion within the next week. From owner-ietf-sasl Wed Oct 29 13:58:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwJkT046847 for ; Wed, 29 Oct 2003 13:58:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLwJ3q046846 for ietf-sasl-bks; Wed, 29 Oct 2003 13:58:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwHkT046840 for ; Wed, 29 Oct 2003 13:58:18 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLtZD6012330; Wed, 29 Oct 2003 16:58:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLphSA015781; Wed, 29 Oct 2003 16:51:44 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9TLphMU012960; Wed, 29 Oct 2003 16:51:43 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9TLpfCa028654; Wed, 29 Oct 2003 16:51:41 -0500 Subject: Re: Agenda items to discuss From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067464301.27762.103.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 29 Oct 2003 16:51:41 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-10-29 at 13:44, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I won't be at the meeting, but I'd like to weigh in with the opinion that we shouldn't make it any harder for implementations to do dual encryption of data for defense-in-depth. It may seem redundant and expensive to encrypt or sign twice (and it's certainly fair for an implementation to avoid using a security layer if it's running over TLS), but it's not completely redundant; the keys used for one security layer may be compromisable under different assumptions than the keys used for another. For example: I make a TLS connection to an MIT server and then SASL-authenticate via GSSAPI. Unbeknownst to me, a CA trusted by my client has issued a bogus X.509 certificate for MIT to an attacker. The attacker intercepts my connection, initiates its own connection to the real MIT server, and passes through my communications so that GSSAPI authentication succeeds. If my client insists on using a SASL security layer, the attacker will not be able to modify (or perhaps even read) my communications despite having compromised TLS. I'm not sure if anyone was seriously considering disallowing dual security layers, but RFC 3080 section 4.1 does so, so it seemed worth heading off. > I think most of the other changes that have been brought forward have > been resolved; please correct me if I'm wrong. I think Greg's > comments on implementing SASL have not suggested any specific changes > to documents that need discussion. Correct; I hope my comments will be kept in mind for future work, but they don't have any ramifications for current documents. (And, apologies for the misconception about authzids. I still feel they should have appeared within the framework and not within mechanisms, but I was wrong to assume that they were specific to DIGEST-MD5.) From owner-ietf-sasl Wed Oct 29 14:55:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtKkT049836 for ; Wed, 29 Oct 2003 14:55:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMtKOS049835 for ietf-sasl-bks; Wed, 29 Oct 2003 14:55:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtJkT049828 for ; Wed, 29 Oct 2003 14:55:19 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TMtGxA014090; Wed, 29 Oct 2003 14:55:16 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TMtG58017978; Wed, 29 Oct 2003 15:55:16 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TMpAQx010060; Wed, 29 Oct 2003 14:51:10 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TMp9Jc010059; Wed, 29 Oct 2003 14:51:09 -0800 (PST) Date: Wed, 29 Oct 2003 14:51:09 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031029225109.GB24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I think this should be discussed. I think the guidance we want to give is: don't delegate session protection from one layer to another without confirming that the end-points at both layers are the same. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt It would be nice if SASL had a channel bindings facility. Such a facility could be added or applications could be encouraged to exchange channel bindings data integrity protected at the SASL layer. Can GSS-API channel bindings facility be used when using the GSS-* SASL mechanisms? Cheers, Nico -- From owner-ietf-sasl Wed Oct 29 15:44:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiakT052523 for ; Wed, 29 Oct 2003 15:44:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNiaKH052522 for ietf-sasl-bks; Wed, 29 Oct 2003 15:44:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiYkT052517 for ; Wed, 29 Oct 2003 15:44:35 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TNiUY9001498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Oct 2003 18:44:33 -0500 (EST) Message-ID: <3FA050DA.9000702@columbia.edu> Date: Wed, 29 Oct 2003 18:44:26 -0500 From: "Jeffrey Altman [Kermit Project Volunteer]" Reply-To: ietf-sasl@imc.org Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > > >>* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >>to develop guidance for protocol designers on this issue? >> >> > >I think this should be discussed. > >I think the guidance we want to give is: don't delegate session >protection from one layer to another without confirming that the >end-points at both layers are the same. > >See: > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > > >It would be nice if SASL had a channel bindings facility. Such a >facility could be added or applications could be encouraged to exchange >channel bindings data integrity protected at the SASL layer. > >Can GSS-API channel bindings facility be used when using the GSS-* SASL >mechanisms? > >Cheers, > >Nico > > I second this sentiment. We need to provide advice on how the underlying session security can be validated as part of the SASL authentication OR after the authentication by exchanging messages using the SASL Security Layer which can be then be turned off if validation was successful. Jeffrey Altman From owner-ietf-sasl Wed Oct 29 15:48:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052767 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNmMVb052766 for ietf-sasl-bks; Wed, 29 Oct 2003 15:48:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052738 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TNmJxA004621; Wed, 29 Oct 2003 15:48:19 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TNmI2o023242; Wed, 29 Oct 2003 16:48:18 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TNiCQx022365; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TNiCMe022364; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Date: Wed, 29 Oct 2003 15:44:12 -0800 From: Nicolas Williams To: ietf-sasl@imc.org Cc: Sam Hartman Subject: Re: Agenda items to discuss Message-ID: <20031029234412.GF24528@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org, Sam Hartman References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> <3FA050DA.9000702@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA050DA.9000702@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 06:44:26PM -0500, Jeffrey Altman [Kermit Project Volunteer] wrote: > Nicolas Williams wrote: > [...] > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > [...] > I second this sentiment. We need to provide advice on how the > underlying session security can be validated as part of the SASL > authentication OR after the authentication by exchanging messages using > the SASL Security Layer which can be then be turned off if validation > was successful. Note that I did post a request for this and other WGs to review the channel bindings draft. There is a section in that I-D about SASL, BTW. Cheers, Nico -- From owner-ietf-sasl Wed Oct 29 16:05:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05DkT053844 for ; Wed, 29 Oct 2003 16:05:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U05DhD053842 for ietf-sasl-bks; Wed, 29 Oct 2003 16:05:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05BkT053836 for ; Wed, 29 Oct 2003 16:05:11 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9U05CE7016851; Wed, 29 Oct 2003 19:05:12 -0500 Date: Wed, 29 Oct 2003 19:05:11 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org cc: mrc@CAC.Washington.EDU Subject: Mark Crispin's comments on draft-ietf-sasl-plain-03.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: Mark had a few comments on the PLAIN draft, mostly centered around the issue of the initial response examples. I tend to agree with his assessments. I'll note (as Kurt did), that this document has already been through the WG last call. a) ACAP is probably not the best choice of protocol for the example, since it is not in wide use. A protocol such as SMTP is probably more appropriate (especially given the trouble we've seen with SMTP implementations getting initial response handling correct). SMTP has the added advantage of having 3 digit response codes that in other have optional text -- though that is not the case in the SASL challenges. b) An example demonstrating plain without using the initial response argument on a protocol that supports it. This would again help to address the implementation problems with the optional initial client send. There are examples in draft-siemborski-rfc2554bis-00.txt (using SMTP) that satisfy this, and could be used. One thing that may also help is to place reminders in mechanism (and protocol) documents that a correct implementation of SASL for a given protocol requires an understanding of the protocol profile, the SASL framework, and the mechanism, and that reading all three documents is necessary to get it right. Of course, in a perfect world, normative references would be enough, but experience seems to be showing this not to be the case. (I'd also like to encourage people again to read over and comment more generally on draft-siemborski-rfc2554bis-00.txt and draft-siemborski-rfc1734bis-00.txt). We're also both planning on being at the SASL WG meeting in Minneapolis, and can discuss this further then. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Oct 29 23:11:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BikT001883 for ; Wed, 29 Oct 2003 23:11:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7BiDN001882 for ietf-sasl-bks; Wed, 29 Oct 2003 23:11:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BhkT001870 for ; Wed, 29 Oct 2003 23:11:43 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U7Bblg099887; Thu, 30 Oct 2003 07:11:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 23:10:51 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: ietf-sasl@imc.org, mrc@CAC.Washington.EDU In-Reply-To: References: 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: At 04:05 PM 10/29/2003, Rob Siemborski wrote: >Mark had a few comments on the PLAIN draft, mostly centered around the >issue of the initial response examples. I tend to agree with his >assessments. I'll note (as Kurt did), that this document has already been >through the WG last call. > >a) ACAP is probably not the best choice of protocol for the example, since >it is not in wide use. A protocol such as SMTP is probably more >appropriate (especially given the trouble we've seen with SMTP >implementations getting initial response handling correct). SMTP has the >added advantage of having 3 digit response codes that in other have >optional text -- though that is not the case in the SASL challenges. I think ACAP is a good choice for illustration of SASL/PLAIN mechanism. No base64, meaningful protocol tokens (instead of numeric codes), and a straightforward/simple syntax. I doubt developers needs to consult the ACAP specific to understand the example. The trouble we've seen with SMTP implementations, I think, make SMTP a particular bad choice for use here. >b) An example demonstrating plain without using the initial response >argument on a protocol that supports it. This would again help to address >the implementation problems with the optional initial client send. I have no objection to adding another example. I'll offer specific text for the WG to consider in a subsequent post. >One thing that may also help is to place reminders in mechanism (and >protocol) documents that a correct implementation of SASL for a given >protocol requires an understanding of the protocol profile, the SASL >framework, and the mechanism, and that reading all three documents is >necessary to get it right. I'll stay on the fence on this one, so I suggest that someone who currently supports adding such offer specific text for WG consideration. Kurt From owner-ietf-sasl Wed Oct 29 23:17:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HjkT004053 for ; Wed, 29 Oct 2003 23:17:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7Hj88004052 for ietf-sasl-bks; Wed, 29 Oct 2003 23:17:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HikT004044 for ; Wed, 29 Oct 2003 23:17:44 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7HeMk021511; Wed, 29 Oct 2003 23:17:45 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7Hemo023689; Wed, 29 Oct 2003 23:17:40 -0800 Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: > I think ACAP is a good choice for illustration of SASL/PLAIN > mechanism. No base64, meaningful protocol tokens (instead of > numeric codes), and a straightforward/simple syntax. It is precisely because ACAP does not use BASE64 and does not use numeric code that makes it unsuitable. IMAP is also unsuitable. > The trouble we've seen with SMTP implementations, I think, make > SMTP a particular bad choice for use here. The trouble with SMTP implementation is the *exact* reason why SMTP examples are needed. You don't need examples for things that people will get right. You need examples for things that people get wrong! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 01:12:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CkkT040821 for ; Thu, 30 Oct 2003 01:12:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U9CktC040819 for ietf-sasl-bks; Thu, 30 Oct 2003 01:12:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CjkT040809 for ; Thu, 30 Oct 2003 01:12:45 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U9Cglg001249; Thu, 30 Oct 2003 09:12:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 01:11:56 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: At 11:17 PM 10/29/2003, Mark Crispin wrote: >On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> I think ACAP is a good choice for illustration of SASL/PLAIN >> mechanism. No base64, meaningful protocol tokens (instead of >> numeric codes), and a straightforward/simple syntax. > >It is precisely because ACAP does not use BASE64 and does not use numeric >code that makes it unsuitable. IMAP is also unsuitable. The sole purpose of the example is to illustrate the syntax and semantics described in Section 2 and this purpose is, in my opinion, best served by avoiding protocol encodings which obfuscate the value of the message production. >> The trouble we've seen with SMTP implementations, I think, make >> SMTP a particular bad choice for use here. > >The trouble with SMTP implementation is the *exact* reason why SMTP >examples are needed. You don't need examples for things that people will >get right. You need examples for things that people get wrong! Some folks have problems getting LDAP/SASL right, so, by your argument, we should include LDAP-based examples in the PLAIN document. The trouble with SMTP implementations of SMTP's SASL profile is more appropriately addressed by revising the SMTP specification. Attempting to address these problems in the PLAIN specification might lead to even more confusion in the SMTP community. Kurt From owner-ietf-sasl Thu Oct 30 06:53:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr9kT065699 for ; Thu, 30 Oct 2003 06:53:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UEr9iQ065698 for ietf-sasl-bks; Thu, 30 Oct 2003 06:53:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr4kT065689 for ; Thu, 30 Oct 2003 06:53:07 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UEqq3w031544; Thu, 30 Oct 2003 09:52:52 -0500 (EST) Message-ID: <3FA12679.3070409@oceana.com> Date: Thu, 30 Oct 2003 09:55:53 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > At 11:17 PM 10/29/2003, Mark Crispin wrote: > >>On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> >>>I think ACAP is a good choice for illustration of SASL/PLAIN >>>mechanism. No base64, meaningful protocol tokens (instead of >>>numeric codes), and a straightforward/simple syntax. >> >>It is precisely because ACAP does not use BASE64 and does not use numeric >>code that makes it unsuitable. IMAP is also unsuitable. > > > The sole purpose of the example is to illustrate the syntax and > semantics described in Section 2 and this purpose is, in my opinion, > best served by avoiding protocol encodings which obfuscate the value > of the message production. I tend to agree. The mechanism docs should only have to worry about the order and contents of the exchanges, not how they are encoded or how the client-first and server-last issues are handled. >>>The trouble we've seen with SMTP implementations, I think, make >>>SMTP a particular bad choice for use here. >> >>The trouble with SMTP implementation is the *exact* reason why SMTP >>examples are needed. You don't need examples for things that people will >>get right. You need examples for things that people get wrong! > > > Some folks have problems getting LDAP/SASL right, so, by your argument, > we should include LDAP-based examples in the PLAIN document. > > The trouble with SMTP implementations of SMTP's SASL profile is more > appropriately addressed by revising the SMTP specification. Attempting > to address these problems in the PLAIN specification might lead to > even more confusion in the SMTP community. I understand why Mark is proposing more examples (to prevent large deployment of incorrect implementations that we all have to deal with), but I have to agree with Kurt that the protocol profile is where comprehensive examples belong. RFC 2222[bis] was written so that the protocol profiles and mechanism specifications are orthogonal. In fact, the PLAIN doc shouldn't have to worry about whether particular protocols support an initial response or not. RFC 2222bis describes how to handle this, and the protocol profile should describe how to implement it. No matter how you slice it, any good/responsible implementer is going to *have* to read three docs. I think that encouraging/enforcing this point is more important than cross-pollinating the docs with the same info. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 30 07:48:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmUkT068901 for ; Thu, 30 Oct 2003 07:48:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UFmUTg068900 for ietf-sasl-bks; Thu, 30 Oct 2003 07:48:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmTkT068893 for ; Thu, 30 Oct 2003 07:48:29 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRmw032022; Thu, 30 Oct 2003 07:48:27 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRtS032744; Thu, 30 Oct 2003 07:48:27 -0800 Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <3FA12679.3070409@oceana.com> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: On Thu, 30 Oct 2003, Ken Murchison wrote: > No matter how you slice it, any good/responsible implementer is going to > *have* to read three docs. I think that encouraging/enforcing this > point is more important than cross-pollinating the docs with the same info. Unfortunately, the "good/responsible implementors" do not include the authors of SMTP SASL for qmail, Microsoft Exchange, or for one of China's main SMTP servers (smtp.163.net). People cut corners, skip documents, and make assumptions through empirical tests with existing implementation. I wish that the world was not this way. It is. For people with that mindset, the only thing that you need the SMTP SASL document for is to learn the response codes. Nothing else needs to be read. They don't read 2222 either. "It works with Netscape and Outlook" is their rallying call. I am not of that mindset, but I have spent many weary hours convincing those who have that mindset that their software is broken. Clarifying examples are always good. I understand why you resist examples; I underwent that myself with the IMAP specification. The IMAP specification had to grow enormously to accomodate all the examples that people insisted upon adding. But even I have to acknowledge that the result was better than what was before. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 08:45:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjskT071831 for ; Thu, 30 Oct 2003 08:45:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGjrQs071830 for ietf-sasl-bks; Thu, 30 Oct 2003 08:45:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjqkT071818 for ; Thu, 30 Oct 2003 08:45:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 80E071515E8; Thu, 30 Oct 2003 11:45:55 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> From: Sam Hartman Date: Thu, 30 Oct 2003 11:45:55 -0500 In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> (Nicolas Williams's message of "Wed, 29 Oct 2003 14:51:09 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman Nicolas> wrote: >> * There was some discussion of multiple layers of encryption >> (TLS vs security layers) in XMPP; do we want to develop >> guidance for protocol designers on this issue? Nicolas> I think this should be discussed. Nicolas> I think the guidance we want to give is: don't delegate Nicolas> session protection from one layer to another without Nicolas> confirming that the end-points at both layers are the Nicolas> same. This approach is out of scope for the SASL working group as it cannot be implemented within the current charter. If you want to discuss the approach on the list, that's fine. However I don't think modifying SASL to gain channel bindings is appropriate for meeting time at the IETF. From owner-ietf-sasl Thu Oct 30 09:00:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0FkT072715 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UH0FcR072714 for ietf-sasl-bks; Thu, 30 Oct 2003 09:00:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0EkT072707 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9UGqKEG032595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 11:52:23 -0500 Date: Thu, 30 Oct 2003 12:00:16 -0500 From: Cyrus Daboo To: Ken Murchison , "Kurt D. Zeilenga" cc: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Message-ID: <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <3FA12679.3070409@oceana.com> References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 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: Hi Ken, --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison wrote: | No matter how you slice it, any good/responsible implementer is going to | *have* to read three docs. Its not just three, in fact it is one (SASL), + one per-mechanism, + one per-protocol. If you're writing an email client, chances are that's going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). Each of those is slightly different in some way. Multiply that by all the mechanisms... | I think that encouraging/enforcing this point | is more important than cross-pollinating the docs with the same info. Again I would like to suggest some kind of "implementer's guide" document for SASL that would provide comprehensive examples for each type of protocol and each mechanism, as well as a list of the common implementation errors that have cropped up. That's not meant to replace having to read and understand each of the other documents, but can be used more as a starting point for multiple protocol implementations etc. I would also like to suggest the possibility of an interop event once the new docs are out so that we can pin down problems related to the new i18n stuff, as well as weed out existing problems. The feedback from that could be used in the implementer's guide too. -- Cyrus Daboo From owner-ietf-sasl Thu Oct 30 09:10:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAokT073611 for ; Thu, 30 Oct 2003 09:10:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHAoGk073610 for ietf-sasl-bks; Thu, 30 Oct 2003 09:10:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAnkT073597 for ; Thu, 30 Oct 2003 09:10:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 30 Oct 2003 17:11:11 +0000 Message-ID: <3FA1460D.6070108@isode.com> Date: Thu, 30 Oct 2003 17:10:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Ken Murchison , "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >Clarifying examples are always good. I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. > Instead of modifying PLAIN, I would rather recommend adding more examples to RFC2222bis or create a new draft "SASL Implementation Considerations" which contains list of common mistakes and compares different profiles. Alexey From owner-ietf-sasl Thu Oct 30 09:49:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075968 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHn5jA075967 for ietf-sasl-bks; Thu, 30 Oct 2003 09:49:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075959 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9UHn1xA026420; Thu, 30 Oct 2003 09:49:01 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9UHn058006952; Thu, 30 Oct 2003 10:49:01 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9UHisQx023663; Thu, 30 Oct 2003 09:44:54 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9UHirAC023662; Thu, 30 Oct 2003 09:44:53 -0800 (PST) Date: Thu, 30 Oct 2003 09:44:53 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031030174453.GI24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 30, 2003 at 11:45:55AM -0500, Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman > Nicolas> wrote: > >> * There was some discussion of multiple layers of encryption > >> (TLS vs security layers) in XMPP; do we want to develop > >> guidance for protocol designers on this issue? > > Nicolas> I think this should be discussed. > > Nicolas> I think the guidance we want to give is: don't delegate > Nicolas> session protection from one layer to another without > Nicolas> confirming that the end-points at both layers are the > Nicolas> same. > Sam> This approach is out of scope for the SASL working group as it Sam> cannot be implemented within the current charter. If you want to Sam> discuss the approach on the list, that's fine. However I don't Sam> think modifying SASL to gain channel bindings is appropriate for Sam> meeting time at the IETF. I don't see how the text from me that you quote could possibly be out of scope for this WG - that text calls for "guidance" - security considerations text. The following text from me which you didn't quote does propose two things, one of which may well be out of scope for the WG - which is fine by me, as long as guidance is given: Nico> It would be nice if SASL had a channel bindings facility. Such a Nico> facility could be added or applications could be encouraged to Nico> exchange channel bindings data integrity protected at the SASL Nico> layer. I can see that adding a channel bindings facility to SASL may be out of scope for this WG. That said, you could argue that the channel bindings I-D itself provides, or should provide, sufficient guidance for developers of SASL application protocols. If so, please review the text in section 3.2 of draft-ietf-nfsv4-channel-bindings-00.txt. Thanks, Nico -- From owner-ietf-sasl Thu Oct 30 09:44:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi5kT075669 for ; Thu, 30 Oct 2003 09:44:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHi56P075668 for ietf-sasl-bks; Thu, 30 Oct 2003 09:44:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi4kT075662 for ; Thu, 30 Oct 2003 09:44:04 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9UHi2lg005675; Thu, 30 Oct 2003 17:44:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 09:43:15 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: At 07:48 AM 10/30/2003, Mark Crispin wrote: >People cut corners, skip documents, and make assumptions through empirical >tests with existing implementation. I wish that the world was not this >way. It is. > >For people with that mindset, the only thing that you need the SMTP SASL >document for is to learn the response codes. Nothing else needs to be >read. They don't read 2222 either. "It works with Netscape and Outlook" >is their rallying call. If they don't read the SASL specification, then any wouldn't read any examples we'd place there. I also note that examples are informative in nature. It should be possible to independently develop interoperable implementations without reading any example. >Clarifying examples are always good. If placed in the appropriate document and don't get in the way of the definitive specification, I would accept that non-redundant clarifying examples are generally good thing. >I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. I think we're resisting attempts to add examples intended to clarify aspects of protocol which are not specified in this document. Clarifying the SMTP, LDAP, IMAP, and other application level protocol specifications is beyond the scope of this document. Kurt From owner-ietf-sasl Thu Oct 30 09:36:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHaekT075028 for ; Thu, 30 Oct 2003 09:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHaePV075023 for ietf-sasl-bks; Thu, 30 Oct 2003 09:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHadkT074955 for ; Thu, 30 Oct 2003 09:36:39 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UHaV3w002180; Thu, 30 Oct 2003 12:36:31 -0500 (EST) Message-ID: <3FA14CD4.6020806@oceana.com> Date: Thu, 30 Oct 2003 12:39:32 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <2147483647.1067515216@[10.0.1.8]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Ken, > > --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison > wrote: > > | No matter how you slice it, any good/responsible implementer is going to > | *have* to read three docs. > > Its not just three, in fact it is one (SASL), + one per-mechanism, + one > per-protocol. If you're writing an email client, chances are that's Right. I was just looking at the SMTP + PLAIN scenario. > going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case > we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). > Each of those is slightly different in some way. Multiply that by all > the mechanisms... > > | I think that encouraging/enforcing this point > | is more important than cross-pollinating the docs with the same info. > > Again I would like to suggest some kind of "implementer's guide" > document for SASL that would provide comprehensive examples for each > type of protocol and each mechanism, as well as a list of the common > implementation errors that have cropped up. That's not meant to replace > having to read and understand each of the other documents, but can be > used more as a starting point for multiple protocol implementations etc. I think this is an excellent idea. I might even be able to volunteer to author or co-author such a document. > I would also like to suggest the possibility of an interop event once > the new docs are out so that we can pin down problems related to the new > i18n stuff, as well as weed out existing problems. The feedback from > that could be used in the implementer's guide too. Another good idea. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Oct 30 10:39:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdakT079630 for ; Thu, 30 Oct 2003 10:39:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIdav6079629 for ietf-sasl-bks; Thu, 30 Oct 2003 10:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdZkT079621 for ; Thu, 30 Oct 2003 10:39:35 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTaZ032355; Thu, 30 Oct 2003 10:39:34 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTEf008294; Thu, 30 Oct 2003 10:39:29 -0800 Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> 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: On Thu, 30 Oct 2003, Kurt D. Zeilenga wrote: > If they don't read the SASL specification, then any wouldn't read any > examples we'd place there. Exactly. That's why it has to be in all the relevant documents, in the hope that the implementor will see the example in the document he chooses to read. > I also note that examples are informative > in nature. It should be possible to independently develop interoperable > implementations without reading any example. I wish that too; but it is unrealistic. > I think we're resisting attempts to add examples intended to clarify > aspects of protocol which are not specified in this document. Clarifying > the SMTP, LDAP, IMAP, and other application level protocol specifications > is beyond the scope of this document. PLAIN is a mechanism which can operate in one of two ways, depending upon whether or not the client supplies initial data. This applies to all application protocols that use SASL. Therefore, this is within the scope of PLAIN. The choice of SMTP instead of ACAP is defensible by the fact that there will be many more SMTP implementations than ACAP implementations. Also, SMTP style interaction is much more typical of Internet protocols than ACAP (or POP3 or IMAP). NNTP and FTP are other examples of such protocols that use SASL now (or are likely to in the future). The fact that a server needs to send something like "334 " (note the trailing space) and nothing else is non-intuitive and surprising. It triggers a "that can't be right" feeling. Therefore, there needs to be explicit examples that say, "yes, it is right". No matter how redundant an example may seem to be, if it prevents a bad implementation then less harm is done by having the example in the document. I regularly deal with individuals who insist that because explicit text isn't in one particular RFC, the associated requirement therefore does not exist -- no matter how many normative documents say otherwise! This is why RFCs 2821 and 2822 spend a considerable amount of effort belaboring points that seem to be in the other document's scope. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From owner-ietf-sasl Thu Oct 30 12:05:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5rkT083801 for ; Thu, 30 Oct 2003 12:05:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK5rAf083800 for ietf-sasl-bks; Thu, 30 Oct 2003 12:05:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5qkT083795 for ; Thu, 30 Oct 2003 12:05:52 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 311C31515E8; Thu, 30 Oct 2003 15:05:42 -0500 (EST) To: ietf-sasl@imc.org Subject: Any new lines of thought on the SMTP comments Message-Id: <20031030200542.311C31515E8@konishi-polis.mit.edu> Date: Thu, 30 Oct 2003 15:05:42 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems like we're starting to repeat ourselves somewhat especially on the issue of revising examples in the plain SASL mechanism document. Are there any new positions that have not previously been considered or any misunderstandings that need to be worked out before we conclude that discussion? From owner-ietf-sasl Thu Oct 30 12:04:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4FkT083738 for ; Thu, 30 Oct 2003 12:04:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK4FZa083737 for ietf-sasl-bks; Thu, 30 Oct 2003 12:04:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4EkT083732 for ; Thu, 30 Oct 2003 12:04:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 852C41515E8; Thu, 30 Oct 2003 15:04:03 -0500 (EST) To: Cyrus Daboo Cc: Ken Murchison , "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> From: Sam Hartman Date: Thu, 30 Oct 2003 15:04:03 -0500 In-Reply-To: <2147483647.1067515216@[10.0.1.8]> (Cyrus Daboo's message of "Thu, 30 Oct 2003 12:00:16 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Cyrus" == Cyrus Daboo writes: Cyrus> | I think that encouraging/enforcing this point | is more Cyrus> important than cross-pollinating the docs with the same Cyrus> info. Cyrus> Again I would like to suggest some kind of "implementer's Cyrus> guide" document for SASL that would provide comprehensive Cyrus> examples for each type of protocol and each mechanism, as Cyrus> well as a list of the common implementation errors that Cyrus> have cropped up. That's not meant to replace having to read Cyrus> and understand each of the other documents, but can be used Cyrus> more as a starting point for multiple protocol Cyrus> implementations etc. Why is this preferable to including protocol specific implementation notes in the protocol profile documents? --Sam From owner-ietf-sasl Fri Oct 31 10:56:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuxkT002402 for ; Fri, 31 Oct 2003 10:56:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIuxsZ002401 for ietf-sasl-bks; Fri, 31 Oct 2003 10:56:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuwkT002396 for ; Fri, 31 Oct 2003 10:56:58 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8E2221515E8; Fri, 31 Oct 2003 13:56:57 -0500 (EST) To: Jeffrey Altman Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <3FA2AEBB.1010806@columbia.edu> From: Sam Hartman Date: Fri, 31 Oct 2003 13:56:57 -0500 In-Reply-To: <3FA2AEBB.1010806@columbia.edu> (Jeffrey Altman's message of "Fri, 31 Oct 2003 13:49:31 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Over the last week I have realized that we may have overlooked a Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. As you know, the document has already passed working group last call. So if we are going to make a change we should come to consensus soon. To that end, I'm seeking comments on this proposed change from the working group. From owner-ietf-sasl Fri Oct 31 10:49:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInkkT002152 for ; Fri, 31 Oct 2003 10:49:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VInkCN002151 for ietf-sasl-bks; Fri, 31 Oct 2003 10:49:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInikT002141 for ; Fri, 31 Oct 2003 10:49:45 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VInc2D007562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 13:49:42 -0500 (EST) Message-ID: <3FA2AEBB.1010806@columbia.edu> Date: Fri, 31 Oct 2003 13:49:31 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: SASLPrep vs Full Stop code points Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. The Full Stop code points U+002E (full stop) U+3002 (ideographic full stop) U+FF0E (fullwidth full stop) U+FF61 (halfwidth ideographic full stop). do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). Jeffrey Altman From owner-ietf-sasl Fri Oct 31 10:58:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwnkT002504 for ; Fri, 31 Oct 2003 10:58:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIwnVs002503 for ietf-sasl-bks; Fri, 31 Oct 2003 10:58:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwmkT002498 for ; Fri, 31 Oct 2003 10:58:48 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VIwkPh002018; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VIwj58003633; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9VIseQx027506; Fri, 31 Oct 2003 10:54:40 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9VIsdTL027505; Fri, 31 Oct 2003 10:54:39 -0800 (PST) Date: Fri, 31 Oct 2003 10:54:39 -0800 From: Nicolas Williams To: Sam Hartman Cc: Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <20031031185439.GH27412@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov References: <3FA2AEBB.1010806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Oct 31, 2003 at 01:56:57PM -0500, Sam Hartman wrote: > >>>>> "Jeffrey" == Jeffrey Altman writes: > > Jeffrey> Over the last week I have realized that we may have overlooked a > Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. > > As you know, the document has already passed working group last call. > So if we are going to make a change we should come to consensus soon. > To that end, I'm seeking comments on this proposed change from the > working group. I agree with Jeff's point. Nico -- From owner-ietf-sasl Fri Oct 31 11:52:06 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq6kT004431 for ; Fri, 31 Oct 2003 11:52:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJq6M2004430 for ietf-sasl-bks; Fri, 31 Oct 2003 11:52:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq5kT004425 for ; Fri, 31 Oct 2003 11:52:05 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 60C6F1515E8; Fri, 31 Oct 2003 14:52:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Consensus call: changing examples from ACAP to SMTP Message-Id: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> Date: Fri, 31 Oct 2003 14:52:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. The discussion seems to have died down on the issue of replacing the ACAP example with an SMTP example in the plain draft. The rough consensus of this working group is that we will not change to an SMTP-based example. We seem to believe that the examples in the plain document should illustrate that mechanisms, not illustrate common implementation errors in other related protocols. I think that we have something approaching a consensus that we will be better served by encouraging implementers to read all the appropriate documents than to include information designed to make sure that implementers will not make mistakes even if they do not read the appropriate documents. That's not as clear as the consensus against changing the example to SMTP; there may be more room for discussion on this issue. Personally I believe that we may want to consider ways in which we can make it clear to implementers what documents they want to read. --Sam From owner-ietf-sasl Fri Oct 31 11:48:52 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmpkT004281 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJmp7j004280 for ietf-sasl-bks; Fri, 31 Oct 2003 11:48:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmokT004275 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9VJmm5u025885; Fri, 31 Oct 2003 12:48:48 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VJmmru018316; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EFZ0DBUK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Date: Fri, 31 Oct 2003 11:48:48 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EG00DCUK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: CwuEY9WEdIoX6gjf2xZb2Q== Actually, the IDNA specifies that out of the Stringprep and the Nameprep profile; in the similar sense/reasons and to preserve the context of the various full stops as much as possible, it seems the Kerberos extension also need to specify the additional mappings at the extension not at the Stringprep profile and only for the Internet domain-style names. Please see the attached, esp., the issue-1. With regards, Ienup ] Date: Fri, 31 Oct 2003 13:49:31 -0500 ] From: Jeffrey Altman ] Subject: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Over the last week I have realized that we may have overlooked a ] necessary mapping for the SASLPrep: Full Stop code points. ] ] The Full Stop code points ] ] U+002E (full stop) ] U+3002 (ideographic full stop) ] U+FF0E (fullwidth full stop) ] U+FF61 (halfwidth ideographic full stop). ] ] do not have mapping tables in StringPrep and are not mapped in NamePrep ] because IDNA (RFC 3490) uses these characters as an equivalent class of ] label separators. Therefore, they cannot exist in any input to which ] NamePrep would have been applied. ] ] It is my belief that SASLPrep must specify a mapping requiring all Full ] Stop code points to be mapped to U+002E (full stop). ] ] Jeffrey Altman ] ] ] ] ] --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; name=idn-considerations-with-kerberos-extension.txt; charset=us-ascii; x-unix-mode=0644 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=idn-considerations-with-kerberos-extension.txt Content-description: idn-considerations-with-kerberos-extension.txt Content-MD5: VfsNrPuCPZApp138x+c8QQ== 10/23/2003 ienup.sung@sun.com Internationalized Domain Name considerations at Kerberos extension ------------------------------------------------------------------ 1. Overview Many existing implementations and system administrators derive Kerberos Realm and Principal Names from Internet domain-style domain names [1, 2]. While it is rather and relatively a simple task when the coded character set (codeset) is a 7-bit ASCII, when the repertoire of the characters to support increases and have to support various scripts and languages at the same time, the complexity also increases and there are issues that the existing standards have not been anticipated. Furthermore, recent standardization of Internationalized Domain Name (IDN) and accompanying application layer architecture/model called Internationalized Domain Names in Applications (IDNA) [3], further increase the complexity and uncertainty on the compatible support of the IDN. This memo tries to describe what are the surrounding issues when we move to the Unicode character set repertoire and also when we have to support IDN and also have maximum compatibility with the IDNA implementations. This memo does not cover or deal with any other internationalization issues at the moment. The U+XXXX and U+YYYYYY are the usual Unicode notations where the XXXX and the YYYYYY denote code point values in the Unicode coding space. 2. Issues and Possible Resolution Suggestions In my opinion, the following issues should be mentioned at the extension and hopefully with normative assertions/guidelines/recommendations on what should be done: - Issue-1: IDNA allows various label separators such as U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), and U+FF61 (halfwidth ideographic full stop). - Resolution-1: Before such domain-style names be used at the Kerberos implementations to derive the Realm, Principal Names, or both, such label separators should all be mapped to 7-bit ASCII/UTF-8 full-stop character ('.' which is U+002E). This is only for Internet domain-style names. - Issue-2: IDNA allows both ASCII Compatible Encoding (ACE) [3, 5] names and IDN names with 8-bit characters as possible user input. - Resolution-2: The Kerberos extension will use UTF-8 as the codeset of the choice; thus if user input is in ACE which starts with "xn--" prefix, then, such names must be converted back to non-ACE, UTF-8 IDN names through the [3]'s conversion steps before the use. For any IDN names with 8-bit characters with non-UTF-8 codsets/codepages, such names should be must be converted to UTF-8 IDN names before the use if the name is not in the UTF-8. - Issue-3: Since the Nameprep [4] used as the Stringprep [5] profile at the IDNA does the case-folding [7] mappings before the Normalization Form KC (NFKC) [8], the IDNA effectively allows various equivalent IDN names for a domain name (or, hostname for that matter). On the other hand, the SASLprep [9] that will be used by the extension does not employee the case-folding mapping and, as a consequence, generates different results for various equivalent names. - Resolution-3: Before the use, any IDN names with 8-bit characters must be converted to UTF-8 if necessary and then the Nameprep must be applied; this will ensure that the various equivalent names map to a single Realm and Principal names derived. - Issue-4: SASLprep and Nameprep prohibits Private Use Area (PUA) characters and hence denying characters/character codes of user-defined characters commonly used in Asian countries at the Principal names. - Resolution-4: Either accept that as the limitation, update the SASLprep and allow the PUA characters, or come up with a Kerberosprep profile that will allow the PUA characters by omitting the Stringprep Table C.3 from the "Prohibited Output" section. - Issue-5: The clarification [2] defines Realm and PrincipalName be encoded as KerberosString. The KerberosString type includes ACE string by definition. - Resolution-5: To reduce future confusions, the exclusion recommendation of the ACE encoded string at the KerberosString with a rationale is desired preferably at the [2] and also at the extension. If to allow the ACE, then, also ample descriptions on consequences and also additional info should be given at the [2] and the extension. - Issue-6: Case conversions are required for the Principals and Realms; Unicode introduces complications to case mappings due to the character set includes characters from various scripts and languages. - Resolution-6: If the case conversions are also required for the IDN names, they must be done as normative steps for the Realm and Principal Names. In doing so, it is necessary to provide the rules and mapping tables to have the deterministic case conversions; the rules and mappings should come from [7] and standard Unicode data files. Furthermore, considering normalized names are necessary to have deterministic name matchings in my opinion, the case conversions should not be done alone but should be done before or possibly together with the normalization depending on the normalization form that will be used for the Realm and the Principal names. Also, considering there is no mapping tables defined for the case conversions in any of the existing profiles or the Stringprep itself, it appears that the WG should come up with case conversion mapping tables that will be used at the Stringprep profile's mapping step prior to or along with the normalization step. (More investigation and study would required on this issue by the way.) - Issue-7: Unlike case-foldings that can be done in *pretty much* locale- independent way, case conversions can yield and also require different per-locale conversion mappings. - Resolution-7: Either there should be additional mappings at the mapping step of the Stringprep profile that will be used for the extension so that such locale-specific case conversion differences will be erased (in a sense, a small set of case-folding or semi-case-folding, if you will, on certain characters) or allow such per-locale conversions and treat the converted names not equivalent. 3. References [1] RFC 1510 Kerberos [2] Kerberos clarification Internet Draft [3] RFC 3490 IDNA [4] RFC 3491 Nameprep [5] RFC 3492 Punycode [6] RFC 3454 Stringprep [7] UAX21 Case Mappings for Unicode 3.2 [8] UAX15 Unicode Normalization Forms for Unicode 3.2 [9] SASLprep Internet Draft --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)-- From owner-ietf-sasl Fri Oct 31 12:07:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7vkT005240 for ; Fri, 31 Oct 2003 12:07:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VK7vL4005239 for ietf-sasl-bks; Fri, 31 Oct 2003 12:07:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7skT005234 for ; Fri, 31 Oct 2003 12:07:55 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VK7oXL008153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:07:53 -0500 (EST) Message-ID: <3FA2C10E.4080907@columbia.edu> Date: Fri, 31 Oct 2003 15:07:42 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ienup Sung wrote: >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >profile; in the similar sense/reasons and to preserve the context of the various >full stops as much as possible, it seems the Kerberos extension also need to >specify the additional mappings at the extension not at the Stringprep profile >and only for the Internet domain-style names > > I see no justification for while this should be specified at some level above the application of SASLprep. SASLprep is applied to Storage and Query strings for the purpose of ensuring that the strings are equivalent when matching are performed or that the one true form is used as input to cryptographic operations. If the Full Stop must be mapped to U+002E before applying SASLprep, and both operations must always be performed, then it follows that the Full Stop mapping should be part of SASLprep. From owner-ietf-sasl Fri Oct 31 13:07:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7JkT008084 for ; Fri, 31 Oct 2003 13:07:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VL7JbA008083 for ietf-sasl-bks; Fri, 31 Oct 2003 13:07:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7IkT008074 for ; Fri, 31 Oct 2003 13:07:18 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VL7EUP012232; Fri, 31 Oct 2003 13:07:15 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VL7Eru001817; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EIH402UK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Date: Fri, 31 Oct 2003 13:07:14 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EII402UK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: reBJGW8+y0HsYkgyST+BQg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks. I agree with you on the place where the mappings of various full stops to the U+002E (ASCII's full stop) should be done; the best place would be before any Stringprep profile based preparation and iff the name is of Internet domain style names. The reason for the above is that the U+002E isn't equivalent/equal to any other ideographic full stops for all the cases and thus, rather, the ideographic full stops needed to be preserved as they are. One notable exception is of course when they are used as label separators for the Internet domain style names. With regards, Ienup ] Date: Fri, 31 Oct 2003 15:07:42 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Ienup Sung wrote: ] ] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep ] >profile; in the similar sense/reasons and to preserve the context of the various ] >full stops as much as possible, it seems the Kerberos extension also need to ] >specify the additional mappings at the extension not at the Stringprep profile ] >and only for the Internet domain-style names ] > ] > ] I see no justification for while this should be specified at some level ] above the ] application of SASLprep. SASLprep is applied to Storage and Query ] strings for the ] purpose of ensuring that the strings are equivalent when matching are ] performed ] or that the one true form is used as input to cryptographic operations. ] ] If the Full Stop must be mapped to U+002E before applying SASLprep, and ] both ] operations must always be performed, then it follows that the Full Stop ] mapping ] should be part of SASLprep. ] ] ] ] ] From owner-ietf-sasl Fri Oct 31 13:38:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcOkT009280 for ; Fri, 31 Oct 2003 13:38:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLcO3H009279 for ietf-sasl-bks; Fri, 31 Oct 2003 13:38:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcMkT009274 for ; Fri, 31 Oct 2003 13:38:23 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VLcJvO011516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 16:38:21 -0500 (EST) Message-ID: <3FA2D641.7010408@columbia.edu> Date: Fri, 31 Oct 2003 16:38:09 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EII402UK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EII402UK@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204020601030306090208" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050204020601030306090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup: I do not agree with you. You cannot have it both ways. Either the code points are considered to be equivalent in which case they are mapped, or they are not equivalent in which case they cannot be mapped. Please remember that the purpose of SASLPrep is to produce a unique representation of a string which is independent of locale and which can be stored in a database for the purpose of ensuring that it can be queried successfully in the future. Strings which have a String Prep profile applied to them are NOT meant to be used for displaying strings to end users. They are meant only for the purpose of on the wire equivalency. SASLPrep is a string prep profile which specifies all of the steps which must be taken an in which order they are to be taken in order to produce the form to be stored in the database. If there are different classes of strings for which there should be different string prep profiles specified for the different classes. - Jeff Ienup Sung wrote: >Thanks. > >I agree with you on the place where the mappings of various full stops to >the U+002E (ASCII's full stop) should be done; the best place would be before >any Stringprep profile based preparation and iff the name is of Internet domain >style names. > >The reason for the above is that the U+002E isn't equivalent/equal to any >other ideographic full stops for all the cases and thus, rather, the ideographic >full stops needed to be preserved as they are. One notable exception is >of course when they are used as label separators for the Internet domain >style names. > >With regards, > >Ienup > > >] Date: Fri, 31 Oct 2003 15:07:42 -0500 >] From: Jeffrey Altman >] Subject: Re: SASLPrep vs Full Stop code points >] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov >] MIME-version: 1.0 >] Content-transfer-encoding: 7bit >] X-Accept-Language: en-us, en >] X-No-Spam-Score: Local >] X-Scanned-By: MIMEDefang 2.35 >] >] Ienup Sung wrote: >] >] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >] >profile; in the similar sense/reasons and to preserve the context of the >various >] >full stops as much as possible, it seems the Kerberos extension also need to >] >specify the additional mappings at the extension not at the Stringprep profile >] >and only for the Internet domain-style names >] > >] > >] I see no justification for while this should be specified at some level >] above the >] application of SASLprep. SASLprep is applied to Storage and Query >] strings for the >] purpose of ensuring that the strings are equivalent when matching are >] performed >] or that the one true form is used as input to cryptographic operations. >] >] If the Full Stop must be mapped to U+002E before applying SASLprep, and >] both >] operations must always be performed, then it follows that the Full Stop >] mapping >] should be part of SASLprep. >] >] >] >] >] > > --------------ms050204020601030306090208 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIxMzgwOVowIwYJKoZIhvcNAQkEMRYEFAZO3rSkm38d 8XqTifdq2LESwzJDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAoT9RMvowLOhLzoBNBC3C09F0YtWW vq9K1HrRy0GHVE6Fn3fufAXY1vb6wzculOoyGZehTIYfGqxhDh0Gn+rNMbZRpx2bLT65bn4f ZthYTO1wG6ErEreuhcqQ8gsvRphSdukOqsNwa3md7LeiUjwPeSkTVgX9AReiAB0XBJDAgKb9 dJaFhR54XLES+mchR0YTl1Ta+2EILkdJOdvBbs5DHjkveDAsZTd3u2+A3fBuCKMOrWJFvPPk GT4D9WqhHQ9yz2iHTbL23SUE7+A2ceUrx9/FLcEN2Xbbk1hLfE/v2rCED+edplTFX/yLyxVg nDeRxjfMJIXZQTTxbXAHD2/2MQAAAAAAAA== --------------ms050204020601030306090208-- From owner-ietf-sasl Fri Oct 31 13:51:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLpckT009725 for ; Fri, 31 Oct 2003 13:51:38 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLpcSQ009724 for ietf-sasl-bks; Fri, 31 Oct 2003 13:51:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VLpbkT009716 for ; Fri, 31 Oct 2003 13:51:37 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa10252; 31 Oct 2003 16:50 EST Date: Fri, 31 Oct 2003 16:50:59 -0500 From: Jeffrey Hutzelman To: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Friday, October 31, 2003 11:48:48 -0800 Ienup Sung wrote: > Actually, the IDNA specifies that out of the Stringprep and the Nameprep > profile; in the similar sense/reasons and to preserve the context of the > various full stops as much as possible, it seems the Kerberos extension > also need to specify the additional mappings at the extension not at the > Stringprep profile and only for the Internet domain-style names. Please bear in mind that when we discuss saslprep, we're not just talking about Kerberos; we're also talking about the whole range of SASL mechansims which also use the SASLprep profile for their authentication ID's or for other strings, and any SASL applications which use the SASLprep profile on authzids. Also, since you're apparently not familiar with the history, I'll point out that there is a simple reason why Kerberos uses the SASLprep profile. Both groups recently had need for stringprep profiles, and began to develop requirements and produce documents. As things progressed, we noticed that we were essentially writing exactly the same profile twice. So, after some investigation to determine that we had essentially the same needs, we agreed to combine the work and produce a single document. The folks you've been discussing IDN issues with over in krb-wg were part of this process. Further, I'll point out to the others reading the fundamental point that you try to make, which may have been missed -- it may be desirable to map U+3002, U+FF0E, and U+EE61 to U+002E _only_ in the context of domain names (where it is required), and not in other contexts. Doing that would indeed require that the work of mapping be done other than in SASLprep. Nameprep does not specify mapping for the full stop characters Jeff mentioned, not out of a desire to "preserve context", but because Nameprep applies to individual DNS labels, and the full stop characters are not permitted in such labels in order to avoid confusion when full domain names are represented as strings with "." separating the labels. IDNA (specifically, RFC3490) has the following to say: 1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). It also requires, in the following paragraph, that when dots are used as label separators in a domain name placed into an IDN-unaware domain name slot, the label separator MUST be U+002E, for the simple reason that none of the other possible choices are valid US-ASCII characters. However, this is of relevance only as an indication of intent, since we are NOT presently talking about any domain name slots, IDN-aware or otherwise. One legitimate way to accomplish these requiements is to insure that by the time anything is parsed out as a domain name, all of these characters have been mapped to U+002E (full stop). That is what Jeff is proposing for SASLprep. There are two significant advantages to this approach: (a) It eliminates the need for "special processing" based on whether something is to be treated as a domain name. This is particularly important in Kerberos, because even those strings in Kerberos which may be derived from domain names (certain realm names and principal name components) are _never_ treated as an independent sequence of labels; they are treated as single strings which do, in fact, contain periods. In order for KDB lookups and other operations to succeed, the periods must be consistent. (b) It provides for consistent behaviour over all strings of the relevant types (among them, Kerberos realm names and principal name components, plus the authentication ID's of several SASL mechanisms), rather than giving a different behavour for those strings or parts of strings which may contain or be derived from domain names. However, there is also a disadvantage, which is that this is a mapping based primarily on visual similarity. SASLprep does not presently contain any such mappings, other than the mapping of non-ASCII space characters to U+0020 (space). I believe we came to the conclusion in the process of designing the (now abandoned) Kerberos stringprep profile that such mappings would lead down a vague and inconsistent path of attempting to second-guess the user, and would thus be counterproductive. Section 1.2 of RFC3490 addresses this issue as well. It may be the case that the special use of dots in domain names, combined with the recommendations of RFC3490 on processing certain other full stop characters as domain label separators, justifies special handling in SASLprep. My first inclination was to agree with Jeff and Nico that this was obviously the right answer; after thinking about it for a few minutes, I'm not so sure. In any case, including this mapping in SASLprep will not save us (or applications, or krb5_sname_to_principal, or whatever) from having to recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when constructing principal names or other strings from domain names. This is because Nameprep may only be applied to individual labels, not entire domain names, and thus such names _must_ be split into separate labels at these characters, each label processed separately, and then the name reassembled, presumably using U+002E (full stop) as the label separator. This is effectively a separate processing step that is required any time nameprep is to be applied. -- Jeff From owner-ietf-sasl Fri Oct 31 14:36:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaYkT011065 for ; Fri, 31 Oct 2003 14:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMaYlU011064 for ietf-sasl-bks; Fri, 31 Oct 2003 14:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaXkT011059 for ; Fri, 31 Oct 2003 14:36:33 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9VMaUlg021617; Fri, 31 Oct 2003 22:36:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031142722.02beae80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 14:35:42 -0800 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <3FA2AEBB.1010806@columbia.edu> References: <3FA2AEBB.1010806@columbia.edu> 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: I concur. I suggest the following bullet item be added to Section 2.1 of [SASLPrep]: - the IDEOGRAPHIC FULL STOP (U+3002), FULLWIDTH FULL STOP (U+FF0E), and HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61) characters be mapped to the FULL STOP (U+002E) character. Kurt At 10:49 AM 10/31/2003, Jeffrey Altman wrote: >Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. > >The Full Stop code points > > U+002E (full stop) > U+3002 (ideographic full stop) > U+FF0E (fullwidth full stop) > U+FF61 (halfwidth ideographic full stop). > >do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. > >It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). > >Jeffrey Altman From owner-ietf-sasl Fri Oct 31 14:44:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiNkT011251 for ; Fri, 31 Oct 2003 14:44:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMiNpL011250 for ietf-sasl-bks; Fri, 31 Oct 2003 14:44:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiMkT011244 for ; Fri, 31 Oct 2003 14:44:22 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VMiMXL000293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 17:44:23 -0500 (EST) Message-ID: <3FA2E5BD.7050505@columbia.edu> Date: Fri, 31 Oct 2003 17:44:13 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <2311370000.1067637059@minbar.fac.cs.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060501080504060901060506" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060501080504060901060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > In any case, including this mapping in SASLprep will not save us (or > applications, or krb5_sname_to_principal, or whatever) from having to > recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when > constructing principal names or other strings from domain names. This > is because Nameprep may only be applied to individual labels, not > entire domain names, and thus such names _must_ be split into separate > labels at these characters, each label processed separately, and then > the name reassembled, presumably using U+002E (full stop) as the label > separator. This is effectively a separate processing step that is > required any time nameprep is to be applied. > > -- Jeff The application of SASLprep produces a Storage string or a Query string. These strings are not appropriate for use as Display strings. The distinction between the different forms of "full stops" just like the distinction between "spaces" is important for display strings. I just don't see how they can be important for query and storage strings. There is an on-going battle taking place on the ietf-imaa@ietf.org mailing list. It is a rehashing of all the arguments which have taken place over the last ten years on whether or not internationalization is a good idea. The argument is clearly pointless. Internationalized strings are not just a necessity but a desirable feature. The fundamental problems related to internationalizing protocols have been caused by an attempt to allow the use of Storage Strings as Display Strings. This is wrong. Storage and query strings are meant to be used within wire protocols. Display strings are meant to be used in user interfaces. Their use is different and therefore so are the requirements. I do not see any reason why protocols which rely on SASLprep must allow this misuse. For example, in Kerberos the set/change password protocol and the kdb could very well provide for both a storage string and a display string. The KDC could have a query function which allows any query string to be used to obtain the display string. The KDC would also utilize the display string in error messages when necessary. The purpose of this is to maintain the proper separation between the User Interface and the Wire Protocols. The one requirement is that the string prep'd Display String must equal the string prep'd storage string when the principal is created. - Jeff --------------ms060501080504060901060506 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIyNDQxM1owIwYJKoZIhvcNAQkEMRYEFHAv23S7Pu4w uhvEYdloO+pvTMaRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAvDfjwaR/czI+lxzDJHLD4rnO9uZt Rgmkky4juV8RVyREns+85GvNWjnWim379a3tn1h8JkNEhKPOqBLOeDO1tkMJ5vL7UaW1ByYr jiYRjnhEHCCXl3qlulU/QS8S33DhJLN4vAlMBN20DXEX9PS4GLXvKZbuYMwbTC+AW+ogaONh 3Fis5y3NaMQAU9uocwMxiNNUiAnKbOzP4LD7xKZCr2naA0QTqMFYGE5NOH2L3xNJOwFfKB9l 9GR5o7Qu1eAHLTRi5mRePfvRtvm1Cyu8HSEeV315bct0r2/YbdhR1SiZXrtDMQntIByR+5Z5 LB7bY3kPWDuPW/4dn2kw/MOG9wAAAAAAAA== --------------ms060501080504060901060506-- From owner-ietf-sasl Fri Oct 31 17:42:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gwkT020372 for ; Fri, 31 Oct 2003 17:42:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA11gwo0020369 for ietf-sasl-bks; Fri, 31 Oct 2003 17:42:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gukT020341 for ; Fri, 31 Oct 2003 17:42:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA11gv5u006209; Fri, 31 Oct 2003 18:42:57 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA11gvru018724; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00IIRGRK5B@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Date: Fri, 31 Oct 2003 17:42:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00IISGRK5B@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: egx+Eeie5tdm2UXdN7GdKQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Regarding the full stops, while I do understand the point of display vs. storage/query string in my opinion, I think the issue boils down onto the followign two things in my view: 1. Should/can we treat ideographic/Asian full stops as equivalent characters of the ASCII full stop (U+002E) in 100% of the possible cases/usages? The answer is no since the U+002E is not only a full stop character but it is also a period and dot/decimal point character; CJK speakers do not use the ideographic/Asian full stops as the dot/decimal point character and hence some use of the ideographic/Asian full stops rather be preserved as they are to be distingushed. And in that cases, can we distinguish what to preserve and what not to preserve and map? 2. Should/can we keep the compatiblity with the IDNA's additional and pre-processing on the label separators, i.e., mappings of all full stops to the U+002E, for the domain style (IDN) names before they are used? I think the answer should be yes. I know the above two sound conflicting and the example shown at the argument #1 could be considered as a case that may not need to be really supported. But I thought presenting them might be a valuable thing to do. With regards, Ienup From owner-ietf-sasl Fri Oct 31 20:53:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r3kT025576 for ; Fri, 31 Oct 2003 20:53:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA14r3on025575 for ietf-sasl-bks; Fri, 31 Oct 2003 20:53:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r2kT025570 for ; Fri, 31 Oct 2003 20:53:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA14r3lg027640; Sat, 1 Nov 2003 04:53:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031193854.02b18be8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 20:52:15 -0800 To: Ienup Sung From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <0HNN00IISGRK5B@mpkmail.eng.sun.com> References: <0HNN00IISGRK5B@mpkmail.eng.sun.com> 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: At 05:42 PM 10/31/2003, Ienup Sung wrote: >Regarding the full stops, while I do understand the point of display vs. >storage/query string in my opinion, I think the issue boils down onto >the followign two things in my view: >1. Should/can we treat ideographic/Asian full stops as equivalent characters > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? SASLprep is only applicable to two use cases: simple user names and password. > The answer is no since the U+002E is not only a full stop character but > it is also a period and dot/decimal point character; CJK speakers do not use > the ideographic/Asian full stops as the dot/decimal point character and > hence some use of the ideographic/Asian full stops rather be preserved as > they are to be distingushed. And in that cases, can we distinguish what to > preserve and what not to preserve and map? SASLprep scope is limited to preparation of user input strings for matching. Issues such as how to preserving the (unprepared) user input is simply beyond our scope as matching and hence SASLprep. >2. Should/can we keep the compatiblity with the IDNA's additional and > pre-processing on the label separators, i.e., mappings of all full stops to > the U+002E, for the domain style (IDN) names before they are used? > I think the answer should be yes. SASLprep can define one preparation algorithm for simple user names and passwords. Simple here implies the input has no structure. That is, names have no particular style in respect to the algorithm. It is possible that specification using SASLprep could apply additional transformations be done. However, such transforms are beyond the scope of SASLprep. >I know the above two sound conflicting and the example shown at the argument >#1 could be considered as a case that may not need to be really supported. >But I thought presenting them might be a valuable thing to do. I would be interested in hearing whether you think the additional suggested mapping is appropriate or not for matching of simple user names or passwords, and why. I think this issue boils down to whether the user provided strings: should match or not. Because user names are often constructed from domain names, and IDNA says these stops are to be treated as equivalent, I believe they should match. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r3kT025576 for ; Fri, 31 Oct 2003 20:53:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA14r3on025575 for ietf-sasl-bks; Fri, 31 Oct 2003 20:53:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA14r2kT025570 for ; Fri, 31 Oct 2003 20:53:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hA14r3lg027640; Sat, 1 Nov 2003 04:53:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031193854.02b18be8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 20:52:15 -0800 To: Ienup Sung From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <0HNN00IISGRK5B@mpkmail.eng.sun.com> References: <0HNN00IISGRK5B@mpkmail.eng.sun.com> 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: At 05:42 PM 10/31/2003, Ienup Sung wrote: >Regarding the full stops, while I do understand the point of display vs. >storage/query string in my opinion, I think the issue boils down onto >the followign two things in my view: >1. Should/can we treat ideographic/Asian full stops as equivalent characters > of the ASCII full stop (U+002E) in 100% of the possible cases/usages? SASLprep is only applicable to two use cases: simple user names and password. > The answer is no since the U+002E is not only a full stop character but > it is also a period and dot/decimal point character; CJK speakers do not use > the ideographic/Asian full stops as the dot/decimal point character and > hence some use of the ideographic/Asian full stops rather be preserved as > they are to be distingushed. And in that cases, can we distinguish what to > preserve and what not to preserve and map? SASLprep scope is limited to preparation of user input strings for matching. Issues such as how to preserving the (unprepared) user input is simply beyond our scope as matching and hence SASLprep. >2. Should/can we keep the compatiblity with the IDNA's additional and > pre-processing on the label separators, i.e., mappings of all full stops to > the U+002E, for the domain style (IDN) names before they are used? > I think the answer should be yes. SASLprep can define one preparation algorithm for simple user names and passwords. Simple here implies the input has no structure. That is, names have no particular style in respect to the algorithm. It is possible that specification using SASLprep could apply additional transformations be done. However, such transforms are beyond the scope of SASLprep. >I know the above two sound conflicting and the example shown at the argument >#1 could be considered as a case that may not need to be really supported. >But I thought presenting them might be a valuable thing to do. I would be interested in hearing whether you think the additional suggested mapping is appropriate or not for matching of simple user names or passwords, and why. I think this issue boils down to whether the user provided strings: should match or not. Because user names are often constructed from domain names, and IDNA says these stops are to be treated as equivalent, I believe they should match. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gwkT020372 for ; Fri, 31 Oct 2003 17:42:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA11gwo0020369 for ietf-sasl-bks; Fri, 31 Oct 2003 17:42:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11gukT020341 for ; Fri, 31 Oct 2003 17:42:56 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA11gv5u006209; Fri, 31 Oct 2003 18:42:57 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA11gvru018724; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00IIRGRK5B@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 17:42:57 -0800 (PST) Date: Fri, 31 Oct 2003 17:42:56 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00IISGRK5B@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: egx+Eeie5tdm2UXdN7GdKQ== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Regarding the full stops, while I do understand the point of display vs. storage/query string in my opinion, I think the issue boils down onto the followign two things in my view: 1. Should/can we treat ideographic/Asian full stops as equivalent characters of the ASCII full stop (U+002E) in 100% of the possible cases/usages? The answer is no since the U+002E is not only a full stop character but it is also a period and dot/decimal point character; CJK speakers do not use the ideographic/Asian full stops as the dot/decimal point character and hence some use of the ideographic/Asian full stops rather be preserved as they are to be distingushed. And in that cases, can we distinguish what to preserve and what not to preserve and map? 2. Should/can we keep the compatiblity with the IDNA's additional and pre-processing on the label separators, i.e., mappings of all full stops to the U+002E, for the domain style (IDN) names before they are used? I think the answer should be yes. I know the above two sound conflicting and the example shown at the argument #1 could be considered as a case that may not need to be really supported. But I thought presenting them might be a valuable thing to do. With regards, Ienup Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiNkT011251 for ; Fri, 31 Oct 2003 14:44:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMiNpL011250 for ietf-sasl-bks; Fri, 31 Oct 2003 14:44:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMiMkT011244 for ; Fri, 31 Oct 2003 14:44:22 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VMiMXL000293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 17:44:23 -0500 (EST) Message-ID: <3FA2E5BD.7050505@columbia.edu> Date: Fri, 31 Oct 2003 17:44:13 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <2311370000.1067637059@minbar.fac.cs.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060501080504060901060506" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060501080504060901060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > In any case, including this mapping in SASLprep will not save us (or > applications, or krb5_sname_to_principal, or whatever) from having to > recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when > constructing principal names or other strings from domain names. This > is because Nameprep may only be applied to individual labels, not > entire domain names, and thus such names _must_ be split into separate > labels at these characters, each label processed separately, and then > the name reassembled, presumably using U+002E (full stop) as the label > separator. This is effectively a separate processing step that is > required any time nameprep is to be applied. > > -- Jeff The application of SASLprep produces a Storage string or a Query string. These strings are not appropriate for use as Display strings. The distinction between the different forms of "full stops" just like the distinction between "spaces" is important for display strings. I just don't see how they can be important for query and storage strings. There is an on-going battle taking place on the ietf-imaa@ietf.org mailing list. It is a rehashing of all the arguments which have taken place over the last ten years on whether or not internationalization is a good idea. The argument is clearly pointless. Internationalized strings are not just a necessity but a desirable feature. The fundamental problems related to internationalizing protocols have been caused by an attempt to allow the use of Storage Strings as Display Strings. This is wrong. Storage and query strings are meant to be used within wire protocols. Display strings are meant to be used in user interfaces. Their use is different and therefore so are the requirements. I do not see any reason why protocols which rely on SASLprep must allow this misuse. For example, in Kerberos the set/change password protocol and the kdb could very well provide for both a storage string and a display string. The KDC could have a query function which allows any query string to be used to obtain the display string. The KDC would also utilize the display string in error messages when necessary. The purpose of this is to maintain the proper separation between the User Interface and the Wire Protocols. The one requirement is that the string prep'd Display String must equal the string prep'd storage string when the principal is created. - Jeff --------------ms060501080504060901060506 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIyNDQxM1owIwYJKoZIhvcNAQkEMRYEFHAv23S7Pu4w uhvEYdloO+pvTMaRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAvDfjwaR/czI+lxzDJHLD4rnO9uZt Rgmkky4juV8RVyREns+85GvNWjnWim379a3tn1h8JkNEhKPOqBLOeDO1tkMJ5vL7UaW1ByYr jiYRjnhEHCCXl3qlulU/QS8S33DhJLN4vAlMBN20DXEX9PS4GLXvKZbuYMwbTC+AW+ogaONh 3Fis5y3NaMQAU9uocwMxiNNUiAnKbOzP4LD7xKZCr2naA0QTqMFYGE5NOH2L3xNJOwFfKB9l 9GR5o7Qu1eAHLTRi5mRePfvRtvm1Cyu8HSEeV315bct0r2/YbdhR1SiZXrtDMQntIByR+5Z5 LB7bY3kPWDuPW/4dn2kw/MOG9wAAAAAAAA== --------------ms060501080504060901060506-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaYkT011065 for ; Fri, 31 Oct 2003 14:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VMaYlU011064 for ietf-sasl-bks; Fri, 31 Oct 2003 14:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VMaXkT011059 for ; Fri, 31 Oct 2003 14:36:33 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9VMaUlg021617; Fri, 31 Oct 2003 22:36:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031031142722.02beae80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 14:35:42 -0800 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: SASLPrep vs Full Stop code points Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov In-Reply-To: <3FA2AEBB.1010806@columbia.edu> References: <3FA2AEBB.1010806@columbia.edu> 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: I concur. I suggest the following bullet item be added to Section 2.1 of [SASLPrep]: - the IDEOGRAPHIC FULL STOP (U+3002), FULLWIDTH FULL STOP (U+FF0E), and HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61) characters be mapped to the FULL STOP (U+002E) character. Kurt At 10:49 AM 10/31/2003, Jeffrey Altman wrote: >Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. > >The Full Stop code points > > U+002E (full stop) > U+3002 (ideographic full stop) > U+FF0E (fullwidth full stop) > U+FF61 (halfwidth ideographic full stop). > >do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. > >It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). > >Jeffrey Altman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLpckT009725 for ; Fri, 31 Oct 2003 13:51:38 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLpcSQ009724 for ietf-sasl-bks; Fri, 31 Oct 2003 13:51:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VLpbkT009716 for ; Fri, 31 Oct 2003 13:51:37 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa10252; 31 Oct 2003 16:50 EST Date: Fri, 31 Oct 2003 16:50:59 -0500 From: Jeffrey Hutzelman To: Ienup Sung , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <2311370000.1067637059@minbar.fac.cs.cmu.edu> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Friday, October 31, 2003 11:48:48 -0800 Ienup Sung wrote: > Actually, the IDNA specifies that out of the Stringprep and the Nameprep > profile; in the similar sense/reasons and to preserve the context of the > various full stops as much as possible, it seems the Kerberos extension > also need to specify the additional mappings at the extension not at the > Stringprep profile and only for the Internet domain-style names. Please bear in mind that when we discuss saslprep, we're not just talking about Kerberos; we're also talking about the whole range of SASL mechansims which also use the SASLprep profile for their authentication ID's or for other strings, and any SASL applications which use the SASLprep profile on authzids. Also, since you're apparently not familiar with the history, I'll point out that there is a simple reason why Kerberos uses the SASLprep profile. Both groups recently had need for stringprep profiles, and began to develop requirements and produce documents. As things progressed, we noticed that we were essentially writing exactly the same profile twice. So, after some investigation to determine that we had essentially the same needs, we agreed to combine the work and produce a single document. The folks you've been discussing IDN issues with over in krb-wg were part of this process. Further, I'll point out to the others reading the fundamental point that you try to make, which may have been missed -- it may be desirable to map U+3002, U+FF0E, and U+EE61 to U+002E _only_ in the context of domain names (where it is required), and not in other contexts. Doing that would indeed require that the work of mapping be done other than in SASLprep. Nameprep does not specify mapping for the full stop characters Jeff mentioned, not out of a desire to "preserve context", but because Nameprep applies to individual DNS labels, and the full stop characters are not permitted in such labels in order to avoid confusion when full domain names are represented as strings with "." separating the labels. IDNA (specifically, RFC3490) has the following to say: 1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). It also requires, in the following paragraph, that when dots are used as label separators in a domain name placed into an IDN-unaware domain name slot, the label separator MUST be U+002E, for the simple reason that none of the other possible choices are valid US-ASCII characters. However, this is of relevance only as an indication of intent, since we are NOT presently talking about any domain name slots, IDN-aware or otherwise. One legitimate way to accomplish these requiements is to insure that by the time anything is parsed out as a domain name, all of these characters have been mapped to U+002E (full stop). That is what Jeff is proposing for SASLprep. There are two significant advantages to this approach: (a) It eliminates the need for "special processing" based on whether something is to be treated as a domain name. This is particularly important in Kerberos, because even those strings in Kerberos which may be derived from domain names (certain realm names and principal name components) are _never_ treated as an independent sequence of labels; they are treated as single strings which do, in fact, contain periods. In order for KDB lookups and other operations to succeed, the periods must be consistent. (b) It provides for consistent behaviour over all strings of the relevant types (among them, Kerberos realm names and principal name components, plus the authentication ID's of several SASL mechanisms), rather than giving a different behavour for those strings or parts of strings which may contain or be derived from domain names. However, there is also a disadvantage, which is that this is a mapping based primarily on visual similarity. SASLprep does not presently contain any such mappings, other than the mapping of non-ASCII space characters to U+0020 (space). I believe we came to the conclusion in the process of designing the (now abandoned) Kerberos stringprep profile that such mappings would lead down a vague and inconsistent path of attempting to second-guess the user, and would thus be counterproductive. Section 1.2 of RFC3490 addresses this issue as well. It may be the case that the special use of dots in domain names, combined with the recommendations of RFC3490 on processing certain other full stop characters as domain label separators, justifies special handling in SASLprep. My first inclination was to agree with Jeff and Nico that this was obviously the right answer; after thinking about it for a few minutes, I'm not so sure. In any case, including this mapping in SASLprep will not save us (or applications, or krb5_sname_to_principal, or whatever) from having to recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when constructing principal names or other strings from domain names. This is because Nameprep may only be applied to individual labels, not entire domain names, and thus such names _must_ be split into separate labels at these characters, each label processed separately, and then the name reassembled, presumably using U+002E (full stop) as the label separator. This is effectively a separate processing step that is required any time nameprep is to be applied. -- Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcOkT009280 for ; Fri, 31 Oct 2003 13:38:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLcO3H009279 for ietf-sasl-bks; Fri, 31 Oct 2003 13:38:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLcMkT009274 for ; Fri, 31 Oct 2003 13:38:23 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VLcJvO011516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 16:38:21 -0500 (EST) Message-ID: <3FA2D641.7010408@columbia.edu> Date: Fri, 31 Oct 2003 16:38:09 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EII402UK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EII402UK@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204020601030306090208" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050204020601030306090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ienup: I do not agree with you. You cannot have it both ways. Either the code points are considered to be equivalent in which case they are mapped, or they are not equivalent in which case they cannot be mapped. Please remember that the purpose of SASLPrep is to produce a unique representation of a string which is independent of locale and which can be stored in a database for the purpose of ensuring that it can be queried successfully in the future. Strings which have a String Prep profile applied to them are NOT meant to be used for displaying strings to end users. They are meant only for the purpose of on the wire equivalency. SASLPrep is a string prep profile which specifies all of the steps which must be taken an in which order they are to be taken in order to produce the form to be stored in the database. If there are different classes of strings for which there should be different string prep profiles specified for the different classes. - Jeff Ienup Sung wrote: >Thanks. > >I agree with you on the place where the mappings of various full stops to >the U+002E (ASCII's full stop) should be done; the best place would be before >any Stringprep profile based preparation and iff the name is of Internet domain >style names. > >The reason for the above is that the U+002E isn't equivalent/equal to any >other ideographic full stops for all the cases and thus, rather, the ideographic >full stops needed to be preserved as they are. One notable exception is >of course when they are used as label separators for the Internet domain >style names. > >With regards, > >Ienup > > >] Date: Fri, 31 Oct 2003 15:07:42 -0500 >] From: Jeffrey Altman >] Subject: Re: SASLPrep vs Full Stop code points >] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov >] MIME-version: 1.0 >] Content-transfer-encoding: 7bit >] X-Accept-Language: en-us, en >] X-No-Spam-Score: Local >] X-Scanned-By: MIMEDefang 2.35 >] >] Ienup Sung wrote: >] >] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >] >profile; in the similar sense/reasons and to preserve the context of the >various >] >full stops as much as possible, it seems the Kerberos extension also need to >] >specify the additional mappings at the extension not at the Stringprep profile >] >and only for the Internet domain-style names >] > >] > >] I see no justification for while this should be specified at some level >] above the >] application of SASLprep. SASLprep is applied to Storage and Query >] strings for the >] purpose of ensuring that the strings are equivalent when matching are >] performed >] or that the one true form is used as input to cryptographic operations. >] >] If the Full Stop must be mapped to U+002E before applying SASLprep, and >] both >] operations must always be performed, then it follows that the Full Stop >] mapping >] should be part of SASLprep. >] >] >] >] >] > > --------------ms050204020601030306090208 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAzMTIxMzgwOVowIwYJKoZIhvcNAQkEMRYEFAZO3rSkm38d 8XqTifdq2LESwzJDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAoT9RMvowLOhLzoBNBC3C09F0YtWW vq9K1HrRy0GHVE6Fn3fufAXY1vb6wzculOoyGZehTIYfGqxhDh0Gn+rNMbZRpx2bLT65bn4f ZthYTO1wG6ErEreuhcqQ8gsvRphSdukOqsNwa3md7LeiUjwPeSkTVgX9AReiAB0XBJDAgKb9 dJaFhR54XLES+mchR0YTl1Ta+2EILkdJOdvBbs5DHjkveDAsZTd3u2+A3fBuCKMOrWJFvPPk GT4D9WqhHQ9yz2iHTbL23SUE7+A2ceUrx9/FLcEN2Xbbk1hLfE/v2rCED+edplTFX/yLyxVg nDeRxjfMJIXZQTTxbXAHD2/2MQAAAAAAAA== --------------ms050204020601030306090208-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7JkT008084 for ; Fri, 31 Oct 2003 13:07:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VL7JbA008083 for ietf-sasl-bks; Fri, 31 Oct 2003 13:07:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL7IkT008074 for ; Fri, 31 Oct 2003 13:07:18 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VL7EUP012232; Fri, 31 Oct 2003 13:07:15 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VL7Eru001817; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EIH402UK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 13:07:14 -0800 (PST) Date: Fri, 31 Oct 2003 13:07:14 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EII402UK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: reBJGW8+y0HsYkgyST+BQg== Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks. I agree with you on the place where the mappings of various full stops to the U+002E (ASCII's full stop) should be done; the best place would be before any Stringprep profile based preparation and iff the name is of Internet domain style names. The reason for the above is that the U+002E isn't equivalent/equal to any other ideographic full stops for all the cases and thus, rather, the ideographic full stops needed to be preserved as they are. One notable exception is of course when they are used as label separators for the Internet domain style names. With regards, Ienup ] Date: Fri, 31 Oct 2003 15:07:42 -0500 ] From: Jeffrey Altman ] Subject: Re: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Ienup Sung wrote: ] ] >Actually, the IDNA specifies that out of the Stringprep and the Nameprep ] >profile; in the similar sense/reasons and to preserve the context of the various ] >full stops as much as possible, it seems the Kerberos extension also need to ] >specify the additional mappings at the extension not at the Stringprep profile ] >and only for the Internet domain-style names ] > ] > ] I see no justification for while this should be specified at some level ] above the ] application of SASLprep. SASLprep is applied to Storage and Query ] strings for the ] purpose of ensuring that the strings are equivalent when matching are ] performed ] or that the one true form is used as input to cryptographic operations. ] ] If the Full Stop must be mapped to U+002E before applying SASLprep, and ] both ] operations must always be performed, then it follows that the Full Stop ] mapping ] should be part of SASLprep. ] ] ] ] ] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7vkT005240 for ; Fri, 31 Oct 2003 12:07:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VK7vL4005239 for ietf-sasl-bks; Fri, 31 Oct 2003 12:07:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VK7skT005234 for ; Fri, 31 Oct 2003 12:07:55 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VK7oXL008153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 15:07:53 -0500 (EST) Message-ID: <3FA2C10E.4080907@columbia.edu> Date: Fri, 31 Oct 2003 15:07:42 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <0HNN00EG00DCUK@mpkmail.eng.sun.com> In-Reply-To: <0HNN00EG00DCUK@mpkmail.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ienup Sung wrote: >Actually, the IDNA specifies that out of the Stringprep and the Nameprep >profile; in the similar sense/reasons and to preserve the context of the various >full stops as much as possible, it seems the Kerberos extension also need to >specify the additional mappings at the extension not at the Stringprep profile >and only for the Internet domain-style names > > I see no justification for while this should be specified at some level above the application of SASLprep. SASLprep is applied to Storage and Query strings for the purpose of ensuring that the strings are equivalent when matching are performed or that the one true form is used as input to cryptographic operations. If the Full Stop must be mapped to U+002E before applying SASLprep, and both operations must always be performed, then it follows that the Full Stop mapping should be part of SASLprep. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq6kT004431 for ; Fri, 31 Oct 2003 11:52:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJq6M2004430 for ietf-sasl-bks; Fri, 31 Oct 2003 11:52:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJq5kT004425 for ; Fri, 31 Oct 2003 11:52:05 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 60C6F1515E8; Fri, 31 Oct 2003 14:52:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Consensus call: changing examples from ACAP to SMTP Message-Id: <20031031195205.60C6F1515E8@konishi-polis.mit.edu> Date: Fri, 31 Oct 2003 14:52:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. The discussion seems to have died down on the issue of replacing the ACAP example with an SMTP example in the plain draft. The rough consensus of this working group is that we will not change to an SMTP-based example. We seem to believe that the examples in the plain document should illustrate that mechanisms, not illustrate common implementation errors in other related protocols. I think that we have something approaching a consensus that we will be better served by encouraging implementers to read all the appropriate documents than to include information designed to make sure that implementers will not make mistakes even if they do not read the appropriate documents. That's not as clear as the consensus against changing the example to SMTP; there may be more room for discussion on this issue. Personally I believe that we may want to consider ways in which we can make it clear to implementers what documents they want to read. --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmpkT004281 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJmp7j004280 for ietf-sasl-bks; Fri, 31 Oct 2003 11:48:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJmokT004275 for ; Fri, 31 Oct 2003 11:48:51 -0800 (PST) (envelope-from is@mpkmail.eng.sun.com) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9VJmm5u025885; Fri, 31 Oct 2003 12:48:48 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VJmmru018316; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Received: from nirvana (nirvana.SFBay.Sun.COM [129.145.23.92]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HNN00EFZ0DBUK@mpkmail.eng.sun.com>; Fri, 31 Oct 2003 11:48:48 -0800 (PST) Date: Fri, 31 Oct 2003 11:48:48 -0800 (PST) From: Ienup Sung Subject: Re: SASLPrep vs Full Stop code points To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Reply-to: Ienup Sung Message-id: <0HNN00EG00DCUK@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: CwuEY9WEdIoX6gjf2xZb2Q== Actually, the IDNA specifies that out of the Stringprep and the Nameprep profile; in the similar sense/reasons and to preserve the context of the various full stops as much as possible, it seems the Kerberos extension also need to specify the additional mappings at the extension not at the Stringprep profile and only for the Internet domain-style names. Please see the attached, esp., the issue-1. With regards, Ienup ] Date: Fri, 31 Oct 2003 13:49:31 -0500 ] From: Jeffrey Altman ] Subject: SASLPrep vs Full Stop code points ] To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov ] MIME-version: 1.0 ] Content-transfer-encoding: 7bit ] X-Accept-Language: en-us, en ] X-No-Spam-Score: Local ] X-Scanned-By: MIMEDefang 2.35 ] ] Over the last week I have realized that we may have overlooked a ] necessary mapping for the SASLPrep: Full Stop code points. ] ] The Full Stop code points ] ] U+002E (full stop) ] U+3002 (ideographic full stop) ] U+FF0E (fullwidth full stop) ] U+FF61 (halfwidth ideographic full stop). ] ] do not have mapping tables in StringPrep and are not mapped in NamePrep ] because IDNA (RFC 3490) uses these characters as an equivalent class of ] label separators. Therefore, they cannot exist in any input to which ] NamePrep would have been applied. ] ] It is my belief that SASLPrep must specify a mapping requiring all Full ] Stop code points to be mapped to U+002E (full stop). ] ] Jeffrey Altman ] ] ] ] ] --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g) Content-type: TEXT/plain; name=idn-considerations-with-kerberos-extension.txt; charset=us-ascii; x-unix-mode=0644 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=idn-considerations-with-kerberos-extension.txt Content-description: idn-considerations-with-kerberos-extension.txt Content-MD5: VfsNrPuCPZApp138x+c8QQ== 10/23/2003 ienup.sung@sun.com Internationalized Domain Name considerations at Kerberos extension ------------------------------------------------------------------ 1. Overview Many existing implementations and system administrators derive Kerberos Realm and Principal Names from Internet domain-style domain names [1, 2]. While it is rather and relatively a simple task when the coded character set (codeset) is a 7-bit ASCII, when the repertoire of the characters to support increases and have to support various scripts and languages at the same time, the complexity also increases and there are issues that the existing standards have not been anticipated. Furthermore, recent standardization of Internationalized Domain Name (IDN) and accompanying application layer architecture/model called Internationalized Domain Names in Applications (IDNA) [3], further increase the complexity and uncertainty on the compatible support of the IDN. This memo tries to describe what are the surrounding issues when we move to the Unicode character set repertoire and also when we have to support IDN and also have maximum compatibility with the IDNA implementations. This memo does not cover or deal with any other internationalization issues at the moment. The U+XXXX and U+YYYYYY are the usual Unicode notations where the XXXX and the YYYYYY denote code point values in the Unicode coding space. 2. Issues and Possible Resolution Suggestions In my opinion, the following issues should be mentioned at the extension and hopefully with normative assertions/guidelines/recommendations on what should be done: - Issue-1: IDNA allows various label separators such as U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), and U+FF61 (halfwidth ideographic full stop). - Resolution-1: Before such domain-style names be used at the Kerberos implementations to derive the Realm, Principal Names, or both, such label separators should all be mapped to 7-bit ASCII/UTF-8 full-stop character ('.' which is U+002E). This is only for Internet domain-style names. - Issue-2: IDNA allows both ASCII Compatible Encoding (ACE) [3, 5] names and IDN names with 8-bit characters as possible user input. - Resolution-2: The Kerberos extension will use UTF-8 as the codeset of the choice; thus if user input is in ACE which starts with "xn--" prefix, then, such names must be converted back to non-ACE, UTF-8 IDN names through the [3]'s conversion steps before the use. For any IDN names with 8-bit characters with non-UTF-8 codsets/codepages, such names should be must be converted to UTF-8 IDN names before the use if the name is not in the UTF-8. - Issue-3: Since the Nameprep [4] used as the Stringprep [5] profile at the IDNA does the case-folding [7] mappings before the Normalization Form KC (NFKC) [8], the IDNA effectively allows various equivalent IDN names for a domain name (or, hostname for that matter). On the other hand, the SASLprep [9] that will be used by the extension does not employee the case-folding mapping and, as a consequence, generates different results for various equivalent names. - Resolution-3: Before the use, any IDN names with 8-bit characters must be converted to UTF-8 if necessary and then the Nameprep must be applied; this will ensure that the various equivalent names map to a single Realm and Principal names derived. - Issue-4: SASLprep and Nameprep prohibits Private Use Area (PUA) characters and hence denying characters/character codes of user-defined characters commonly used in Asian countries at the Principal names. - Resolution-4: Either accept that as the limitation, update the SASLprep and allow the PUA characters, or come up with a Kerberosprep profile that will allow the PUA characters by omitting the Stringprep Table C.3 from the "Prohibited Output" section. - Issue-5: The clarification [2] defines Realm and PrincipalName be encoded as KerberosString. The KerberosString type includes ACE string by definition. - Resolution-5: To reduce future confusions, the exclusion recommendation of the ACE encoded string at the KerberosString with a rationale is desired preferably at the [2] and also at the extension. If to allow the ACE, then, also ample descriptions on consequences and also additional info should be given at the [2] and the extension. - Issue-6: Case conversions are required for the Principals and Realms; Unicode introduces complications to case mappings due to the character set includes characters from various scripts and languages. - Resolution-6: If the case conversions are also required for the IDN names, they must be done as normative steps for the Realm and Principal Names. In doing so, it is necessary to provide the rules and mapping tables to have the deterministic case conversions; the rules and mappings should come from [7] and standard Unicode data files. Furthermore, considering normalized names are necessary to have deterministic name matchings in my opinion, the case conversions should not be done alone but should be done before or possibly together with the normalization depending on the normalization form that will be used for the Realm and the Principal names. Also, considering there is no mapping tables defined for the case conversions in any of the existing profiles or the Stringprep itself, it appears that the WG should come up with case conversion mapping tables that will be used at the Stringprep profile's mapping step prior to or along with the normalization step. (More investigation and study would required on this issue by the way.) - Issue-7: Unlike case-foldings that can be done in *pretty much* locale- independent way, case conversions can yield and also require different per-locale conversion mappings. - Resolution-7: Either there should be additional mappings at the mapping step of the Stringprep profile that will be used for the extension so that such locale-specific case conversion differences will be erased (in a sense, a small set of case-folding or semi-case-folding, if you will, on certain characters) or allow such per-locale conversions and treat the converted names not equivalent. 3. References [1] RFC 1510 Kerberos [2] Kerberos clarification Internet Draft [3] RFC 3490 IDNA [4] RFC 3491 Nameprep [5] RFC 3492 Punycode [6] RFC 3454 Stringprep [7] UAX21 Case Mappings for Unicode 3.2 [8] UAX15 Unicode Normalization Forms for Unicode 3.2 [9] SASLprep Internet Draft --Boundary_(ID_iHfplVVsxREVrFiq1oDd/g)-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwnkT002504 for ; Fri, 31 Oct 2003 10:58:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIwnVs002503 for ietf-sasl-bks; Fri, 31 Oct 2003 10:58:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIwmkT002498 for ; Fri, 31 Oct 2003 10:58:48 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VIwkPh002018; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9VIwj58003633; Fri, 31 Oct 2003 11:58:46 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9VIseQx027506; Fri, 31 Oct 2003 10:54:40 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9VIsdTL027505; Fri, 31 Oct 2003 10:54:39 -0800 (PST) Date: Fri, 31 Oct 2003 10:54:39 -0800 From: Nicolas Williams To: Sam Hartman Cc: Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points Message-ID: <20031031185439.GH27412@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Jeffrey Altman , ietf-sasl@imc.org, ietf-krb-wg@anl.gov References: <3FA2AEBB.1010806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Oct 31, 2003 at 01:56:57PM -0500, Sam Hartman wrote: > >>>>> "Jeffrey" == Jeffrey Altman writes: > > Jeffrey> Over the last week I have realized that we may have overlooked a > Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. > > As you know, the document has already passed working group last call. > So if we are going to make a change we should come to consensus soon. > To that end, I'm seeking comments on this proposed change from the > working group. I agree with Jeff's point. Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuxkT002402 for ; Fri, 31 Oct 2003 10:56:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIuxsZ002401 for ietf-sasl-bks; Fri, 31 Oct 2003 10:56:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIuwkT002396 for ; Fri, 31 Oct 2003 10:56:58 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8E2221515E8; Fri, 31 Oct 2003 13:56:57 -0500 (EST) To: Jeffrey Altman Cc: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: Re: SASLPrep vs Full Stop code points References: <3FA2AEBB.1010806@columbia.edu> From: Sam Hartman Date: Fri, 31 Oct 2003 13:56:57 -0500 In-Reply-To: <3FA2AEBB.1010806@columbia.edu> (Jeffrey Altman's message of "Fri, 31 Oct 2003 13:49:31 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Over the last week I have realized that we may have overlooked a Jeffrey> necessary mapping for the SASLPrep: Full Stop code points. As you know, the document has already passed working group last call. So if we are going to make a change we should come to consensus soon. To that end, I'm seeking comments on this proposed change from the working group. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInkkT002152 for ; Fri, 31 Oct 2003 10:49:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VInkCN002151 for ietf-sasl-bks; Fri, 31 Oct 2003 10:49:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VInikT002141 for ; Fri, 31 Oct 2003 10:49:45 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VInc2D007562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 13:49:42 -0500 (EST) Message-ID: <3FA2AEBB.1010806@columbia.edu> Date: Fri, 31 Oct 2003 13:49:31 -0500 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-krb-wg@anl.gov Subject: SASLPrep vs Full Stop code points Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Over the last week I have realized that we may have overlooked a necessary mapping for the SASLPrep: Full Stop code points. The Full Stop code points U+002E (full stop) U+3002 (ideographic full stop) U+FF0E (fullwidth full stop) U+FF61 (halfwidth ideographic full stop). do not have mapping tables in StringPrep and are not mapped in NamePrep because IDNA (RFC 3490) uses these characters as an equivalent class of label separators. Therefore, they cannot exist in any input to which NamePrep would have been applied. It is my belief that SASLPrep must specify a mapping requiring all Full Stop code points to be mapped to U+002E (full stop). Jeffrey Altman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5rkT083801 for ; Thu, 30 Oct 2003 12:05:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK5rAf083800 for ietf-sasl-bks; Thu, 30 Oct 2003 12:05:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK5qkT083795 for ; Thu, 30 Oct 2003 12:05:52 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 311C31515E8; Thu, 30 Oct 2003 15:05:42 -0500 (EST) To: ietf-sasl@imc.org Subject: Any new lines of thought on the SMTP comments Message-Id: <20031030200542.311C31515E8@konishi-polis.mit.edu> Date: Thu, 30 Oct 2003 15:05:42 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems like we're starting to repeat ourselves somewhat especially on the issue of revising examples in the plain SASL mechanism document. Are there any new positions that have not previously been considered or any misunderstandings that need to be worked out before we conclude that discussion? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4FkT083738 for ; Thu, 30 Oct 2003 12:04:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UK4FZa083737 for ietf-sasl-bks; Thu, 30 Oct 2003 12:04:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UK4EkT083732 for ; Thu, 30 Oct 2003 12:04:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 852C41515E8; Thu, 30 Oct 2003 15:04:03 -0500 (EST) To: Cyrus Daboo Cc: Ken Murchison , "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> From: Sam Hartman Date: Thu, 30 Oct 2003 15:04:03 -0500 In-Reply-To: <2147483647.1067515216@[10.0.1.8]> (Cyrus Daboo's message of "Thu, 30 Oct 2003 12:00:16 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Cyrus" == Cyrus Daboo writes: Cyrus> | I think that encouraging/enforcing this point | is more Cyrus> important than cross-pollinating the docs with the same Cyrus> info. Cyrus> Again I would like to suggest some kind of "implementer's Cyrus> guide" document for SASL that would provide comprehensive Cyrus> examples for each type of protocol and each mechanism, as Cyrus> well as a list of the common implementation errors that Cyrus> have cropped up. That's not meant to replace having to read Cyrus> and understand each of the other documents, but can be used Cyrus> more as a starting point for multiple protocol Cyrus> implementations etc. Why is this preferable to including protocol specific implementation notes in the protocol profile documents? --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdakT079630 for ; Thu, 30 Oct 2003 10:39:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIdav6079629 for ietf-sasl-bks; Thu, 30 Oct 2003 10:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIdZkT079621 for ; Thu, 30 Oct 2003 10:39:35 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTaZ032355; Thu, 30 Oct 2003 10:39:34 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UIdTEf008294; Thu, 30 Oct 2003 10:39:29 -0800 Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> 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: On Thu, 30 Oct 2003, Kurt D. Zeilenga wrote: > If they don't read the SASL specification, then any wouldn't read any > examples we'd place there. Exactly. That's why it has to be in all the relevant documents, in the hope that the implementor will see the example in the document he chooses to read. > I also note that examples are informative > in nature. It should be possible to independently develop interoperable > implementations without reading any example. I wish that too; but it is unrealistic. > I think we're resisting attempts to add examples intended to clarify > aspects of protocol which are not specified in this document. Clarifying > the SMTP, LDAP, IMAP, and other application level protocol specifications > is beyond the scope of this document. PLAIN is a mechanism which can operate in one of two ways, depending upon whether or not the client supplies initial data. This applies to all application protocols that use SASL. Therefore, this is within the scope of PLAIN. The choice of SMTP instead of ACAP is defensible by the fact that there will be many more SMTP implementations than ACAP implementations. Also, SMTP style interaction is much more typical of Internet protocols than ACAP (or POP3 or IMAP). NNTP and FTP are other examples of such protocols that use SASL now (or are likely to in the future). The fact that a server needs to send something like "334 " (note the trailing space) and nothing else is non-intuitive and surprising. It triggers a "that can't be right" feeling. Therefore, there needs to be explicit examples that say, "yes, it is right". No matter how redundant an example may seem to be, if it prevents a bad implementation then less harm is done by having the example in the document. I regularly deal with individuals who insist that because explicit text isn't in one particular RFC, the associated requirement therefore does not exist -- no matter how many normative documents say otherwise! This is why RFCs 2821 and 2822 spend a considerable amount of effort belaboring points that seem to be in the other document's scope. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075968 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHn5jA075967 for ietf-sasl-bks; Thu, 30 Oct 2003 09:49:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHn5kT075959 for ; Thu, 30 Oct 2003 09:49:05 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9UHn1xA026420; Thu, 30 Oct 2003 09:49:01 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9UHn058006952; Thu, 30 Oct 2003 10:49:01 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9UHisQx023663; Thu, 30 Oct 2003 09:44:54 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9UHirAC023662; Thu, 30 Oct 2003 09:44:53 -0800 (PST) Date: Thu, 30 Oct 2003 09:44:53 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031030174453.GI24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 30, 2003 at 11:45:55AM -0500, Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman > Nicolas> wrote: > >> * There was some discussion of multiple layers of encryption > >> (TLS vs security layers) in XMPP; do we want to develop > >> guidance for protocol designers on this issue? > > Nicolas> I think this should be discussed. > > Nicolas> I think the guidance we want to give is: don't delegate > Nicolas> session protection from one layer to another without > Nicolas> confirming that the end-points at both layers are the > Nicolas> same. > Sam> This approach is out of scope for the SASL working group as it Sam> cannot be implemented within the current charter. If you want to Sam> discuss the approach on the list, that's fine. However I don't Sam> think modifying SASL to gain channel bindings is appropriate for Sam> meeting time at the IETF. I don't see how the text from me that you quote could possibly be out of scope for this WG - that text calls for "guidance" - security considerations text. The following text from me which you didn't quote does propose two things, one of which may well be out of scope for the WG - which is fine by me, as long as guidance is given: Nico> It would be nice if SASL had a channel bindings facility. Such a Nico> facility could be added or applications could be encouraged to Nico> exchange channel bindings data integrity protected at the SASL Nico> layer. I can see that adding a channel bindings facility to SASL may be out of scope for this WG. That said, you could argue that the channel bindings I-D itself provides, or should provide, sufficient guidance for developers of SASL application protocols. If so, please review the text in section 3.2 of draft-ietf-nfsv4-channel-bindings-00.txt. Thanks, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi5kT075669 for ; Thu, 30 Oct 2003 09:44:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHi56P075668 for ietf-sasl-bks; Thu, 30 Oct 2003 09:44:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHi4kT075662 for ; Thu, 30 Oct 2003 09:44:04 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9UHi2lg005675; Thu, 30 Oct 2003 17:44:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030091622.047837c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 09:43:15 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Ken Murchison , Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: At 07:48 AM 10/30/2003, Mark Crispin wrote: >People cut corners, skip documents, and make assumptions through empirical >tests with existing implementation. I wish that the world was not this >way. It is. > >For people with that mindset, the only thing that you need the SMTP SASL >document for is to learn the response codes. Nothing else needs to be >read. They don't read 2222 either. "It works with Netscape and Outlook" >is their rallying call. If they don't read the SASL specification, then any wouldn't read any examples we'd place there. I also note that examples are informative in nature. It should be possible to independently develop interoperable implementations without reading any example. >Clarifying examples are always good. If placed in the appropriate document and don't get in the way of the definitive specification, I would accept that non-redundant clarifying examples are generally good thing. >I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. I think we're resisting attempts to add examples intended to clarify aspects of protocol which are not specified in this document. Clarifying the SMTP, LDAP, IMAP, and other application level protocol specifications is beyond the scope of this document. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHaekT075028 for ; Thu, 30 Oct 2003 09:36:40 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHaePV075023 for ietf-sasl-bks; Thu, 30 Oct 2003 09:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHadkT074955 for ; Thu, 30 Oct 2003 09:36:39 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UHaV3w002180; Thu, 30 Oct 2003 12:36:31 -0500 (EST) Message-ID: <3FA14CD4.6020806@oceana.com> Date: Thu, 30 Oct 2003 12:39:32 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: "Kurt D. Zeilenga" , Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <2147483647.1067515216@[10.0.1.8]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Ken, > > --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison > wrote: > > | No matter how you slice it, any good/responsible implementer is going to > | *have* to read three docs. > > Its not just three, in fact it is one (SASL), + one per-mechanism, + one > per-protocol. If you're writing an email client, chances are that's Right. I was just looking at the SMTP + PLAIN scenario. > going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case > we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). > Each of those is slightly different in some way. Multiply that by all > the mechanisms... > > | I think that encouraging/enforcing this point > | is more important than cross-pollinating the docs with the same info. > > Again I would like to suggest some kind of "implementer's guide" > document for SASL that would provide comprehensive examples for each > type of protocol and each mechanism, as well as a list of the common > implementation errors that have cropped up. That's not meant to replace > having to read and understand each of the other documents, but can be > used more as a starting point for multiple protocol implementations etc. I think this is an excellent idea. I might even be able to volunteer to author or co-author such a document. > I would also like to suggest the possibility of an interop event once > the new docs are out so that we can pin down problems related to the new > i18n stuff, as well as weed out existing problems. The feedback from > that could be used in the implementer's guide too. Another good idea. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAokT073611 for ; Thu, 30 Oct 2003 09:10:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHAoGk073610 for ietf-sasl-bks; Thu, 30 Oct 2003 09:10:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHAnkT073597 for ; Thu, 30 Oct 2003 09:10:49 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 30 Oct 2003 17:11:11 +0000 Message-ID: <3FA1460D.6070108@isode.com> Date: Thu, 30 Oct 2003 17:10:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: Ken Murchison , "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >Clarifying examples are always good. I understand why you resist >examples; I underwent that myself with the IMAP specification. The IMAP >specification had to grow enormously to accomodate all the examples that >people insisted upon adding. But even I have to acknowledge that the >result was better than what was before. > Instead of modifying PLAIN, I would rather recommend adding more examples to RFC2222bis or create a new draft "SASL Implementation Considerations" which contains list of common mistakes and compares different profiles. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0FkT072715 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UH0FcR072714 for ietf-sasl-bks; Thu, 30 Oct 2003 09:00:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH0EkT072707 for ; Thu, 30 Oct 2003 09:00:15 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9UGqKEG032595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 11:52:23 -0500 Date: Thu, 30 Oct 2003 12:00:16 -0500 From: Cyrus Daboo To: Ken Murchison , "Kurt D. Zeilenga" cc: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Message-ID: <2147483647.1067515216@[10.0.1.8]> In-Reply-To: <3FA12679.3070409@oceana.com> References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 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: Hi Ken, --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison wrote: | No matter how you slice it, any good/responsible implementer is going to | *have* to read three docs. Its not just three, in fact it is one (SASL), + one per-mechanism, + one per-protocol. If you're writing an email client, chances are that's going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). Each of those is slightly different in some way. Multiply that by all the mechanisms... | I think that encouraging/enforcing this point | is more important than cross-pollinating the docs with the same info. Again I would like to suggest some kind of "implementer's guide" document for SASL that would provide comprehensive examples for each type of protocol and each mechanism, as well as a list of the common implementation errors that have cropped up. That's not meant to replace having to read and understand each of the other documents, but can be used more as a starting point for multiple protocol implementations etc. I would also like to suggest the possibility of an interop event once the new docs are out so that we can pin down problems related to the new i18n stuff, as well as weed out existing problems. The feedback from that could be used in the implementer's guide too. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjskT071831 for ; Thu, 30 Oct 2003 08:45:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGjrQs071830 for ietf-sasl-bks; Thu, 30 Oct 2003 08:45:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGjqkT071818 for ; Thu, 30 Oct 2003 08:45:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 80E071515E8; Thu, 30 Oct 2003 11:45:55 -0500 (EST) To: ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> From: Sam Hartman Date: Thu, 30 Oct 2003 11:45:55 -0500 In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> (Nicolas Williams's message of "Wed, 29 Oct 2003 14:51:09 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman Nicolas> wrote: >> * There was some discussion of multiple layers of encryption >> (TLS vs security layers) in XMPP; do we want to develop >> guidance for protocol designers on this issue? Nicolas> I think this should be discussed. Nicolas> I think the guidance we want to give is: don't delegate Nicolas> session protection from one layer to another without Nicolas> confirming that the end-points at both layers are the Nicolas> same. This approach is out of scope for the SASL working group as it cannot be implemented within the current charter. If you want to discuss the approach on the list, that's fine. However I don't think modifying SASL to gain channel bindings is appropriate for meeting time at the IETF. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmUkT068901 for ; Thu, 30 Oct 2003 07:48:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UFmUTg068900 for ietf-sasl-bks; Thu, 30 Oct 2003 07:48:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFmTkT068893 for ; Thu, 30 Oct 2003 07:48:29 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRmw032022; Thu, 30 Oct 2003 07:48:27 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9UFmRtS032744; Thu, 30 Oct 2003 07:48:27 -0800 Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <3FA12679.3070409@oceana.com> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> <3FA12679.3070409@oceana.com> 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: On Thu, 30 Oct 2003, Ken Murchison wrote: > No matter how you slice it, any good/responsible implementer is going to > *have* to read three docs. I think that encouraging/enforcing this > point is more important than cross-pollinating the docs with the same info. Unfortunately, the "good/responsible implementors" do not include the authors of SMTP SASL for qmail, Microsoft Exchange, or for one of China's main SMTP servers (smtp.163.net). People cut corners, skip documents, and make assumptions through empirical tests with existing implementation. I wish that the world was not this way. It is. For people with that mindset, the only thing that you need the SMTP SASL document for is to learn the response codes. Nothing else needs to be read. They don't read 2222 either. "It works with Netscape and Outlook" is their rallying call. I am not of that mindset, but I have spent many weary hours convincing those who have that mindset that their software is broken. Clarifying examples are always good. I understand why you resist examples; I underwent that myself with the IMAP specification. The IMAP specification had to grow enormously to accomodate all the examples that people insisted upon adding. But even I have to acknowledge that the result was better than what was before. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr9kT065699 for ; Thu, 30 Oct 2003 06:53:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UEr9iQ065698 for ietf-sasl-bks; Thu, 30 Oct 2003 06:53:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEr4kT065689 for ; Thu, 30 Oct 2003 06:53:07 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9UEqq3w031544; Thu, 30 Oct 2003 09:52:52 -0500 (EST) Message-ID: <3FA12679.3070409@oceana.com> Date: Thu, 30 Oct 2003 09:55:53 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Crispin , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > At 11:17 PM 10/29/2003, Mark Crispin wrote: > >>On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> >>>I think ACAP is a good choice for illustration of SASL/PLAIN >>>mechanism. No base64, meaningful protocol tokens (instead of >>>numeric codes), and a straightforward/simple syntax. >> >>It is precisely because ACAP does not use BASE64 and does not use numeric >>code that makes it unsuitable. IMAP is also unsuitable. > > > The sole purpose of the example is to illustrate the syntax and > semantics described in Section 2 and this purpose is, in my opinion, > best served by avoiding protocol encodings which obfuscate the value > of the message production. I tend to agree. The mechanism docs should only have to worry about the order and contents of the exchanges, not how they are encoded or how the client-first and server-last issues are handled. >>>The trouble we've seen with SMTP implementations, I think, make >>>SMTP a particular bad choice for use here. >> >>The trouble with SMTP implementation is the *exact* reason why SMTP >>examples are needed. You don't need examples for things that people will >>get right. You need examples for things that people get wrong! > > > Some folks have problems getting LDAP/SASL right, so, by your argument, > we should include LDAP-based examples in the PLAIN document. > > The trouble with SMTP implementations of SMTP's SASL profile is more > appropriately addressed by revising the SMTP specification. Attempting > to address these problems in the PLAIN specification might lead to > even more confusion in the SMTP community. I understand why Mark is proposing more examples (to prevent large deployment of incorrect implementations that we all have to deal with), but I have to agree with Kurt that the protocol profile is where comprehensive examples belong. RFC 2222[bis] was written so that the protocol profiles and mechanism specifications are orthogonal. In fact, the PLAIN doc shouldn't have to worry about whether particular protocols support an initial response or not. RFC 2222bis describes how to handle this, and the protocol profile should describe how to implement it. No matter how you slice it, any good/responsible implementer is going to *have* to read three docs. I think that encouraging/enforcing this point is more important than cross-pollinating the docs with the same info. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CkkT040821 for ; Thu, 30 Oct 2003 01:12:46 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U9CktC040819 for ietf-sasl-bks; Thu, 30 Oct 2003 01:12:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9CjkT040809 for ; Thu, 30 Oct 2003 01:12:45 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U9Cglg001249; Thu, 30 Oct 2003 09:12:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031030004344.0467f8e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 01:11:56 -0800 To: Mark Crispin From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: Rob Siemborski , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: At 11:17 PM 10/29/2003, Mark Crispin wrote: >On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: >> I think ACAP is a good choice for illustration of SASL/PLAIN >> mechanism. No base64, meaningful protocol tokens (instead of >> numeric codes), and a straightforward/simple syntax. > >It is precisely because ACAP does not use BASE64 and does not use numeric >code that makes it unsuitable. IMAP is also unsuitable. The sole purpose of the example is to illustrate the syntax and semantics described in Section 2 and this purpose is, in my opinion, best served by avoiding protocol encodings which obfuscate the value of the message production. >> The trouble we've seen with SMTP implementations, I think, make >> SMTP a particular bad choice for use here. > >The trouble with SMTP implementation is the *exact* reason why SMTP >examples are needed. You don't need examples for things that people will >get right. You need examples for things that people get wrong! Some folks have problems getting LDAP/SASL right, so, by your argument, we should include LDAP-based examples in the PLAIN document. The trouble with SMTP implementations of SMTP's SASL profile is more appropriately addressed by revising the SMTP specification. Attempting to address these problems in the PLAIN specification might lead to even more confusion in the SMTP community. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HjkT004053 for ; Wed, 29 Oct 2003 23:17:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7Hj88004052 for ietf-sasl-bks; Wed, 29 Oct 2003 23:17:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7HikT004044 for ; Wed, 29 Oct 2003 23:17:44 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7HeMk021511; Wed, 29 Oct 2003 23:17:45 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9U7Hemo023689; Wed, 29 Oct 2003 23:17:40 -0800 Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST) From: Mark Crispin To: "Kurt D. Zeilenga" cc: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt In-Reply-To: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> Message-ID: References: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> 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: On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote: > I think ACAP is a good choice for illustration of SASL/PLAIN > mechanism. No base64, meaningful protocol tokens (instead of > numeric codes), and a straightforward/simple syntax. It is precisely because ACAP does not use BASE64 and does not use numeric code that makes it unsuitable. IMAP is also unsuitable. > The trouble we've seen with SMTP implementations, I think, make > SMTP a particular bad choice for use here. The trouble with SMTP implementation is the *exact* reason why SMTP examples are needed. You don't need examples for things that people will get right. You need examples for things that people get wrong! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BikT001883 for ; Wed, 29 Oct 2003 23:11:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U7BiDN001882 for ietf-sasl-bks; Wed, 29 Oct 2003 23:11:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U7BhkT001870 for ; Wed, 29 Oct 2003 23:11:43 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9U7Bblg099887; Thu, 30 Oct 2003 07:11:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031029220508.046461a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 23:10:51 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt Cc: ietf-sasl@imc.org, mrc@CAC.Washington.EDU In-Reply-To: References: 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: At 04:05 PM 10/29/2003, Rob Siemborski wrote: >Mark had a few comments on the PLAIN draft, mostly centered around the >issue of the initial response examples. I tend to agree with his >assessments. I'll note (as Kurt did), that this document has already been >through the WG last call. > >a) ACAP is probably not the best choice of protocol for the example, since >it is not in wide use. A protocol such as SMTP is probably more >appropriate (especially given the trouble we've seen with SMTP >implementations getting initial response handling correct). SMTP has the >added advantage of having 3 digit response codes that in other have >optional text -- though that is not the case in the SASL challenges. I think ACAP is a good choice for illustration of SASL/PLAIN mechanism. No base64, meaningful protocol tokens (instead of numeric codes), and a straightforward/simple syntax. I doubt developers needs to consult the ACAP specific to understand the example. The trouble we've seen with SMTP implementations, I think, make SMTP a particular bad choice for use here. >b) An example demonstrating plain without using the initial response >argument on a protocol that supports it. This would again help to address >the implementation problems with the optional initial client send. I have no objection to adding another example. I'll offer specific text for the WG to consider in a subsequent post. >One thing that may also help is to place reminders in mechanism (and >protocol) documents that a correct implementation of SASL for a given >protocol requires an understanding of the protocol profile, the SASL >framework, and the mechanism, and that reading all three documents is >necessary to get it right. I'll stay on the fence on this one, so I suggest that someone who currently supports adding such offer specific text for WG consideration. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05DkT053844 for ; Wed, 29 Oct 2003 16:05:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U05DhD053842 for ietf-sasl-bks; Wed, 29 Oct 2003 16:05:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U05BkT053836 for ; Wed, 29 Oct 2003 16:05:11 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9U05CE7016851; Wed, 29 Oct 2003 19:05:12 -0500 Date: Wed, 29 Oct 2003 19:05:11 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org cc: mrc@CAC.Washington.EDU Subject: Mark Crispin's comments on draft-ietf-sasl-plain-03.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: Mark had a few comments on the PLAIN draft, mostly centered around the issue of the initial response examples. I tend to agree with his assessments. I'll note (as Kurt did), that this document has already been through the WG last call. a) ACAP is probably not the best choice of protocol for the example, since it is not in wide use. A protocol such as SMTP is probably more appropriate (especially given the trouble we've seen with SMTP implementations getting initial response handling correct). SMTP has the added advantage of having 3 digit response codes that in other have optional text -- though that is not the case in the SASL challenges. b) An example demonstrating plain without using the initial response argument on a protocol that supports it. This would again help to address the implementation problems with the optional initial client send. There are examples in draft-siemborski-rfc2554bis-00.txt (using SMTP) that satisfy this, and could be used. One thing that may also help is to place reminders in mechanism (and protocol) documents that a correct implementation of SASL for a given protocol requires an understanding of the protocol profile, the SASL framework, and the mechanism, and that reading all three documents is necessary to get it right. Of course, in a perfect world, normative references would be enough, but experience seems to be showing this not to be the case. (I'd also like to encourage people again to read over and comment more generally on draft-siemborski-rfc2554bis-00.txt and draft-siemborski-rfc1734bis-00.txt). We're also both planning on being at the SASL WG meeting in Minneapolis, and can discuss this further then. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052767 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNmMVb052766 for ietf-sasl-bks; Wed, 29 Oct 2003 15:48:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNmMkT052738 for ; Wed, 29 Oct 2003 15:48:22 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TNmJxA004621; Wed, 29 Oct 2003 15:48:19 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TNmI2o023242; Wed, 29 Oct 2003 16:48:18 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TNiCQx022365; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TNiCMe022364; Wed, 29 Oct 2003 15:44:12 -0800 (PST) Date: Wed, 29 Oct 2003 15:44:12 -0800 From: Nicolas Williams To: ietf-sasl@imc.org Cc: Sam Hartman Subject: Re: Agenda items to discuss Message-ID: <20031029234412.GF24528@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org, Sam Hartman References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> <3FA050DA.9000702@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA050DA.9000702@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 06:44:26PM -0500, Jeffrey Altman [Kermit Project Volunteer] wrote: > Nicolas Williams wrote: > [...] > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > [...] > I second this sentiment. We need to provide advice on how the > underlying session security can be validated as part of the SASL > authentication OR after the authentication by exchanging messages using > the SASL Security Layer which can be then be turned off if validation > was successful. Note that I did post a request for this and other WGs to review the channel bindings draft. There is a section in that I-D about SASL, BTW. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiakT052523 for ; Wed, 29 Oct 2003 15:44:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNiaKH052522 for ietf-sasl-bks; Wed, 29 Oct 2003 15:44:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNiYkT052517 for ; Wed, 29 Oct 2003 15:44:35 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9TNiUY9001498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Oct 2003 18:44:33 -0500 (EST) Message-ID: <3FA050DA.9000702@columbia.edu> Date: Wed, 29 Oct 2003 18:44:26 -0500 From: "Jeffrey Altman [Kermit Project Volunteer]" Reply-To: ietf-sasl@imc.org Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-sasl@imc.org Subject: Re: Agenda items to discuss References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> <20031029225109.GB24528@binky.central.sun.com> In-Reply-To: <20031029225109.GB24528@binky.central.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Nicolas Williams wrote: >On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > > >>* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want >>to develop guidance for protocol designers on this issue? >> >> > >I think this should be discussed. > >I think the guidance we want to give is: don't delegate session >protection from one layer to another without confirming that the >end-points at both layers are the same. > >See: > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt > > >It would be nice if SASL had a channel bindings facility. Such a >facility could be added or applications could be encouraged to exchange >channel bindings data integrity protected at the SASL layer. > >Can GSS-API channel bindings facility be used when using the GSS-* SASL >mechanisms? > >Cheers, > >Nico > > I second this sentiment. We need to provide advice on how the underlying session security can be validated as part of the SASL authentication OR after the authentication by exchanging messages using the SASL Security Layer which can be then be turned off if validation was successful. Jeffrey Altman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtKkT049836 for ; Wed, 29 Oct 2003 14:55:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMtKOS049835 for ietf-sasl-bks; Wed, 29 Oct 2003 14:55:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMtJkT049828 for ; Wed, 29 Oct 2003 14:55:19 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TMtGxA014090; Wed, 29 Oct 2003 14:55:16 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TMtG58017978; Wed, 29 Oct 2003 15:55:16 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TMpAQx010060; Wed, 29 Oct 2003 14:51:10 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TMp9Jc010059; Wed, 29 Oct 2003 14:51:09 -0800 (PST) Date: Wed, 29 Oct 2003 14:51:09 -0800 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Agenda items to discuss Message-ID: <20031029225109.GB24528@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I think this should be discussed. I think the guidance we want to give is: don't delegate session protection from one layer to another without confirming that the end-points at both layers are the same. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt It would be nice if SASL had a channel bindings facility. Such a facility could be added or applications could be encouraged to exchange channel bindings data integrity protected at the SASL layer. Can GSS-API channel bindings facility be used when using the GSS-* SASL mechanisms? Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwJkT046847 for ; Wed, 29 Oct 2003 13:58:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLwJ3q046846 for ietf-sasl-bks; Wed, 29 Oct 2003 13:58:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwHkT046840 for ; Wed, 29 Oct 2003 13:58:18 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLtZD6012330; Wed, 29 Oct 2003 16:58:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TLphSA015781; Wed, 29 Oct 2003 16:51:44 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9TLphMU012960; Wed, 29 Oct 2003 16:51:43 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9TLpfCa028654; Wed, 29 Oct 2003 16:51:41 -0500 Subject: Re: Agenda items to discuss From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> References: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067464301.27762.103.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 29 Oct 2003 16:51:41 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-10-29 at 13:44, Sam Hartman wrote: > * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want > to develop guidance for protocol designers on this issue? I won't be at the meeting, but I'd like to weigh in with the opinion that we shouldn't make it any harder for implementations to do dual encryption of data for defense-in-depth. It may seem redundant and expensive to encrypt or sign twice (and it's certainly fair for an implementation to avoid using a security layer if it's running over TLS), but it's not completely redundant; the keys used for one security layer may be compromisable under different assumptions than the keys used for another. For example: I make a TLS connection to an MIT server and then SASL-authenticate via GSSAPI. Unbeknownst to me, a CA trusted by my client has issued a bogus X.509 certificate for MIT to an attacker. The attacker intercepts my connection, initiates its own connection to the real MIT server, and passes through my communications so that GSSAPI authentication succeeds. If my client insists on using a SASL security layer, the attacker will not be able to modify (or perhaps even read) my communications despite having compromised TLS. I'm not sure if anyone was seriously considering disallowing dual security layers, but RFC 3080 section 4.1 does so, so it seemed worth heading off. > I think most of the other changes that have been brought forward have > been resolved; please correct me if I'm wrong. I think Greg's > comments on implementing SASL have not suggested any specific changes > to documents that need discussion. Correct; I hope my comments will be kept in mind for future work, but they don't have any ramifications for current documents. (And, apologies for the misconception about authzids. I still feel they should have appeared within the framework and not within mechanisms, but I was wrong to assume that they were specific to DIGEST-MD5.) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi6kT035183 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TIi69Z035182 for ietf-sasl-bks; Wed, 29 Oct 2003 10:44:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-NINE.MIT.EDU [18.187.6.104]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TIi5kT035177 for ; Wed, 29 Oct 2003 10:44:06 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2F80E1515E8; Wed, 29 Oct 2003 13:44:05 -0500 (EST) To: ietf-sasl@imc.org Subject: Agenda items to discuss Message-Id: <20031029184405.2F80E1515E8@konishi-polis.mit.edu> Date: Wed, 29 Oct 2003 13:44:05 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a lot of discussion on the list since the last IETF and I'm curious which issues actually need meeting time. I'd appreciate it if people could suggest issues that still seem to be open. Thing I think may be open or need discussion are: * Initial server challenges especially as they interact with SMTP * Security layer replacement in the base SASL spec * Authorization ID text (data vs blob, confusion about restriction, etc) * There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want to develop guidance for protocol designers on this issue? I think most of the other changes that have been brought forward have been resolved; please correct me if I'm wrong. I think Greg's comments on implementing SASL have not suggested any specific changes to documents that need discussion. There's also been a lot of IDN related discussion in the Kerberos working group. So far, I don't think any of that discussion affects saslprep. If any of those issues do end up affecting saslprep, we may at least want to be aware of them. I'll review those discussion within the next week. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLpCI7006906 for ; Tue, 28 Oct 2003 13:51:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLpBYq006905 for ietf-sasl-bks; Tue, 28 Oct 2003 13:51:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SLpAI7006899 for ; Tue, 28 Oct 2003 13:51:11 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa04663; 28 Oct 2003 16:50 EST Date: Tue, 28 Oct 2003 16:50:44 -0500 From: Jeffrey Hutzelman To: Greg Hudson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <1116100000.1067377844@minbar.fac.cs.cmu.edu> In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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, October 28, 2003 16:13:29 -0500 Greg Hudson wrote: > > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: >> I think the only point you raise that I disagree with is the idea that >> authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, > but they each have different passwords, so they aren't analagous to > DIGEST-MD5 authzids.) They are trivial to support by authenticating and > then transmitting the desired authzid. So they should either be part of > the protocol or part of the SASL framework, but certainly not part of > SASL mechanisms. They're not introduced by this mechanism, either. Authorization identities _are_ part of the SASL framework -- a client may optionally specify the authorization identity he wishes to assume, independent of the authentication identity provided by the mechanism. It is the responsibility of the mechanism to transport the requested authzid, if there is one. -- Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmnI7006761 for ; Tue, 28 Oct 2003 13:48:49 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLmmeA006760 for ietf-sasl-bks; Tue, 28 Oct 2003 13:48:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLmlI7006754 for ; Tue, 28 Oct 2003 13:48:47 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9SLmmk4025751; Tue, 28 Oct 2003 16:48:48 -0500 Date: Tue, 28 Oct 2003 16:48:48 -0500 (EST) From: Rob Siemborski To: Greg Hudson cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Some implementor's notes In-Reply-To: <1067375609.27762.26.camel@error-messages.mit.edu> Message-ID: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <1067375609.27762.26.camel@error-messages.mit.edu> 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: On Tue, 28 Oct 2003, Greg Hudson wrote: > On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > > I think the only point you raise that I disagree with is the idea that > > authorization IDs are not important. > > And yet, to the best of my knowledge, they are not introduced by any > mechanism other than DIGEST-MD5. In addition to DIGEST-MD5, the PLAIN, KERBEROS_V4, GSSAPI, SRP, and OTP mechanisms all support authorization identifiers. This certainly isn't something completely new introduced by DIGEST-MD5. > They are trivial to support by authenticating and then transmitting the > desired authzid. So they should either be part of the protocol or part > of the SASL framework, but certainly not part of SASL mechanisms. I admit that hindsight reveals that it would be nice for SASL to be able to support authorization ids as part of the framework -- it would solve the inconsistency introduced by CRAM-MD5. I don't think we really want to do this at the application layer either, since that repeats this work for every SASL application (having application-specific constraints on the authorization ID, however, would be fine). However, I don't think we can abandon the current deployed infrastructure to fix the SASL framework to allow this at this point. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKhI7005489 for ; Tue, 28 Oct 2003 13:20:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLKhWu005488 for ietf-sasl-bks; Tue, 28 Oct 2003 13:20:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLKfI7005483 for ; Tue, 28 Oct 2003 13:20:42 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 28 Oct 2003 21:21:06 +0000 Message-ID: <3F9EDDAB.2080804@isode.com> Date: Tue, 28 Oct 2003 21:20:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt References: <200310282045.PAA25736@ietf.org> In-Reply-To: <200310282045.PAA25736@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) > Author(s) : A. Melnikov > Filename : draft-ietf-sasl-rfc2222bis-03.txt > Pages : 11 > Date : 2003-10-28 > > The updated draft deals with most (but not all) issues raised during WG Last Call. There are some mostly editorial issues left. There was a recent discussion on IMAP mailing list about adding examples to show how to encode initial response when it is/is not supported by the protocol. I will add this in the next revision. I am not going to attend IETF in Minneapolis. What is the planned agenda for the SASL meeting in Minneapolis? Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI7I7005384 for ; Tue, 28 Oct 2003 13:18:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLI6FW005383 for ietf-sasl-bks; Tue, 28 Oct 2003 13:18:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLI5I7005378 for ; Tue, 28 Oct 2003 13:18:06 -0800 (PST) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLI6s9014556; Tue, 28 Oct 2003 16:18:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9SLDWal015702; Tue, 28 Oct 2003 16:13:32 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9SLDVEi010084; Tue, 28 Oct 2003 16:13:31 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9SLDTB9027808; Tue, 28 Oct 2003 16:13:29 -0500 Subject: Re: Some implementor's notes From: Greg Hudson To: Sam Hartman Cc: ietf-sasl@imc.org In-Reply-To: References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067375609.27762.26.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 28 Oct 2003 16:13:29 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-10-28 at 15:31, Sam Hartman wrote: > I think the only point you raise that I disagree with is the idea that > authorization IDs are not important. And yet, to the best of my knowledge, they are not introduced by any mechanism other than DIGEST-MD5. (Kerberos has multi-level principals, but they each have different passwords, so they aren't analagous to DIGEST-MD5 authzids.) They are trivial to support by authenticating and then transmitting the desired authzid. So they should either be part of the protocol or part of the SASL framework, but certainly not part of SASL mechanisms. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk5I7004151 for ; Tue, 28 Oct 2003 12:46:05 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKk5Ip004150 for ietf-sasl-bks; Tue, 28 Oct 2003 12:46:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKk2I7004144 for ; Tue, 28 Oct 2003 12:46:02 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25756; Tue, 28 Oct 2003 15:45:52 -0500 (EST) Message-Id: <200310282045.PAA25756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-03.txt Date: Tue, 28 Oct 2003 15:45:51 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-03.txt Pages : 9 Date : 2003-10-28 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160205.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjtI7004136 for ; Tue, 28 Oct 2003 12:45:55 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjtGB004135 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjrI7004130 for ; Tue, 28 Oct 2003 12:45:54 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25736; Tue, 28 Oct 2003 15:45:43 -0500 (EST) Message-Id: <200310282045.PAA25736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-03.txt Date: Tue, 28 Oct 2003 15:45:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-03.txt Pages : 11 Date : 2003-10-28 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160148.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjlI7004123 for ; Tue, 28 Oct 2003 12:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKjlS8004122 for ietf-sasl-bks; Tue, 28 Oct 2003 12:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKjjI7004115 for ; Tue, 28 Oct 2003 12:45:46 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25711; Tue, 28 Oct 2003 15:45:36 -0500 (EST) Message-Id: <200310282045.PAA25711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-04.txt Date: Tue, 28 Oct 2003 15:45:35 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-04.txt Pages : 6 Date : 2003-10-28 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28160127.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVXI7003412 for ; Tue, 28 Oct 2003 12:31:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKVXj2003411 for ietf-sasl-bks; Tue, 28 Oct 2003 12:31:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKVWI7003405 for ; Tue, 28 Oct 2003 12:31:32 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A83111515E8; Tue, 28 Oct 2003 15:31:33 -0500 (EST) To: Greg Hudson Cc: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Sam Hartman Date: Tue, 28 Oct 2003 15:31:33 -0500 In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> (Greg Hudson's message of "Mon, 13 Oct 2003 13:19:19 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Greg" == Greg Hudson writes: Greg> * It introduces the concepts of realms, subsequent Greg> authentication, and authorization IDs, none of which seem to Greg> be important functionality for a generic shared-secret Greg> authentication scheme, and all of which could (I think) be Greg> handled out of band. Fortunately, it's not too difficult to Greg> avoid supporting those features. I think the only point you raise that I disagree with is the idea that authorization IDs are not important. I can understand why an implementation might not want to use them, but I believe they are important for protocols to support and are something you will tend to want to add over time to an implementation. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHXI7074996 for ; Mon, 27 Oct 2003 13:17:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLHX22074995 for ietf-sasl-bks; Mon, 27 Oct 2003 13:17:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLHRI7074986 for ; Mon, 27 Oct 2003 13:17:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BFF3F1515E8; Mon, 27 Oct 2003 16:17:27 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> <3F867FC1.90704@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 16:17:27 -0500 In-Reply-To: <3F867FC1.90704@isode.com> (Alexey Melnikov's message of "Fri, 10 Oct 2003 10:45:37 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: >> I wonder if it might be better to not to change the protocol >> but, instead, just document the security consideration. >> Alexey> I would like to allow new protocols to allow to deinstall Alexey> the security layer when none is negotiated. RFC 2222 Alexey> prohibits this. Why do you want this? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8dI7071881 for ; Mon, 27 Oct 2003 12:08:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK8dnl071880 for ietf-sasl-bks; Mon, 27 Oct 2003 12:08:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK8cI7071871 for ; Mon, 27 Oct 2003 12:08:38 -0800 (PST) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RK7xxA009860; Mon, 27 Oct 2003 12:07:59 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9RK7v58012282; Mon, 27 Oct 2003 13:07:58 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9RK3qQx003840; Mon, 27 Oct 2003 12:03:52 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9RK3oR7003839; Mon, 27 Oct 2003 12:03:50 -0800 (PST) Date: Mon, 27 Oct 2003 12:03:50 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org Cc: nfsv4@ietf.org Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt] Message-ID: <20031027200350.GI24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org, nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Followups-To: nfsv4@ietf.org Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies for the cross-post; followups should NOT be cross-posted this widely. Please Cc ONLY the appropriate WG mailing list(s) on any replies. Since I am not subscribed to all of the relevant WGs' mailing lists, please Cc me in all replies.] The NFSv4 WG I-D on channel bindings needs review from several IETF WGs. This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02). We would appreciate feedback from the Cc'ed WGs on several areas as requested below. Please cc the appropriate WG lists only in your replies. The I-D announcement is included below, including the I-D Abstract. Thanks, Nico Review requests: - From all the cc'ed WGs, the security community in general and the [concluded] CAT WG mailing list: o Please review the generic definition of "channel bindings" in this I-D and the concept of "channel bindings" in general. (Use the CAT WG list and/or the NFSv4 WG list.) - From the IPSEC WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. o Please review the IPsec channel bindings construction. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPSP WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPS WG: o Please consider the channel bindings concept as a general solution to the problems with the iSCSI approach to security ("authenticate at iSCSI layer with x, y or z authentication technology, but delegate session integrity/confidentiality protection to IPsec"). See the introduction (section 1) of this I-D for a description of the problem with the iSCSI approach to security. (I realize that I'm late to the iSCSI party - my goal is not to affect the progression of the iSCSI I-Ds to Proposed Standard and publication as RFCs, far from it.) (Use the IPS WG list.) - From the TLS WG: o Please review the construction of channel bindings to TLS channels given in this I-D. (Use the TLS WG list.) - From the SECSH WG: o Please review the construction of channel bindings to SSHv2 channels given in this I-D. (Use the SECSH WG list.) - From the KRB WG: o Please review sections 3.3 and 4.5 of this I-D. (Use the KRB WG list.) - From the SASL WG: o Please review section 3.2 of this I-D. (Use the SASL WG list.) ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 24 Oct 2003 10:50:50 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt To: IETF-Announce: ; Cc: nfsv4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : On the Use of Channel Bindings to Secure Channels Author(s) : N. Williams Filename : draft-ietf-nfsv4-channel-bindings-00.txt Pages : 14 Date : 2003-10-23 This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-channel-bindings-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2dI7071665 for ; Mon, 27 Oct 2003 12:02:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RK2deT071664 for ietf-sasl-bks; Mon, 27 Oct 2003 12:02:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RK2cI7071659 for ; Mon, 27 Oct 2003 12:02:38 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E4D781515EB; Mon, 27 Oct 2003 15:02:37 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 15:02:37 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 27 Oct 2003 20:21:02 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Alexey Melnikov writes: >> Hallvard B Furuseth wrote: >>> Alexey Melnikov writes: >>>> Hallvard B Furuseth wrote: >>>>>> 4.1. Authentication protocol exchange >>> Anyway, I think I found the answer in section 6.1. The >>> initial auth command from the client is not part of the >>> exchange, but the optional "response" in the auth command is. >>> >> Sorry, this makes little sense to me. Semantically the initial >> response *is* part of an authentication exchange. Hallvard> That's what I wrote. >>>>>> 4.2. Authorization identities and proxy authentication >>>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an >>>>>> authorization >>>>> identity over protocol is specified in each authentication >>>>>> mechanism >>>>> (with the authentication mechanism's blob being further >>>>> ^^^^ >>>>> >>>>> What's a blob? I don't think it's 'something ill-defined or >>>>> amorphous', like the dictionary says:-) >>>>> >>>> I've changed this to "data". >>> I still don't know _which_ data you are talking about. >>> >> Data is defined (and specific to) by each SASL mechanism. Hallvard> Is the text in the ()'s just saying that the SASL Hallvard> mechanism restricts the data sent between client and Hallvard> server to more than just being random strings in the Hallvard> character encoding scheme? Well, of course. Why Hallvard> mention that at all? If not, I still don't understand Hallvard> what this () is saying. Because you want to make it clear to application protocol designers and SASL library implementers that mechanisms will be expected to restrict this data. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnGI7071153 for ; Mon, 27 Oct 2003 11:49:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJnGCK071152 for ietf-sasl-bks; Mon, 27 Oct 2003 11:49:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-SIX.MIT.EDU [18.187.5.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJnFI7071147 for ; Mon, 27 Oct 2003 11:49:15 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1BDD1515EA; Mon, 27 Oct 2003 14:49:10 -0500 (EST) To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> From: Sam Hartman Date: Mon, 27 Oct 2003 14:49:10 -0500 In-Reply-To: <3F919B07.6050909@isode.com> (Alexey Melnikov's message of "Sat, 18 Oct 2003 20:56:55 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> IMHO, as a server writer, I would do (2) anyway. But of Alexey> course this is my personal opinion. This needs to be left up to individual mechanisms. The server definitely should not do this. I can think of mechanisms where doing (2) will break signatures of data, etc. For plain, I would probably do all three as you suggest. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPCI7069974 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJPCP5069973 for ietf-sasl-bks; Mon, 27 Oct 2003 11:25:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJPBI7069966 for ; Mon, 27 Oct 2003 11:25:12 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1AECzG-0005M0-Be; Mon, 27 Oct 2003 20:25:10 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1AECzD-0004YS-Ja; Mon, 27 Oct 2003 20:25:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECzD-00025o-00; Mon, 27 Oct 2003 20:25:07 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token In-Reply-To: <3F8D308B.5050208@isode.com> References: <3F8D308B.5050208@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:25:07 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2831bis 2.1.1 "Step One" says: >> >> qop-options = "qop" "=" <"> qop-list <"> >> qop-list = 1#qop-value >> qop-value = "auth" | "auth-int" | "auth-conf" | >> token >> >>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >>"auth", "auth-int" and "auth-conf", but not when it is . > > Token is specifically for future extensions, if you see a qop value you > don't recognize - you have to ignore it. > If you recognize nothing, you have to fail the authentication exchange. > > Do you want any clarifications on this to be added to the document. Not sure. I think it would be good to mention that 'token is for future extensions' somewhere. And perhaps that these extensions must define A2, since rfc2831bis does not. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNJI7069893 for ; Mon, 27 Oct 2003 11:23:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJNIm9069892 for ietf-sasl-bks; Mon, 27 Oct 2003 11:23:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJNHI7069885 for ; Mon, 27 Oct 2003 11:23:18 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECxQ-00059f-K2; Mon, 27 Oct 2003 20:23:16 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECxN-0004NX-58; Mon, 27 Oct 2003 20:23:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECxM-00025m-00; Mon, 27 Oct 2003 20:23:12 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer In-Reply-To: <3F8D34E4.4020607@isode.com> References: <3F8D34E4.4020607@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:23:12 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>rfc2222bis section 6.3 "Multiple authentications" says: >> >> If a security layer is in effect >> and a subsequent SASL negotiation selects a second security layer, >> then the second security layer replaces the first. If a security >> layer is in effect and a subsequent SASL negotiation selects no >> security layer, the original security layer must be removed. >> >>Exactly when is the old layer canceled? >> >>If an old layer is active and the client starts to negotiate a new >>layer, it may not know when to expect the response from the server. >>So the layer can't be canceled by starting a new negotiation. >> > No, the layer can only be cancelled/replaced after a subsequent > authentication completes successfully. OK. Please mention that explicitly. > Each profile document must document exactly when this takes place. 'this' = 'it completed successfully', I take it. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL8I7069814 for ; Mon, 27 Oct 2003 11:21:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJL8U0069813 for ietf-sasl-bks; Mon, 27 Oct 2003 11:21:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJL6I7069806 for ; Mon, 27 Oct 2003 11:21:07 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1AECvJ-0004vJ-MX; Mon, 27 Oct 2003 20:21:05 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AECvG-0006ok-AO; Mon, 27 Oct 2003 20:21:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECvG-00025S-00; Mon, 27 Oct 2003 20:21:02 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F915345.8070201@isode.com> References: <3F83FA6D.1030909@isode.com> <3F915345.8070201@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:21:02 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: >>Alexey Melnikov writes: >>>Hallvard B Furuseth wrote: >>> >>>>>4.1. Authentication protocol exchange >>Anyway, I think I found the answer in section 6.1. The initial auth >>command from the client is not part of the exchange, but the optional >>"response" in the auth command is. >> > Sorry, this makes little sense to me. > Semantically the initial response *is* part of an authentication > exchange. That's what I wrote. >>>>>4.2. Authorization identities and proxy authentication >>>>> >>>>> (...) >>>>> The character encoding scheme used for transmitting an authorization >>>>> identity over protocol is specified in each authentication mechanism >>>>> (with the authentication mechanism's blob being further >>>> ^^^^ >>>> >>>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>>like the dictionary says:-) >>>> >>>I've changed this to "data". >> >>I still don't know _which_ data you are talking about. >> > Data is defined (and specific to) by each SASL mechanism. Is the text in the ()'s just saying that the SASL mechanism restricts the data sent between client and server to more than just being random strings in the character encoding scheme? Well, of course. Why mention that at all? If not, I still don't understand what this () is saying. >>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>>top. >>>> >>>I've added a sentence about this in the introduction section. >> >>I'm pretty sure you will still need to insert the words "Obsoletes: rfc >>2222" in the header sometime, though I don't remember where this is >>stated. >> > I think this is going to be added by a RFC editor. > > I couldn't find anything saying so. I did find rfc2223 (Instructions > to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks > you to insert. rfc2223 does say that the RFC Editor may make some > changes, but preferably as few as possible, and it doesn't mention > that one. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFQI7069534 for ; Mon, 27 Oct 2003 11:15:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJFQxt069533 for ietf-sasl-bks; Mon, 27 Oct 2003 11:15:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJFPI7069525 for ; Mon, 27 Oct 2003 11:15:25 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1AECpm-0004Ni-Ps; Mon, 27 Oct 2003 20:15:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1AECpk-0005yD-Mz; Mon, 27 Oct 2003 20:15:20 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECpj-00025D-00; Mon, 27 Oct 2003 20:15:19 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F919D54.7070306@isode.com> References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> <3F919D54.7070306@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:15:19 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > >>>>> In > >>>>> order to avoid noninteroperability due to differing normalizations, > >>>>> when a mechanism specifies that a string authentication identity or > >>>>> password used as input to a cryptographic function (or used for > >>>>> comparison) it SHOULD specify that the string first be prepared using > >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm > >>>>> [StringPrep]. > >>>> > The new text after that reads: > > There are three entities that has to deal with this issue: a client > (upon getting user input or retrieving a value from configuration), a server > (upon receiving the value from the client) and a utility that is able to > store > passwords/hashes in a database that can be later used by the server. > The preparation must be done by the client and the utility and may be > done by the > server. If preparation fails or results in an empty string, the entity doing > the preparation SHALL fail the authentication exchange. I like Kurt's suggestion better: The mechanism must define where preparation is done. That way clients using mechanisms like PLAIN can leave as much work as possible to the server. >>> Alexey, the current text suggests that client (1) prep the >>> value before sending, the server then preps it (2) again >>> (before comparing it to the store value, which also should >>> be prep'ed (3) either before storing it or before each compare). >> >> Ok, I am with you now. >> >> IMHO, as a server writer, I would do (2) anyway. But of course this is >> my personal opinion. I see no reason to prepare a string which we know already has been prepared (if the client works correctly). I guess it doesn't hurt to allow that, but what you are saying is that if the client sends incorrect data (it doesn't prepare when it should do so), auth on your server would succeed anyway. Put that way, I'm not sure if that is a bug or a feature. BTW, the server can't do (2) with mechanisms like DIGEST-MD5, where it never sees the plain password from the client. I got that wrong too in my original message. >>> We should not suggest that mechanisms should do both (1) and >>> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >>> proper matching. >> >> IMHO, this is a responsibility of the client, Disagree. It's the responsibility of the mechanism defintion to say where it should happen. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3wI7068824 for ; Mon, 27 Oct 2003 11:03:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RJ3w5U068823 for ietf-sasl-bks; Mon, 27 Oct 2003 11:03:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJ3pI7068808 for ; Mon, 27 Oct 2003 11:03:52 -0800 (PST) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AECec-0003C4-9J; Mon, 27 Oct 2003 20:03:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AECeZ-00026i-JM; Mon, 27 Oct 2003 20:03:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AECeZ-00023k-00; Mon, 27 Oct 2003 20:03:47 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: rfc2831bis issues In-Reply-To: <3F9C2F32.1060004@isode.com> References: <3F9C2F32.1060004@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 27 Oct 2003 20:03:47 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>1.1 Conventions and Notation >>> >>> This specification uses the same ABNF notation and lexical >>> conventions as HTTP/1.1 specification; see section 7. >> >>...as well as some named rules defined there (section 7.2). >> > 7 implies 7.2. True. Please add '...and named rules', though. Those are not notation or lexical conventions. >>> The value of a quoted string constant as an octet string does not >>> include any terminating null character >> >>...which the C language adds. >> >>[For readers who don't know C, if any.] >> > IMHO, readers who don't know C will not care about this comment anyway, > because it doesn't add any additional information. Disagree. For such readers, this comment adds a confusing reference to a null character which they can't find elsewhere in the draft. It might be better to just delete the sentence, though. >>>2.1.1 Step One >>> >>> The server starts by sending a challenge. >> >>How does it know that it should do that? >> > The client always starts first (according to SASL). If the client > doesn't includes an initial response, the server will know. > > Can you suggest any clarification text here? 'The server starts by sending a challenge after the client indicates that SASL negotiatin should start'? >>>2.1.2 Step Two >>> authzid >>> >>> >>> The server SHOULD verify the correctness of an authzid as >>> specified by the corresponding SASL protocol profile. >>> >>> >> >>Which corresponding SASL profile? >> > I meant that any protocol using SASL should verify authorization > identity as specified in the SASL profile for the protocol. Any > suggestion how to make this clear? Using your words, The server SHOULD verify the correctness of an authzid as specified by the SASL profile for the protocol. >>>2.2 Subsequent Authentication >>> >>> If the client has previously authenticated to the server, and >>> remembers the values of username, realm, nonce, nonce-count, cnonce, >> ^^^^^^^^ >>> and qop that it used in that authentication, and the SASL profile for >>> a protocol permits an initial client response, then it MAY perform >>> "subsequent authentication", as defined in this section. >> >>What's the point of authenticating again with the same username? Auth >>with a _different_ username would be more interesting. >> > This is a case of fast reauthentication using a different TCP > connection. This is similar to resuming a TLS session. Oh. Could you add 'even after closing the connection and reopening a new one' in section 2.2? >>>2.2.2 Step Two >>> >>> If the response is valid, (...) >> >>I don't understand the text starting with "or from any o". >> > The text in my copy says: > > (...) Thanks. > So I am not sure where have you found this. It's in http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt. >>> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >>> received value; the message is discarded if they differ. >>> (...) >> > This whole section talks about protecting data when authentication is > already complete. Not in the published draft. There, this sentence occurs in section 2.2.2. But there is no section between 2.2.2 and 2.4, so I guess this part of the published draft got garbled. >>>7.2 Basic Rules >> >>> OCTET = >> >>s/character/byte/, I think. >> > I actually disagree in this case. A byte has 8 bits by definition. No it hasn't. That's why the term 'octet' was invented. A byte is an addressable machine unit, which is _usually_ 8 bits nowadays. >> A byte in a multi-byte UTF-8 character >>is not normally considered a character. >> > I am not talking about Unicode characters here. A 'character' is part of a character set. Which character set is it supposed to be part of here, if not UTF-8? Maybe you are thinking of C, where the 'byte' type is called (unsigned) char? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB84I7043644 for ; Mon, 27 Oct 2003 03:08:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RB84Cl043643 for ietf-sasl-bks; Mon, 27 Oct 2003 03:08:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RB7tI7043626 for ; Mon, 27 Oct 2003 03:08:02 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Mon, 27 Oct 2003 11:08:03 +0000 Message-ID: <3F9C2F32.1060004@isode.com> Date: Sun, 26 Oct 2003 20:31:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis issues References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Here are various editorial and non-editorial comments for >draft-ietf-sasl-rfc2831bis-02.txt. > > >>Table of Contents >> >> >> 3.8 CBC MODE ATTACKS............................................. >> >> > >Missing page number. > Yes, I was lazy. I was changing text a lot, so I had to spend a lot of time fixing page numbers when doing each revision. So I just gave up. >>1.1 Conventions and Notation >> >> >> This specification uses the same ABNF notation and lexical >> conventions as HTTP/1.1 specification; see section 7. >> >> > >...as well as some named rules defined there (section 7.2). > 7 implies 7.2. >> The value of a quoted string constant as an octet string does not >> include any terminating null character >> >> > >...which the C language adds. > >[For readers who don't know C, if any.] > > IMHO, readers who don't know C will not care about this comment anyway, because it doesn't add any additional information. >>2.1.1 Step One >> >> The server starts by sending a challenge. >> >> > >How does it know that it should do that? > The client always starts first (according to SASL). If the client doesn't includes an initial response, the server will know. Can you suggest any clarification text here? >> nonce >> Note >> that since the string is passed as a quoted string, the >> double-quote >> >> > >and backslash? > Actually, I've changed ABNF to disallow double-quotes or backslashes. So, this should be removed. >> character is not allowed unless escaped (see section >> 7.2). >> >> > >I think this applies to other quoted strings than the nonce. > Yes, but it is especially problematic for nonces, as people just generate binary data and than forget to quote it. >> server_maxbuf ("maximal ciphertext buffer size") >> >> > > > >> Let call "maximal cleartext buffer size" (or "maximal sender >> size") the maximal size of a cleartext buffer that, after being >> >> > >"Let call"? Should be "Call", or "Let .... be", I think. > Ok. >> charset >> This directive, if present, specifies that the server supports >> UTF-8 [UTF-8] encoding for the username, realm and password. If >> present, the username, realm and password are in Unicode, prepared >> using the "SASLPrep" profile [SASLPrep] of the "stringprep" >> algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not >> present, the username, realm and password MUST be encoded in ISO >> 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). >> >> > >There is no username and password sent by the server. Do you mean the >_client_ MUST send them in UTF-8 if "charset" is given by the server? > Yes. >> cipher-opts >> >> >> "qop-options" directive, in which case the "3des" cipher is >> mandatory-to-implement. >> >> > >I suggest you remove the "-"s in mandatory-to-implement. > This is a term used in SASL. By using "-" I am trying to emphasize this. >>2.1.2 Step Two >> >> >> digest-uri >> Indicates the principal name of the service with which the client >> wishes to connect, formed from the serv-type, host, and serv-name. >> For example, the FTP service on "ftp.example.com" would have a >> "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from >> the example above would have a "digest-uri" value of >> "SMTP/mail3.example.com/example.com". >> >> Servers SHOULD check that the supplied value is correct. This will >> detect accidental connection to the incorrect server, as well as some >> redirection attacks. It is also so that clients will be trained to >> provide values that will work with implementations that use a shared >> back-end authentication service that can provide server >> authentication. >> >> The serv-type component should match the service being offered. The >> host component should match one of the host names of the host on >> which the service is running, or it's IP address. Servers SHOULD NOT >> normally support the IP address form, because server authentication >> by IP address is not very useful; they should only do so if the DNS >> is unavailable or unreliable. The serv-name component should match >> one of the service's configured service names. >> >> This directive may appear at most once; if multiple instances are >> present, the client should abort the authentication exchange. >> >> Note: In the HTTP use of Digest authentication, the digest-uri is the >> URI (usually a URL) of the resource requested -- hence the name of >> the directive. >> >> > >Is this entire section about digest-uri? If so, most of it should be >indented. > > >> authzid >> >> >> The server SHOULD verify the correctness of an authzid as >> specified by the corresponding SASL protocol profile. >> >> > >Which corresponding SASL profile? > I meant that any protocol using SASL should verify authorization identity as specified in the SASL profile for the protocol. Any suggestion how to make this clear? >>2.2 Subsequent Authentication >> >> If the client has previously authenticated to the server, and >> remembers the values of username, realm, nonce, nonce-count, cnonce, >> >> > ^^^^^^^^ > > >> and qop that it used in that authentication, and the SASL profile for >> a protocol permits an initial client response, then it MAY perform >> "subsequent authentication", as defined in this section. >> >> > >What's the point of authenticating again with the same username? Auth >with a _different_ username would be more interesting. > This is a case of fast reauthentication using a different TCP connection. This is similar to resuming a TLS session. >>2.2.2 Step Two >> >> >> If the response is valid, the server MAY choose to deem that >> authentication has succeeded. However, if it has been too long since >> the previous authentication, or for any o including the next >> subsequent authentication, between the client and the server MUST be >> integrity protected. >> >> > >I don't understand the text starting with "or from any o". > The text in my copy says: If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication. So I am not sure where have you found this. >> Using as a base session key the value of H(A1) >> as defined above >> >> > >need a "," here > Ok. >> Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the >> received value; the message is discarded if they differ. >> >> The >> receiver's sequence counter is incremented if they match. >> >> > >Doesn't the server send a response? How does the client know that the >authentication is completed? > This whole section talks about protecting data when authentication is already complete. > ... > >>5.1 Normative references >> >> >> [RFC 2222] Myers, J., "Simple Authentication and Security Layer >> (SASL)", RFC 2222, October 1997. >> >> > >Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > Fixed, thanks. >... > >> ( *LWS element *( *LWS "," *LWS element )) >> >> > >Should this really be asymmetric, or should it be > ( element *( *LWS "," *LWS element )) >or > ( *LWS element *( *LWS "," *LWS element ) *LWS ) > I can go for the last proposal. At least it seems to be the original intent. >? > > > >>7.2 Basic Rules >> >> > > > >> OCTET = >> >> > >s/character/byte/, I think. > I actually disagree in this case. A byte has 8 bits by definition. > A byte in a multi-byte UTF-8 character >is not normally considered a character. > I am not talking about Unicode characters here. Thank you for your comments. In the meantime I will work (and think more) on the rest of them. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEDI7062616 for ; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NDEDrr062615 for ietf-sasl-bks; Thu, 23 Oct 2003 06:14:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDEBI7062603 for ; Thu, 23 Oct 2003 06:14:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17392; Thu, 23 Oct 2003 09:14:02 -0400 (EDT) Message-Id: <200310231314.JAA17392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-08.txt Date: Thu, 23 Oct 2003 09:14:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-08.txt Pages : 37 Date : 2003-10-22 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nystrom-http-sasl-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nystrom-http-sasl-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183614.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAsI7029921 for ; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IKAsvw029920 for ietf-sasl-bks; Sat, 18 Oct 2003 13:10:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKAnI7029911 for ; Sat, 18 Oct 2003 13:10:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:10:59 +0100 Message-ID: <3F919E3C.2040504@isode.com> Date: Sat, 18 Oct 2003 21:10:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >Simon raised this issue to me privately... but I think it needs >broader discussion (given that it is a technical issue). > >At 02:19 PM 10/2/2003, Simon Josefsson wrote: > > >>* The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing). >> >> > >That is, what should the implementation do if the message it receives >is malformed? > >I note that this issue is likely not unique to ANONYMOUS. So, maybe >it should be dealt with in base SASL specification. > >I'm thinking a malformed message should be treated as a protocol >error in the application protocol. > I agree. However, can you be more specific what do you want me to add to the base spec. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6rI7029838 for ; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IK6rm5029837 for ietf-sasl-bks; Sat, 18 Oct 2003 13:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IK6lI7029831 for ; Sat, 18 Oct 2003 13:06:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 21:07:07 +0100 Message-ID: <3F919D54.7070306@isode.com> Date: Sat, 18 Oct 2003 21:06:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> <3F919B07.6050909@isode.com> In-Reply-To: <3F919B07.6050909@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > >>>>> In >>>>> order to avoid noninteroperability due to differing normalizations, >>>>> when a mechanism specifies that a string authentication identity or >>>>> password used as input to a cryptographic function (or used for >>>>> comparison) it SHOULD specify that the string first be prepared using >>>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>>> [StringPrep]. >>>> The new text after that reads: There are three entities that has to deal with this issue: a client (upon getting user input or retrieving a value from configuration), a server (upon receiving the value from the client) and a utility that is able to store passwords/hashes in a database that can be later used by the server. The preparation must be done by the client and the utility and may be done by the server. If preparation fails or results in an empty string, the entity doing the preparation SHALL fail the authentication exchange. >>>>> This should be done by both the client (upon getting >>>>> user input or retrieving a value from configuration) and by the >>>>> server (upon receiving the value from the client). >>>>> >>>> >>>> What's the point of this duplicate preparation? Why not do it only >>>> at the server side? >>> >>> Because if the client doesn't do that, the hash calculated on the >>> server will not match the one calculated on the client. >> >> Alexey, the current text suggests that client (1) prep the >> value before sending, the server then preps it (2) again >> (before comparing it to the store value, which also should >> be prep'ed (3) either before storing it or before each compare). > > Ok, I am with you now. > > IMHO, as a server writer, I would do (2) anyway. But of course this is > my personal opinion. > > However there is one case when all three may make sense. Imagine that > there are two clients that use PLAIN. > One of the prepares username/password, the other one doesn't. If the > server also does preparation, it will be able to interoperate with > both clients. > >> We need to REQUIRE that mechanisms specify how character strings >> are to be prepared for comparison and RECOMMEND that they use >> SASLprep for simple user names and passwords. >> >> We should not suggest that mechanisms should do both (1) and >> (2). (1) and (3) OR (2) or (3) are sufficient to ensure >> proper matching. > > IMHO, this is a responsibility of the client, so I will clarify that. > But I will add that the server "MAY prepare". Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJvAI7029677 for ; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IJvAxB029676 for ietf-sasl-bks; Sat, 18 Oct 2003 12:57:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IJv4I7029670 for ; Sat, 18 Oct 2003 12:57:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 20:57:18 +0100 Message-ID: <3F919B07.6050909@isode.com> Date: Sat, 18 Oct 2003 20:56:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 04:52 AM 10/8/2003, Alexey Melnikov wrote: > > >>>> In >>>> order to avoid noninteroperability due to differing normalizations, >>>> when a mechanism specifies that a string authentication identity or >>>> password used as input to a cryptographic function (or used for >>>> comparison) it SHOULD specify that the string first be prepared using >>>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>>> [StringPrep]. This should be done by both the client (upon getting >>>> user input or retrieving a value from configuration) and by the >>>> server (upon receiving the value from the client). >>>> >>>> >>>> >>>What's the point of this duplicate preparation? Why not do it only >>>at the server side? >>> >>> >>> >>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> > >Alexey, the current text suggests that client (1) prep the >value before sending, the server then preps it (2) again >(before comparing it to the store value, which also should >be prep'ed (3) either before storing it or before each compare). > Ok, I am with you now. IMHO, as a server writer, I would do (2) anyway. But of course this is my personal opinion. However there is one case when all three may make sense. Imagine that there are two clients that use PLAIN. One of the prepares username/password, the other one doesn't. If the server also does preparation, it will be able to interoperate with both clients. > >We need to REQUIRE that mechanisms specify how character strings >are to be prepared for comparison and RECOMMEND that they use >SASLprep for simple user names and passwords. > >We should not suggest that mechanisms should do both (1) and >(2). (1) and (3) OR (2) or (3) are sufficient to ensure >proper matching. > IMHO, this is a responsibility of the client, so I will clarify that. But I will add that the server "MAY prepare". Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh7I7026999 for ; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IIh72l026998 for ietf-sasl-bks; Sat, 18 Oct 2003 11:43:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IIh5I7026992 for ; Sat, 18 Oct 2003 11:43:06 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Sat, 18 Oct 2003 19:43:25 +0100 Message-ID: <3F915345.8070201@isode.com> Date: Sat, 18 Oct 2003 15:50:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: <3F83FA6D.1030909@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Alexey Melnikov writes: > > >>Hallvard B Furuseth wrote: >> >> >>>>4.1. Authentication protocol exchange >>>> >>>> A SASL mechanism is responsible for conducting an authentication >>>> protocol exchange. This consists of a series of server challenges >>>> and client responses, >>>> >>>> >>>> >>>Does this mean that the initial auth command from the client is not >>>considered part of the authentication protocol exchange? >>> >>> >>> >>Does it matter in this section? >> > >Well, that's where "authentication protocol exchange" seems to be >defined. It matters if other documents refer to "the authentication >protocol exchange". > >Anyway, I think I found the answer in section 6.1. The initial auth >command from the client is not part of the exchange, but the optional >"response" in the auth command is. > Sorry, this makes little sense to me. Semantically the initial response *is* part of an authentication exchange. It is just an optimization to avoid a round trip. > > >>>>4.2. Authorization identities and proxy authentication >>>> >>>> (...) >>>> The character encoding scheme used for transmitting an authorization >>>> identity over protocol is specified in each authentication mechanism >>>> (with the authentication mechanism's blob being further >>>> >>>> >>> ^^^^ >>> >>>What's a blob? I don't think it's 'something ill-defined or amorphous', >>>like the dictionary says:-) >>> >>> >>I've changed this to "data". >> >> > >I still don't know _which_ data you are talking about. > > Data is defined (and specific to) by each SASL mechanism. >>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>>top. >>> >>> >>> >>I've added a sentence about this in the introduction section. >> >> > >I'm pretty sure you will still need to insert the words "Obsoletes: rfc >2222" in the header sometime, though I don't remember where this is >stated. > I think this is going to be added by a RFC editor. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq9I7073626 for ; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBq93X073625 for ietf-sasl-bks; Wed, 15 Oct 2003 04:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBq7I7073620 for ; Wed, 15 Oct 2003 04:52:08 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:52:08 +0100 Message-ID: <3F8D34E4.4020607@isode.com> Date: Wed, 15 Oct 2003 12:52:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2222bis: re-negotiating SASL security layer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2222bis section 6.3 "Multiple authentications" says: > > If a security layer is in effect > and a subsequent SASL negotiation selects a second security layer, > then the second security layer replaces the first. If a security > layer is in effect and a subsequent SASL negotiation selects no > security layer, the original security layer must be removed. > >Exactly when is the old layer canceled? > >If an old layer is active and the client starts to negotiate a new >layer, it may not know when to expect the response from the server. >So the layer can't be canceled by starting a new negotiation. > No, the layer can only be cancelled/replaced after a subsequent authentication completes successfully. Each profile document must document exactly when this takes place. A subsuquent authentication takes place while an old security layer is still in effect. >It could be canceled after receipt of the first response from the >server. Or after the completed SASL negotiation, which would be >performed with the old layer in effect. I don't know how easy that >would be to implement, or if it would interfere with the definitions of >some SASL mechanisms to have two mechanisms active at the same time. > >Another way would for the layers themselves contain a 'cancel layer' >operation, which may only be used just before negotiating a new layer >and before closing the connection. Then the SASL negotiation could be >performed without mixing the old and the new SASL mechanism, and the >layer could only be re-negotiated if the old layer had such a 'cancel >layer' operation. > > Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXZI7073224 for ; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBXZT0073223 for ietf-sasl-bks; Wed, 15 Oct 2003 04:33:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBXYI7073218 for ; Wed, 15 Oct 2003 04:33:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 15 Oct 2003 12:33:36 +0100 Message-ID: <3F8D308B.5050208@isode.com> Date: Wed, 15 Oct 2003 12:33:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: rfc2831bis: A2 when qop-value=token References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >rfc2831bis 2.1.1 "Step One" says: > > qop-options = "qop" "=" <"> qop-list <"> > qop-list = 1#qop-value > qop-value = "auth" | "auth-int" | "auth-conf" | > token > >2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is >"auth", "auth-int" and "auth-conf", but not when it is . > Hi Hallvard, Token is specifically for future extensions, if you see a qop value you don't recognize - you have to ignore it. If you recognize nothing, you have to fail the authentication exchange. Do you want any clarifications on this to be added to the document. (I will go through your big message over weekend). Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVOI7073131 for ; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FBVO6x073130 for ietf-sasl-bks; Wed, 15 Oct 2003 04:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBVMI7073120 for ; Wed, 15 Oct 2003 04:31:23 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9js8-0006Cl-JA for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:20 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9js5-0005N7-KS for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9js5-0006IA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 13:31:17 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: re-negotiating SASL security layer Date: Wed, 15 Oct 2003 13:31:17 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis section 6.3 "Multiple authentications" says: If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer must be removed. Exactly when is the old layer canceled? If an old layer is active and the client starts to negotiate a new layer, it may not know when to expect the response from the server. So the layer can't be canceled by starting a new negotiation. It could be canceled after receipt of the first response from the server. Or after the completed SASL negotiation, which would be performed with the old layer in effect. I don't know how easy that would be to implement, or if it would interfere with the definitions of some SASL mechanisms to have two mechanisms active at the same time. Another way would for the layers themselves contain a 'cancel layer' operation, which may only be used just before negotiating a new layer and before closing the connection. Then the SASL negotiation could be performed without mixing the old and the new SASL mechanism, and the layer could only be re-negotiated if the old layer had such a 'cancel layer' operation. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwXI7072093 for ; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FAwX2N072092 for ietf-sasl-bks; Wed, 15 Oct 2003 03:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAwVI7072086 for ; Wed, 15 Oct 2003 03:58:31 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9jMK-0002Bu-Qs for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:28 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9jMG-0006WN-Em for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:24 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9jMB-0006DA-00 for ietf-sasl@imc.org; Wed, 15 Oct 2003 12:58:19 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis: A2 when qop-value=token Date: Wed, 15 Oct 2003 12:58:19 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2831bis 2.1.1 "Step One" says: qop-options = "qop" "=" <"> qop-list <"> qop-list = 1#qop-value qop-value = "auth" | "auth-int" | "auth-conf" | token 2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is "auth", "auth-int" and "auth-conf", but not when it is . -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfcI7064250 for ; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EKfcsS064249 for ietf-sasl-bks; Tue, 14 Oct 2003 13:41:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKfaI7064242 for ; Tue, 14 Oct 2003 13:41:37 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Vz5-0007Y2-J3 for ietf-sasl@imc.org; Tue, 14 Oct 2003 22:41:35 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9Vz4-0006b5-5H; Tue, 14 Oct 2003 22:41:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Vz3-00041y-00; Tue, 14 Oct 2003 22:41:33 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2831bis issues Date: Tue, 14 Oct 2003 22:41:33 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are various editorial and non-editorial comments for draft-ietf-sasl-rfc2831bis-02.txt. > Table of Contents > 3.8 CBC MODE ATTACKS............................................. Missing page number. > 1.1 Conventions and Notation > This specification uses the same ABNF notation and lexical > conventions as HTTP/1.1 specification; see section 7. ...as well as some named rules defined there (section 7.2). > The value of a quoted string constant as an octet string does not > include any terminating null character ...which the C language adds. [For readers who don't know C, if any.] > 2.1.1 Step One > > The server starts by sending a challenge. How does it know that it should do that? > nonce > Note > that since the string is passed as a quoted string, the > double-quote and backslash? > character is not allowed unless escaped (see section > 7.2). I think this applies to other quoted strings than the nonce. > server_maxbuf ("maximal ciphertext buffer size") > Let call "maximal cleartext buffer size" (or "maximal sender > size") the maximal size of a cleartext buffer that, after being "Let call"? Should be "Call", or "Let .... be", I think. > charset > This directive, if present, specifies that the server supports > UTF-8 [UTF-8] encoding for the username, realm and password. If > present, the username, realm and password are in Unicode, prepared > using the "SASLPrep" profile [SASLPrep] of the "stringprep" > algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not > present, the username, realm and password MUST be encoded in ISO > 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). There is no username and password sent by the server. Do you mean the _client_ MUST send them in UTF-8 if "charset" is given by the server? > cipher-opts > "qop-options" directive, in which case the "3des" cipher is > mandatory-to-implement. I suggest you remove the "-"s in mandatory-to-implement. > 2.1.2 Step Two > digest-uri > Indicates the principal name of the service with which the client > wishes to connect, formed from the serv-type, host, and serv-name. > For example, the FTP service on "ftp.example.com" would have a > "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from > the example above would have a "digest-uri" value of > "SMTP/mail3.example.com/example.com". > > Servers SHOULD check that the supplied value is correct. This will > detect accidental connection to the incorrect server, as well as some > redirection attacks. It is also so that clients will be trained to > provide values that will work with implementations that use a shared > back-end authentication service that can provide server > authentication. > > The serv-type component should match the service being offered. The > host component should match one of the host names of the host on > which the service is running, or it's IP address. Servers SHOULD NOT > normally support the IP address form, because server authentication > by IP address is not very useful; they should only do so if the DNS > is unavailable or unreliable. The serv-name component should match > one of the service's configured service names. > > This directive may appear at most once; if multiple instances are > present, the client should abort the authentication exchange. > > Note: In the HTTP use of Digest authentication, the digest-uri is the > URI (usually a URL) of the resource requested -- hence the name of > the directive. Is this entire section about digest-uri? If so, most of it should be indented. > authzid > The server SHOULD verify the correctness of an authzid as > specified by the corresponding SASL protocol profile. Which corresponding SASL profile? > 2.2 Subsequent Authentication > > If the client has previously authenticated to the server, and > remembers the values of username, realm, nonce, nonce-count, cnonce, ^^^^^^^^ > and qop that it used in that authentication, and the SASL profile for > a protocol permits an initial client response, then it MAY perform > "subsequent authentication", as defined in this section. What's the point of authenticating again with the same username? Auth with a _different_ username would be more interesting. > 2.2.2 Step Two > If the response is valid, the server MAY choose to deem that > authentication has succeeded. However, if it has been too long since > the previous authentication, or for any o including the next > subsequent authentication, between the client and the server MUST be > integrity protected. I don't understand the text starting with "or from any o". > Using as a base session key the value of H(A1) > as defined above need a "," here > Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the > received value; the message is discarded if they differ. The > receiver's sequence counter is incremented if they match. Doesn't the server send a response? How does the client know that the authentication is completed? > 2.4 Confidentiality Protection > > If the server sent a "cipher-opts" directive and the client responded > with a "cipher" directive, then subsequent messages between the > client and the server MUST be confidentiality protected. What is confidentiality protection? > The IV used to send/receive the initial buffer You might say "Initialization Vector (IV)" again here, it's been a while since you mentined what an IV is. > SEAL(Ki, Kc, SeqNum, msg) = > {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001, > SeqNum} SEAL? That is never used in this document. > 5.1 Normative references > [RFC 2222] Myers, J., "Simple Authentication and Security Layer > (SASL)", RFC 2222, October 1997. Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt. > [Unicode] The Unicode Consortium, "The Unicode Standard, Version Indent "The". > [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC > 2279, Janyary 1998. Indent "Yergeau". > [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Unindent "Hinden". > [FIPS] National Institute of Standards and Technology, "DES Modes of Indent "National". > [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", Indent "Daemen". > 5.2 Informative references > [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", Indent "Kaliski". > [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: Indent "Moeller". > 7.1 Augmented BNF Since <"> means to enclose a literal, you might replace other <">s with <'>s in this section. E.g. > rule1 | rule2 > Elements separated by a bar ("|") are alternatives, e.g., "yes | > no" will accept yes or no. Elements separated by a bar ('|') are alternatives, e.g., 'yes | no' will accept yes or no. > #rule > ( *LWS element *( *LWS "," *LWS element )) Should this really be asymmetric, or should it be ( element *( *LWS "," *LWS element )) or ( *LWS element *( *LWS "," *LWS element ) *LWS ) ? > 7.2 Basic Rules > OCTET = s/character/byte/, I think. A byte in a multi-byte UTF-8 character is not normally considered a character. > 8 Sample Code > for (scan = base; scan < end; ++scan) { > if (*scan > 0xC3) break; /* abort if outside 8859-1 */ > if (*scan >= 0xC0 && *scan <= 0xC3) { > if (++scan == end || *scan < 0x80 || *scan > 0xBF) > break; /* * Handle invalid UTF-8-like sequences, e.g. '\0' * encoded as "\xC0\x80". Accepting such sequences * is a security risk, according to [UTF-8]. */ if (*scan < 0xC2) return an error or something; Error return also requires the return type of the function to be changed, and a 'return success' at the end. Maybe another way is to simply not translate invalid UTF-8 strings to iso8859-1. This should also be discussed in the section which says that UTF-8 should be converted to iso8859-1 when possible. > } > } -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItwI7060032 for ; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EItwpO060031 for ietf-sasl-bks; Tue, 14 Oct 2003 11:55:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EItuI7060025 for ; Tue, 14 Oct 2003 11:55:56 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:53 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Oct 2003 11:55:53 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Oct 2003 11:55:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 14 Oct 2003 11:55:49 -0700 Content-class: urn:content-classes:message Subject: RE: Some implementor's notes MIME-Version: 1.0 Date: Tue, 14 Oct 2003 11:55:33 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_00A0_01C3924A.12E99900"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460539473B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Some implementor's notes thread-index: AcOSQgF/OFFnSNWNQjyVIpppTMaRZwAQhPMA From: "Paul Leach" To: "Alexey Melnikov" , "Greg Hudson" Cc: X-OriginalArrivalTime: 14 Oct 2003 18:55:49.0960 (UTC) FILETIME=[C8DA6480:01C39284] 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_000_00A0_01C3924A.12E99900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SASL's version of Digest has that clunky syntax so that it is possible to share an implementation with HTTP digest. HTTP digest couldn't get cleaned up when HTTP 1.1 was being worked on because some people claimed there were significant deployments of an earlier version. The "subsequent auth" feature was a request from client authors of apps where reconnects are frequent and the desire was to make them efficient. (POP3 clients are or used to be typical examples.) > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Alexey Melnikov > Sent: Tuesday, October 14, 2003 3:37 AM > To: Greg Hudson > Cc: ietf-sasl@imc.org > Subject: Re: Some implementor's notes > > > Greg Hudson wrote: > > >... > > > >First, I looked into CRAM-MD5. It doesn't authenticate the > server and > >it doesn't leave the window open for stream protection, but those > >issues aren't critical. I found the following sources of hidden > >complexity: > > > >... > > > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > > don't understand and which does not look trivial to implement. > > I'm sure there are real issues with internationalized usernames > > and passwords, but the blow-up in complexity seems astounding. > > > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as > well (at least it will when I publish a new revision) > > > > >Faced with these problems and a general sense of guilt at > the idea of > >implementing a weak system, I turned to DIGEST-MD5. I found > that while > >DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the > >digests, it comes with a burdensome level of complexity which is > >unrelated to its conceptual security properties. In particular: > > > > * It introduces the concepts of realms, subsequent authentication, > > and authorization IDs, none of which seem to be important > > functionality for a generic shared-secret authentication scheme, > > and all of which could (I think) be handled out of band. > > Fortunately, it's not too difficult to avoid supporting those > > features. > > > > * Messages are composed of key-value pairs which do not obey a > > consistent syntax for the value, so parsing them is hard. (I'm > > not convinced that Cyrus's implementation is correct, > particularly > > for skipping over auth-param values.) > > > I suggest you try to find a case that breaks stuff. It is > more constructive than saying that something doesn't (or may > not) work. > > > * Length-counted strings would be easier to parse than quoted > > strings while remaining human-readable. > > > > * Implicit allowance for linear whitespace has no intrinsic value > > and renders implementations more complicated and error-prone. > > > Yes. There are historical reasons why this happened. > It was a compromise between design and something that could > have been implemented by one big vendor. > It was supposed to become a replacement for another seriously > broken SASL mechanism NTLM. > > > * It is not specified whether the serv-type, host, and digest-uri > > values are required. > > > They are required to be sent, but the receiver SHOULD (but > not required > to) verify it. If the text is not clear, let me know and I > will try to fix it. > > > (Cyrus treats digest-uri as required but not > > the other two, probably because it's not specified what > you should > > do with an unspecified digest-uri when computing the > digests.) It > > is not made clear what security value, if any, these parameters > > have; to "detect accidental connection to the incorrect > server" is > > not an important function for an authentication scheme. > > > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > > like a very burdensome requirement to place on the protocol for > > the sake of a very implementation-specific convenience. One can > > avoid this complexity by not supporting UTF-8, but that in itself > > is unfortunate. > > > >Most of this complexity is there to provide wire similarity between > >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling > >justification for requiring a tenfold expansion in code size > over what > >would be required to compute the digests and do basic parsing. > > > > > See above. > > >Because of this complexity, I am likely to go back to CRAM-MD5, > >ignoring the RFC 3454 requirement in the current draft. I'm > not sure > >what SASL can do at this point to reduce the implementation burdens, > >but I have to say that I am sorely disappointed. When one > is designing > >a security system, one should compromise simplicity only in > the name of > >security. > > > SASL has nothing to do with your problem (well, very little to do). > SASL is just a framework. If you don't like mechanisms that > are currently available, you can write a new one and try to > make it deployed. > > >As promised, here are my major issues with the Cyrus SASL > >implementation: > > > > * As I've discussed before, if you're a library invoking the SASL > > library, there's no way to ensure thread-safety while remaining > > compatible with other libraries invoking SASL. > > > > * The getopt interface seems to be a barrier to successfully > > documenting or internationalizing an application's configuration > > system. > > > Why? > > > * The API does not successfully hide the complexity of the > > underlying mechanisms, such as digest-md5's realms. (By "hide" > > here I don't mean the API shouldn't support them, but that you > > should have to go to extra effort to use them, instead of having > > to go to extra effort to ignore them.) > > > Yes, this is a bit unfortunate, but I had exactly the same > problem trying to write a different SASL implementation. > > > > > * The secrets database is kept in a database format which > depends on > > the build of the library. > > > Shouldn't really. Secrets are usually stored in sasldb > backend, the format is quite stable at this point and > shouldn't change very much over the time. > > > If you go from one build to another > > (say, by upgrading versions of Red Hat) and the new build uses a > > different database, your server stops working and you get a > > cryptic error. That seems totally unacceptable, and I wonder how > > existing users of the library are dealing with it. > > > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > > > > Alexey > > > > ------=_NextPart_000_00A0_01C3924A.12E99900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlHDCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBmcwggYooAMCAQICCiFlQmAA AgAAAJYwCQYHKoZIzjgEAzBvMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1Jl ZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVW IFdpbjJLIElzc3VlIENBMB4XDTAzMDgyMTE3MDcyM1oXDTA0MDgyMDE3MDcyM1owQjErMCkGCSqG SIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTETMBEGA1UEAxMKUGF1bCBMZWFj aDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0xTvP/FlC8fgJAIfma5S5qyOlX9cEBVW6Pow YiSkWaKsfecw/fFg8olmGrV6STKTv0mxvvJgz6VprvvRgPc9/lavEa7Dg5BpW3bbEIWto40DvaqB gl9QZ9Ad+mtNFD5XyMO3Bw8JKiZgy1GIXerH6LQ+rTXmCQeqG/jVeOxoFiUCAwEAAaOCBJEwggSN MAsGA1UdDwQEAwIFoDAdBgNVHQ4EFgQUIaL8rFmdmJIbwYUpAThTsFPTjXowKQYJKwYBBAGCNxQC BBweGgBTAG0AYQByAHQAYwBhAHIAZABVAHMAZQByMIGUBgNVHSMEgYwwgYmAFCAZq9iZaHr5hoL6 cnmH00RgUUXvoWWkYzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQL EwVOdGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMoIK LgdxZgAFAAACIzCCAa4GA1UdHwSCAaUwggGhMIHioIHfoIHchoHZbGRhcDovLy9DTj1OVERFViUy MFdpbjJLJTIwSXNzdWUlMjBDQSgxKSxDTj1udGRldjJrY2EsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29y cCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBcoFqgWIZWaHR0cDovL250ZGV2MmtjYS5udGRl di5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFdpbjJLJTIwSXNzdWUlMjBD QSgxKS5jcmwwXKBaoFiGVmh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvTlRERVYlMjBXaW4ySyUyMElzc3VlJTIwQ0EoMSkuY3JsMIIBaQYIKwYBBQUH AQEEggFbMIIBVzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPU5UREVWJTIwV2luMkslMjBJc3N1 ZSUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRp ZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhQYIKwYBBQUH MAKGeWh0dHA6Ly9udGRldjJrY2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv bnRkZXYya2NhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFdpbjJLJTIwSXNzdWUl MjBDQSgyKS5jcnQwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwQGCCsGAQUFBwMCMFMG A1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1 bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTAJBgcqhkjOOAQDAy4AMCsCE0S2SLEdb4WEJv055mWF zOTOP/MCFFKWyliMgynk36EVIBHy8sw1aqfLMIIGlzCCBlagAwIBAgIKLgdxZgAFAAACIzAJBgcq hkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2 MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4XDTAyMTAx MTE3MDg1NloXDTA0MTAxMTE3MTg1NlowbzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU5UREVWMR0wGwYDVQQD ExROVERFViBXaW4ySyBJc3N1ZSBDQTCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQCTCC1vMkOpDkgx MJmlg1rQPpIRgEdDJNoJMpf47nK1k2QMx4tBoKaHhWPcxyblUTiWEz/ahR9Pb027PZS+l3Hg11Zn CkUDWv+Ua+x7HgRn88y219o5g5KLvXfXP66hargC7sip9Zs+qN1OMqrg6aKRNynCxav2lTghPQBO 4gc+LwIVANmVGNJGOMKtxSR5S3dlI7slhj0rAoGAVEWozto8isIYr5QbAWkAHlzfc2tX+2RhE/oa lqehpAtFfvDeWau/csQQ3QWZI46spI7ebyvGiOVbLF5HQMxAJ2fBC0XZBLM82YgeKuOfVYwam6gs TiYm24oKz7VbdofyCfjelJRXT2mJEeUonMaKbAySJySfQuELBvKxCUC7lqADgYQAAoGAFiRVn6Ny rDG1yvxstlatKvIt3Pd3oU148+jngq4lE6L7DCia91idkKfri321sSLZJpRWjw0tBXyV6PhX1Ofy cM04WMpYttjpgtYy31cMXmnnMgxC+jAYcOwYp6ecTGVxNRuZNzez3xmwZ9z82SfRCqmDh1EMNXYr QR0H4VUHI+ajggOIMIIDhDASBgkrBgEEAYI3FQEEBQIDAQACMB0GA1UdDgQWBBQgGavYmWh6+YaC +nJ5h9NEYFFF7zAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTivgNw1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAw ggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9y ZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNz PWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRwOi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0 LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGlj YTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NO PU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIu bnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWlj cm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUp LmNydDAJBgcqhkjOOAQDAzAAMC0CFHNk8vkyGD3GAmwPvUg1m5fVyfGTAhUAhnex7TIppYeW5OMY qJonfdc4Z5UwggaoMIIGEaADAgECAgor++JGAAMAMgjEMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERF ViBJU1NVRTMgQ0EwHhcNMDMwODIxMTcwNzExWhcNMDQwODIwMTcwNzExWjCBsDETMBEGCgmSJomT 8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNv cnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGln aHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqoW5IwY+zVFVnkEXvyXTr2NUw9BIh1G5Prz/7ICp7EF4y T3KXY5VXzfTgSaq3PofyDHpgtxz/mKKYyLxHiXYoovpCajquTpTyr3dlPpj6bkLpAHH7wWR3VvyX G3bzbYePZpkBho4/qI7SZhRhKJH8Jr4WgtcpMB+WZonry1GRZQIDAQABo4IEKzCCBCcwCwYDVR0P BAQDAgeAMB0GA1UdDgQWBBSd1h+ZKvVxSfNGOZpADzy9ClfE0jA+BgkrBgEEAYI3FQcEMTAvBicr BgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYK/nPZ8ht7mgFQCAXgCAQEwHwYDVR0jBBgwFoAU i9HNYfHpr468kdBA6im/5i6FQFcwggGIBgNVHR8EggF/MIIBezCCAXegggFzoIIBb4aBz2xkYXA6 Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSgyKSxDTj1XSElDQTMsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZNaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9OVERFVkNSTHMvTlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcmyGTGh0 dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ U1NVRTMlMjBDQSgyKS5jcmwwggFUBggrBgEFBQcBAQSCAUYwggFCMIHFBggrBgEFBQcwAoaBuGxk YXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1p Y3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRp b25BdXRob3JpdHkweAYIKwYBBQUHMAKGbGh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3Nv ZnQuY29tL0NlcnRFbnJvbGwvV0hJQ0EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUy MElTU1VFMyUyMENBKDMpLmNydDATBgNVHSUEDDAKBggrBgEFBQcDBDAtBgNVHSAEJjAkMCIGICsG AQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVAYMRMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH AwQwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRldi5taWNyb3NvZnQuY29t gRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMA0GCSqGSIb3DQEBBQUAA4GBAH/THraMU6d3 3PRTCS9MWY9ECxgGz/q4JBjPeHGdBKdcH3zjo291rfdmP8iqjekjHPC5Q7Mk2pghYt5IeksAdKNF PoPNOMaDVAM1BBMczPerfR1VA/jpltBeNrKc+X+en2VBlHVXTF/WDix7cgiVSKuO4njAykP1sCck FLpQVeTpMIIIGzCCBwOgAwIBAgIKKMbncgABAAAANTANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYg U0EgUm9vdCBDQTAeFw0wMjEwMTAxNjMzMDBaFw0wNTEwMTAxNjQzMDBaMGExCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRl cm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMIIBtzCCASsGByqGSM44BAEwggEeAoGBAPoSz3u7 mLB5rhlH5CE5AalrBl6Ntst+vZLNPRPhI8ABrNuHKYWlR6hWd/ikP5IMgDQr7DUpJrrdv4Z2T1pJ PVEHIxCua3HTX/o+XVGTZXdBv4x+OhHLmt11KcTy9B+0tpg3psJC4m+taONabd+yw/EB9AoPldGd HoGBBSGOdALjAhUAmE+UPbJ1WtXpFK2UwmM6G/zo60MCgYBmyg997xQQPnCr4IraxqUi5sXXsvSP vimwO/UEFxJwAiWS8OUunvnh7Gd0/scD5YNkVAsbRYF+XNgyYVCsYusC1LH8DvoOzq4Hz8lg9K/2 kA80v2Skr4DH1EFM2JG3J9Hbq362Dk9i8V6HAZEA/P8kB9/J+cI1LoXlWtfw5uaCmAOBhQACgYEA okrSViTIQt7ZG0Ytjr2GLccq5bTzDsmUdROQz1qi9eb5cOIYa2YXgE6cmZTIIFOLx6bPdgbwZSAs OfBQofQoLG3vJeQcGsA/vj7wzjmzlaImYsBF9OZRFKl7C3r/TLShHXBTQHo16zcCGuLCXhQvOsrj JhlKvhvR5fMmNpOK4jmjggRTMIIETzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTivgNw1Ysg 0kFEaq/myHdxWiUAHzALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwQABTAjBgkrBgEEAYI3 FQIEFgQU1lIoN1kh422F4hJqLWNtqmi8a0AwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUiMnNnJw6IoDq5C3aFUcv9fvEvJswggGZBgNVHR8EggGQMIIBjDCCAYigggGEoIIB gIaB2WxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKSxDTj13aGljYXNhcm9vdGNh LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGUWh0dHA6 Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFNB JTIwUm9vdCUyMENBKDEpLmNybIZPaHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybDCCAekGCCsGAQUFBwEB BIIB2zCCAdcwgcgGCCsGAQUFBzAChoG7bGRhcDovLy9DTj1OVERFViUyMFNBJTIwUm9vdCUyMENB LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhAYIKwYBBQUHMAKGeGh0 dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDCBggYIKwYBBQUHMAKGdmh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29t L0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYl MjBTQSUyMFJvb3QlMjBDQSgxKS5jcnQwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBBQUA A4IBAQA0wmQlGbxPwheWF+0oj8v1hjBbV13gmBK/2Oy0q2OcgC/o+GSkKK+5S36xOxTvVIBio37P i6jtJI8WneO9ONcLQK5NHuUV3j9FFtCM2TnLbq/OJHu+rKrYIBRYAjn3y6oWPaZQnH1Ug6Qa54AC El1bocfKBM6bVNlJKnB+WRpnwb4MrXQinvr0rYrlYH+Z7xECHo+aJ9qnp7cXXzELF57Y9qBBbqY5 keifWFfX+NxhFpRrgwtS6LtdIPOInQLG2kPoY8QafHvTSBj4IuSxdaN+d0d9n1ODnN4IKRhRYiVS pwP7aoLrK3FelYjdLEH7XQC2q+T41duYgNhWl0Dkf26XMYIC6TCCAuUCAQEwWTBLMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYg SVNTVUUzIENBAgor++JGAAMAMgjEMAkGBSsOAwIaBQCgggHmMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAxNDE4NTUzM1owIwYJKoZIhvcNAQkEMRYEFPdbwOnO ppyG4GuX9P7P1EX02u5RMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGMBgkrBgEEAYI3EAQxfzB9MG8xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4G A1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOVERFVjEdMBsGA1UE AxMUTlRERVYgV2luMksgSXNzdWUgQ0ECCiFlQmAAAgAAAJYwgY4GCyqGSIb3DQEJEAILMX+gfTBv MQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1p Y3Jvc29mdDEOMAwGA1UECxMFTlRERVYxHTAbBgNVBAMTFE5UREVWIFdpbjJLIElzc3VlIENBAgoh ZUJgAAIAAACWMA0GCSqGSIb3DQEBAQUABIGAXpjbVOG6vEm8Ft/Id52KsowOHebp+rsm2uWqmYHx hJih28lSm+GAR57zi2xIbBoqOEoeps9m2GJ8ocbREn41peis80LNw9j26gyfJwurdyss2FkHZ3HW cOW9gJr7w6WCtz1DZ2oYZeBYiYUpZBGdxeOHopRnSXgU0rc0WY6RKysAAAAAAAA= ------=_NextPart_000_00A0_01C3924A.12E99900-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjdI7055767 for ; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EGjduk055766 for ietf-sasl-bks; Tue, 14 Oct 2003 09:45:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EGjcI7055761 for ; Tue, 14 Oct 2003 09:45:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EGjdlg000478; Tue, 14 Oct 2003 16:45:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014093409.03ab2c98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 09:44:46 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> 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: At 08:33 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> 3). Realm >> >> I have not yet heard any arguments to keep the realm text. > >I found it useful, since I had no clear idea what a realm was. >The text is just too demanding. How about making the text purely >informational, without any SHOULD or MUST? I think the primary concern is that the text introduces a concept with is particular to one or more mechanisms and hence is out of place. Seems better to move the text into the DIGEST-MD5 specification as it seems to following the DIGEST-MD5 concept of a realm. Other mechanisms also have realm concepts, but it's not clear to me that they are the same as DIGEST-MD5's. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr2I7053298 for ; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFr2bK053297 for ietf-sasl-bks; Tue, 14 Oct 2003 08:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFr1I7053292 for ; Tue, 14 Oct 2003 08:53:01 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9EFr2lg099937; Tue, 14 Oct 2003 15:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031014083522.03aaed50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 08:52:24 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> 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: At 08:01 AM 10/14/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >>> draft-ietf-sasl-plain-02.txt says that >>> >>> The client leaves >>> the authorization identity empty if it wishes the server to derive the >>> authorization identity from the provided authentication identity. >>> >>> and >>> >>> Note that the parameters provided to the Authorize function are not >>> prepared. >>> >>> so I think the pseudo-code for empty authzid should say >>> authzid = DeriveAuthzid(authcid); >>> and not >>> authzid = DeriveAuthzid(pAuthcid); >> >> I think the current psuedo-code is correct, the first >> quoted text is misleading. > >I don't feel strongly about this, but the original wording seems >right to me. authzid is not prepared, No, the psuedo-code does not prepare the authzid. The authzid is prepared, it's just prepared by other code. I'll qualify the note with "by this code". >so neither does it >use the prepared version of authcid. The authzid is derived from the prepared authcid to ensure that all representations of the authentication identity produce the same authzid. This, I think, is important. >And that way, >PLAIN(authzid = "", authcid = X, password) does the same as >PLAIN(authzid = X, authcid = X, password). These are not necessarily equivalent. That is, authzid may not be in the same form as the authcid and may require different preparation. The psuedo code (and notes) are intended to reflect this. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXII7052605 for ; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFXIfG052604 for ietf-sasl-bks; Tue, 14 Oct 2003 08:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFXHI7052597 for ; Tue, 14 Oct 2003 08:33:17 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1A9RAf-0003aB-3F; Tue, 14 Oct 2003 17:33:13 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1A9RAb-0005Iv-1b; Tue, 14 Oct 2003 17:33:09 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9RAX-0003Jn-00; Tue, 14 Oct 2003 17:33:05 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:33:05 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> 3). Realm > > I have not yet heard any arguments to keep the realm text. I found it useful, since I had no clear idea what a realm was. The text is just too demanding. How about making the text purely informational, without any SHOULD or MUST? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1jI7051200 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EF1jJu051199 for ietf-sasl-bks; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EF1iI7051193 for ; Tue, 14 Oct 2003 08:01:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1A9Qg8-0000BM-Pt; Tue, 14 Oct 2003 17:01:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.14) id 1A9Qfz-0006hy-SS; Tue, 14 Oct 2003 17:01:31 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9Qfy-0003FW-00; Tue, 14 Oct 2003 17:01:30 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt In-Reply-To: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> References: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 17:01:30 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >> draft-ietf-sasl-plain-02.txt says that >> >> The client leaves >> the authorization identity empty if it wishes the server to derive the >> authorization identity from the provided authentication identity. >> >> and >> >> Note that the parameters provided to the Authorize function are not >> prepared. >> >> so I think the pseudo-code for empty authzid should say >> authzid = DeriveAuthzid(authcid); >> and not >> authzid = DeriveAuthzid(pAuthcid); > > I think the current psuedo-code is correct, the first > quoted text is misleading. I don't feel strongly about this, but the original wording seems right to me. authzid is not prepared, so neither does it use the prepared version of authcid. And that way, PLAIN(authzid = "", authcid = X, password) does the same as PLAIN(authzid = X, authcid = X, password). Your way, it does not. That seems wrong to me. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs7I7050838 for ; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EEs7O5050837 for ietf-sasl-bks; Tue, 14 Oct 2003 07:54:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEs1I7050822 for ; Tue, 14 Oct 2003 07:54:01 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A9QYh-0007AW-8m; Tue, 14 Oct 2003 16:53:59 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A9QXB-0006bE-Dt; Tue, 14 Oct 2003 16:52:25 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A9QX7-0003E1-00; Tue, 14 Oct 2003 16:52:21 +0200 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 14 Oct 2003 16:52:21 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Hallvard B Furuseth wrote: > >>>4.1. Authentication protocol exchange >>> >>> A SASL mechanism is responsible for conducting an authentication >>> protocol exchange. This consists of a series of server challenges >>> and client responses, >>> >> >>Does this mean that the initial auth command from the client is not >>considered part of the authentication protocol exchange? >> > Does it matter in this section? Well, that's where "authentication protocol exchange" seems to be defined. It matters if other documents refer to "the authentication protocol exchange". Anyway, I think I found the answer in section 6.1. The initial auth command from the client is not part of the exchange, but the optional "response" in the auth command is. >>>4.2. Authorization identities and proxy authentication >>> >>> (...) >>> The character encoding scheme used for transmitting an authorization >>> identity over protocol is specified in each authentication mechanism >>> (with the authentication mechanism's blob being further >> ^^^^ >> >>What's a blob? I don't think it's 'something ill-defined or amorphous', >>like the dictionary says:-) >> > I've changed this to "data". I still don't know _which_ data you are talking about. >>> A protocol profile MAY further refine the definition of an >>> authorization identity by adding additional syntactic restrictions >>> and protocol-specific semantics. >> >>Add a paragraph break here, since the following is a new item. Remove >>"A protocol profile MUST specify" to just make the following a new item >>in the list of things that must be specified. >> >>> A protocol profile MUST specify the >>> form of the authorization identity (as it is protocol specific, as >>> > I would rather not do this, as this is a single logic item. OK. >>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >>top. >> > I've added a sentence about this in the introduction section. I'm pretty sure you will still need to insert the words "Obsoletes: rfc 2222" in the header sometime, though I don't remember where this is stated. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAauI7038856 for ; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EAau2m038855 for ietf-sasl-bks; Tue, 14 Oct 2003 03:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAasI7038849 for ; Tue, 14 Oct 2003 03:36:55 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 14 Oct 2003 11:36:49 +0100 Message-ID: <3F8BD1BF.4080001@isode.com> Date: Tue, 14 Oct 2003 11:36:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Some implementor's notes References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: >... > >First, I looked into CRAM-MD5. It doesn't authenticate the server and >it doesn't leave the window open for stream protection, but those >issues aren't critical. I found the following sources of hidden >complexity: > >... > > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. > I have to disappoint you, but DIGEST-MD5 requires RFC 3454 as well (at least it will when I publish a new revision) > >Faced with these problems and a general sense of guilt at the idea of >implementing a weak system, I turned to DIGEST-MD5. I found that >while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes >the digests, it comes with a burdensome level of complexity which is >unrelated to its conceptual security properties. In particular: > > * It introduces the concepts of realms, subsequent authentication, > and authorization IDs, none of which seem to be important > functionality for a generic shared-secret authentication scheme, > and all of which could (I think) be handled out of band. > Fortunately, it's not too difficult to avoid supporting those > features. > > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) > I suggest you try to find a case that breaks stuff. It is more constructive than saying that something doesn't (or may not) work. > * Length-counted strings would be easier to parse than quoted > strings while remaining human-readable. > > * Implicit allowance for linear whitespace has no intrinsic value > and renders implementations more complicated and error-prone. > Yes. There are historical reasons why this happened. It was a compromise between design and something that could have been implemented by one big vendor. It was supposed to become a replacement for another seriously broken SASL mechanism NTLM. > * It is not specified whether the serv-type, host, and digest-uri > values are required. > They are required to be sent, but the receiver SHOULD (but not required to) verify it. If the text is not clear, let me know and I will try to fix it. > (Cyrus treats digest-uri as required but not > the other two, probably because it's not specified what you should > do with an unspecified digest-uri when computing the digests.) It > is not made clear what security value, if any, these parameters > have; to "detect accidental connection to the incorrect server" is > not an important function for an authentication scheme. > > * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems > like a very burdensome requirement to place on the protocol for > the sake of a very implementation-specific convenience. One can > avoid this complexity by not supporting UTF-8, but that in itself > is unfortunate. > >Most of this complexity is there to provide wire similarity between >DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling >justification for requiring a tenfold expansion in code size over what >would be required to compute the digests and do basic parsing. > > See above. >Because of this complexity, I am likely to go back to CRAM-MD5, >ignoring the RFC 3454 requirement in the current draft. I'm not sure >what SASL can do at this point to reduce the implementation burdens, >but I have to say that I am sorely disappointed. When one is >designing a security system, one should compromise simplicity only in >the name of security. > SASL has nothing to do with your problem (well, very little to do). SASL is just a framework. If you don't like mechanisms that are currently available, you can write a new one and try to make it deployed. >As promised, here are my major issues with the Cyrus SASL >implementation: > > * As I've discussed before, if you're a library invoking the SASL > library, there's no way to ensure thread-safety while remaining > compatible with other libraries invoking SASL. > > * The getopt interface seems to be a barrier to successfully > documenting or internationalizing an application's configuration > system. > Why? > * The API does not successfully hide the complexity of the > underlying mechanisms, such as digest-md5's realms. (By "hide" > here I don't mean the API shouldn't support them, but that you > should have to go to extra effort to use them, instead of having > to go to extra effort to ignore them.) > Yes, this is a bit unfortunate, but I had exactly the same problem trying to write a different SASL implementation. > > * The secrets database is kept in a database format which depends on > the build of the library. > Shouldn't really. Secrets are usually stored in sasldb backend, the format is quite stable at this point and shouldn't change very much over the time. > If you go from one build to another > (say, by upgrading versions of Red Hat) and the new build uses a > different database, your server stops working and you get a > cryptic error. That seems totally unacceptable, and I wonder how > existing users of the library are dealing with it. > > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGHI7049390 for ; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DLGH0W049389 for ietf-sasl-bks; Mon, 13 Oct 2003 14:16:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DLGGI7049368 for ; Mon, 13 Oct 2003 14:16:16 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLGHSX018273; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DLG3hk009695; Mon, 13 Oct 2003 17:16:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DLC0jW003985; Mon, 13 Oct 2003 17:12:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DLBvN6000604; Mon, 13 Oct 2003 17:11:57 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: Lyndon Nerenberg Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1066056060@[192.168.42.6]> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> <2147483647.1066056060@[192.168.42.6]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066079516.30290.91.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 17:11:57 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 16:41, Lyndon Nerenberg wrote: > > * The secrets database keeps secrets in plain text, which I find > > unacceptable due to the amount of password-sharing users do. > > If you don't trust the OS to protect this data then your only option is > to use a SASL mechanism that doesn't require plain text equivalent > secrets. This is SASL mechanism specific, and not an artifact of the > Cyrus implementation. The issue is not how much the OS can be trusted; it's how much the owner of the server can be trusted. Ideally, the user should be able to provide the secret to the server owner in such a way that the server owner cannot reuse it with other services. On further consideration, even if CRAM-MD5 secrets are kept in intermediate form, that form can be reused with other CRAM-MD5 services, so that's maybe not so useful. However, a DIGEST-MD5 password in intermediate form can only be used with another DIGEST-MD5 service if the username and realm matches. I'm not really sure what the common practice is for realm names, but if they're commonly related to the server hostname then the secret shouldn't be reusable in practice. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf7I7047402 for ; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DKf7xo047401 for ietf-sasl-bks; Mon, 13 Oct 2003 13:41:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DKf6I7047395 for ; Mon, 13 Oct 2003 13:41:06 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9DKf0P5036838; Mon, 13 Oct 2003 14:41:01 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Mon, 13 Oct 2003 14:41:00 -0600 From: Lyndon Nerenberg To: Greg Hudson , ietf-sasl@imc.org Subject: Re: Some implementor's notes Message-ID: <2147483647.1066056060@[192.168.42.6]> In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > * I find it important to avoid storing passwords in clear text, > since people often use the same password for multiple systems. To > accomplish this, you need an MD5 implementation which supports > saving intermediate states. That's an implementation issue, and not a CRAM-MD5 problem. [More on this below.] > * The current draft mandates the use of RFC 3454, a 91-page RFC I > don't understand and which does not look trivial to implement. > I'm sure there are real issues with internationalized usernames > and passwords, but the blow-up in complexity seems astounding. 3454 is a bit verbose, but from an implementation standpoint it's really not that complicated. There's no getting away from stringprep. The alternative solution of restricting everything to US-ASCII is a non-starter. With the IETF heavily leaning towards stringprep for all new protocol work, you shouldn't have any trouble finding libraries that will assist with the UTF coding issues. > Because of this complexity, I am likely to go back to CRAM-MD5, > ignoring the RFC 3454 requirement in the current draft. Please don't. We have enough trouble as it is with implementations sending non-ASCII strings in CRAM-MD5. Without the ability to specify the character set in use, interoperability suffers greatly. stringprep solves this problem. > * The secrets database keeps secrets in plain text, which I find > unacceptable due to the amount of password-sharing users do. If you don't trust the OS to protect this data then your only option is to use a SASL mechanism that doesn't require plain text equivalent secrets. This is SASL mechanism specific, and not an artifact of the Cyrus implementation. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBEI7042435 for ; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DIBElS042434 for ietf-sasl-bks; Mon, 13 Oct 2003 11:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DIBDI7042429 for ; Mon, 13 Oct 2003 11:11:13 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DIBAo8025711 for ; Mon, 13 Oct 2003 14:11:14 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DI61Fp029761 for ; Mon, 13 Oct 2003 14:06:17 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHxtjW004447 for ; Mon, 13 Oct 2003 13:59:56 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHxrL6000520; Mon, 13 Oct 2003 13:59:53 -0400 Subject: Re: Some implementor's notes From: Greg Hudson To: ietf-sasl@imc.org In-Reply-To: <200310131719.h9DHJJs4000506@error-messages.mit.edu> References: <200310131719.h9DHJJs4000506@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066067993.30290.58.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 13 Oct 2003 13:59:53 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 2003-10-13 at 13:19, Greg Hudson wrote: > * Messages are composed of key-value pairs which do not obey a > consistent syntax for the value, so parsing them is hard. (I'm > not convinced that Cyrus's implementation is correct, particularly > for skipping over auth-param values.) Whoops, this was based on a misreading of the syntax for auth-param (I read it as being "auth-param=token=value" instead of just "token=value"). So, ignore that point. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJLI7039891 for ; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DHJLZk039890 for ietf-sasl-bks; Mon, 13 Oct 2003 10:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHJKI7039885 for ; Mon, 13 Oct 2003 10:19:20 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJL7R019978 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9DHJLX0023277 for ; Mon, 13 Oct 2003 13:19:21 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9DHJK0I013308 for ; Mon, 13 Oct 2003 13:19:20 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h9DHJJs4000506; Mon, 13 Oct 2003 13:19:19 -0400 Date: Mon, 13 Oct 2003 13:19:19 -0400 Message-Id: <200310131719.h9DHJJs4000506@error-messages.mit.edu> From: Greg Hudson To: ietf-sasl@imc.org Subject: Some implementor's notes Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm writing these notes in hopes that they will provide insight on possible barriers to SASL's adoption. When I created the custom Subversion protocol, I decided to use SASL for authentication because I liked the concept and because I dislike the properties of X.509 certificates, which (via TLS) are the only real alternative that I know of. I started out by implementing ANONYMOUS and EXTERNAL myself, since those are trivial. I figured for the real meat, I would use a library, since in an ideal world applications have no business implementing authentication systems. Unfortunately, I'm finding the Cyrus library unsuitable (I'll detail the reasons for this at the end, since it's implementation-specific) and I can't use the gsasl library in Subversion since it is covered by the GPL. So, since there have been a lot of calls for password authentication, I thought maybe I would implement one of the shared-secret systems without stream protection; Subversion's utility libraries already include an MD5 implementation, so I figured I wouldn't need to introduce any complicated pieces of code. First, I looked into CRAM-MD5. It doesn't authenticate the server and it doesn't leave the window open for stream protection, but those issues aren't critical. I found the following sources of hidden complexity: * The processing of the secret (pad to 64 bytes or digest and then pad to 64 bytes) is clunky and has no value in an MD5 context as far as I know. * I find it important to avoid storing passwords in clear text, since people often use the same password for multiple systems. To accomplish this, you need an MD5 implementation which supports saving intermediate states. * The current draft mandates the use of RFC 3454, a 91-page RFC I don't understand and which does not look trivial to implement. I'm sure there are real issues with internationalized usernames and passwords, but the blow-up in complexity seems astounding. Faced with these problems and a general sense of guilt at the idea of implementing a weak system, I turned to DIGEST-MD5. I found that while DIGEST-MD5 is much more elegant than CRAM-MD5 in how it computes the digests, it comes with a burdensome level of complexity which is unrelated to its conceptual security properties. In particular: * It introduces the concepts of realms, subsequent authentication, and authorization IDs, none of which seem to be important functionality for a generic shared-secret authentication scheme, and all of which could (I think) be handled out of band. Fortunately, it's not too difficult to avoid supporting those features. * Messages are composed of key-value pairs which do not obey a consistent syntax for the value, so parsing them is hard. (I'm not convinced that Cyrus's implementation is correct, particularly for skipping over auth-param values.) * Length-counted strings would be easier to parse than quoted strings while remaining human-readable. * Implicit allowance for linear whitespace has no intrinsic value and renders implementations more complicated and error-prone. * It is not specified whether the serv-type, host, and digest-uri values are required. (Cyrus treats digest-uri as required but not the other two, probably because it's not specified what you should do with an unspecified digest-uri when computing the digests.) It is not made clear what security value, if any, these parameters have; to "detect accidental connection to the incorrect server" is not an important function for an authentication scheme. * The UTF-8 to ISO 8859-1 recoding of usernames and passwords seems like a very burdensome requirement to place on the protocol for the sake of a very implementation-specific convenience. One can avoid this complexity by not supporting UTF-8, but that in itself is unfortunate. Most of this complexity is there to provide wire similarity between DIGEST-MD5 as used in SASL and in HTTP, but that's not a compelling justification for requiring a tenfold expansion in code size over what would be required to compute the digests and do basic parsing. Because of this complexity, I am likely to go back to CRAM-MD5, ignoring the RFC 3454 requirement in the current draft. I'm not sure what SASL can do at this point to reduce the implementation burdens, but I have to say that I am sorely disappointed. When one is designing a security system, one should compromise simplicity only in the name of security. As promised, here are my major issues with the Cyrus SASL implementation: * As I've discussed before, if you're a library invoking the SASL library, there's no way to ensure thread-safety while remaining compatible with other libraries invoking SASL. * The getopt interface seems to be a barrier to successfully documenting or internationalizing an application's configuration system. * The API does not successfully hide the complexity of the underlying mechanisms, such as digest-md5's realms. (By "hide" here I don't mean the API shouldn't support them, but that you should have to go to extra effort to use them, instead of having to go to extra effort to ignore them.) * The secrets database is kept in a database format which depends on the build of the library. If you go from one build to another (say, by upgrading versions of Red Hat) and the new build uses a different database, your server stops working and you get a cryptic error. That seems totally unacceptable, and I wonder how existing users of the library are dealing with it. * The secrets database keeps secrets in plain text, which I find unacceptable due to the amount of password-sharing users do. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjII7037188 for ; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFjIM5037187 for ietf-sasl-bks; Mon, 13 Oct 2003 08:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFjGI7037180 for ; Mon, 13 Oct 2003 08:45:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9DFjH5t022347 for ; Mon, 13 Oct 2003 11:45:17 -0400 Date: Mon, 13 Oct 2003 11:45:17 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: rfc2254bis/rfc2554bis 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: I'd like to point members of this working group at the following two documents which are intended as revisions to the SMTP/POP3 SASL profiles: draft-siemborski-rfc1734bis-00.txt draft-siemborski-rfc2554bis-00.txt The aims here are to clarify the specifications to result in fewer interoperability problems. The two big concerns that I am aware of being how implementations deal with client-send-first and (in the case of SMTP) servers rejecting the AUTH= parameter to MAIL FROM when the session is not authenticated. I will be updating these drafts to point at rfc2222bis in their first revision. I'd also like to hear any other comments. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfMZA098198 for ; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AFfMuC098197 for ietf-sasl-bks; Fri, 10 Oct 2003 08:41:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-02.noos.net [212.198.2.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFfKZA098189 for ; Fri, 10 Oct 2003 08:41:21 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 3714922 invoked by uid 0); 10 Oct 2003 15:40:43 -0000 Received: (qmail 3205723 invoked by uid 0); 8 Oct 2003 19:32:14 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for ; 8 Oct 2003 19:32:14 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 51F8863FB6; Wed, 8 Oct 2003 14:32:09 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hades.jabber.org (Postfix) with ESMTP id 2461763FB0; Wed, 8 Oct 2003 14:31:36 -0500 (CDT) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre Cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Oct 2003 20:31:34 +0100 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kEZA081162 for ; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9kECt081160 for ietf-sasl-bks; Fri, 10 Oct 2003 02:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.noos.fr (nan-smtp-12.noos.net [212.198.2.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9kCZA081154 for ; Fri, 10 Oct 2003 02:46:13 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 9850079 invoked by uid 0); 10 Oct 2003 09:45:46 -0000 Received: (qmail 8715980 invoked by uid 0); 9 Oct 2003 07:19:39 -0000 Received: from unknown (HELO hades.jabber.org) ([208.245.212.109]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with SMTP for ; 9 Oct 2003 07:19:39 -0000 Received: from hades (hades [127.0.0.1]) by hades.jabber.org (Postfix) with ESMTP id 6E11663FD9; Thu, 9 Oct 2003 00:10:03 -0500 (CDT) Delivered-To: xmppwg@jabber.org Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by hades.jabber.org (Postfix) with ESMTP id 1E90F63D7C for ; Thu, 9 Oct 2003 00:09:27 -0500 (CDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> From: Eric Rescorla In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: xmppwg@jabber.org X-Mailman-Version: 2.0.13 Reply-To: xmppwg@jabber.org X-Reply-To: EKR List-Unsubscribe: , List-Id: Mailing list of the IETF's XMPP Working Group List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Oct 2003 22:16:31 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ _______________________________________________ xmppwg mailing list xmppwg@jabber.org http://jabber.org/cgi-bin/mailman/listinfo/xmppwg Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jrZA081146 for ; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A9jrOC081145 for ietf-sasl-bks; Fri, 10 Oct 2003 02:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A9jlZA081138 for ; Fri, 10 Oct 2003 02:45:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 10 Oct 2003 10:45:40 +0100 Message-ID: <3F867FC1.90704@isode.com> Date: Fri, 10 Oct 2003 10:45:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , SASL WG Subject: Re: Replacing a SASL security layer References: <3F848CD6.9010804@isode.com> <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >A concern here is that a number of application profiles >specify (and developers have implemented) SASL layers such >that established layers cannot be deinstalled except to install >new layers. > I am only aware of one protocol that might do that: LDAP. > Changing this now will naturally introduce some >interoperability, so we need to be sure that the change is well >justified. > I don't believe anybody implements this right anyway (please, do let me know if I am right). > I wonder if it might be better to not to change the >protocol but, instead, just document the security consideration. > I would like to allow new protocols to allow to deinstall the security layer when none is negotiated. RFC 2222 prohibits this. IMHO, it is fine if an existing protocol doesn't do that (and documents the issue in Security considerations), but there is no point of forcing brokeness on new protocols. Cheers, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r8ZA003688 for ; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A2r828003687 for ietf-sasl-bks; Thu, 9 Oct 2003 19:53:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A2r3ZA003682 for ; Thu, 9 Oct 2003 19:53:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9A2r1lg046810; Fri, 10 Oct 2003 02:53:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009194307.02b4e630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 19:52:29 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Replacing a SASL security layer Cc: Jeffrey Hutzelman , SASL WG In-Reply-To: <3F848CD6.9010804@isode.com> References: <3F848CD6.9010804@isode.com> 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: A concern here is that a number of application profiles specify (and developers have implemented) SASL layers such that established layers cannot be deinstalled except to install new layers. Changing this now will naturally introduce some interoperability, so we need to be sure that the change is well justified. I wonder if it might be better to not to change the protocol but, instead, just document the security consideration. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu4ZA098325 for ; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Nu4uF098324 for ietf-sasl-bks; Thu, 9 Oct 2003 16:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Nu3ZA098315 for ; Thu, 9 Oct 2003 16:56:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h99Ntvo5020961; Thu, 9 Oct 2003 19:56:00 -0400 (EDT) Message-ID: <3F85F58C.3000905@oceana.com> Date: Thu, 09 Oct 2003 19:55:56 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dick Kniep CC: SASL WG Subject: Re: Sasl problems References: <1065738130.31142.2.camel@server.kniep.nl> In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrong list. This list is for discussion of the design of SASL and its mechanisms, not the implementations. Try: cyrus-sasl@lists.andrew.cmu.edu and/or info-cyrus@lists.andrew.cmu.edu Dick Kniep wrote: > Hi List, > > This is my first post on the sasl list, I am no guru on SASl, so please > be gentle. > > We have installed a Kolab server (groupware with Sasl, postfix, cyrus > imap etc.) Install went smoothly, but we cannot log on. I have posted to > the kolab mailinglist, but got no answer whatsoever. So, next is my > original post to the kolab mailinglist. If anyone can help, please do > so. > > Since the original occurrance of the error, I have tried to remove the > user 'dick' completely from the system, defining it again etc. All to no > avail. > > ++++ Original message to Kolab mailinglist ++++ > > We have a strange phenomenon where we cannot get access to the server. > > We have entered a userid in the management module. This works OK (or so > it seems) Next we try to login, but then we get a message that the > userid is not authorized. The password is correct. When we look in the > logs of SASL the following messages are shown: > > -------------------------- > > Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or > more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). > Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth > failure: [user=dick] [service=imap] [realm=] [mech=ldap] > > -------------------------- > > It says that there are more definitions of the user 'dick'. > If that is the case how can we verify that? > If not what could be the problem than???? > > Please help > > Kind regards, > D. Kniep > > > > > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng4ZA098040 for ; Thu, 9 Oct 2003 16:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Ng3EW098039 for ietf-sasl-bks; Thu, 9 Oct 2003 16:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Ng2ZA098034 for ; Thu, 9 Oct 2003 16:42:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h99Ng4lg044945; Thu, 9 Oct 2003 23:42:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009163323.0388c3b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 16:41:32 -0700 To: Dick Kniep From: "Kurt D. Zeilenga" Subject: Re: Sasl problems Cc: SASL WG In-Reply-To: <1065738130.31142.2.camel@server.kniep.nl> References: <1065738130.31142.2.camel@server.kniep.nl> 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: Dick, As list is reserved for discussions regarding standardization of SASL, your post is off-topic. You should instead direct your post to a forum which supports the particular software you are using. I note that Cyrus SASL mailing list information can be found at . Thanks, Kurt (SASL WG co-chair) At 03:22 PM 10/9/2003, Dick Kniep wrote: >Hi List, > >This is my first post on the sasl list, I am no guru on SASl, so please >be gentle. > >We have installed a Kolab server (groupware with Sasl, postfix, cyrus >imap etc.) Install went smoothly, but we cannot log on. I have posted to >the kolab mailinglist, but got no answer whatsoever. So, next is my >original post to the kolab mailinglist. If anyone can help, please do >so. > >Since the original occurrance of the error, I have tried to remove the >user 'dick' completely from the system, defining it again etc. All to no >avail. > >++++ Original message to Kolab mailinglist ++++ > >We have a strange phenomenon where we cannot get access to the server. > >We have entered a userid in the management module. This works OK (or so >it seems) Next we try to login, but then we get a message that the >userid is not authorized. The password is correct. When we look in the >logs of SASL the following messages are shown: > >-------------------------- > >Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or >more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). >Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth >failure: [user=dick] [service=imap] [realm=] [mech=ldap] > >-------------------------- > >It says that there are more definitions of the user 'dick'. >If that is the case how can we verify that? >If not what could be the problem than???? > >Please help > >Kind regards, >D. Kniep Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc2ZA094765 for ; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99Mc2Am094764 for ietf-sasl-bks; Thu, 9 Oct 2003 15:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99Mc1ZA094759 for ; Thu, 9 Oct 2003 15:38:01 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 79992151D9B; Thu, 9 Oct 2003 18:38:03 -0400 (EDT) To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> From: Sam Hartman Date: Thu, 09 Oct 2003 18:38:03 -0400 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> (Nicolas Williams's message of "Thu, 9 Oct 2003 08:04:30 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey Nicolas> wrote: >> If the TLS tunnel is only server authenticated and the client >> supports a particular SASL method (perhaps even in a different >> protocol)that provides mutual authentication both inside and >> outside a TLS tunnel there is a vulnerability. In this case if >> only the message protection of TLS is used you cannot be sure >> that the client endpoint of the TLS tunnel is the same client >> endpoint that the server authenticated with SASL. >> >> To mitigate this problem you can: >> >> - Use the protection from the inner SASL method - Have the SASL >> authentication mechanism authenticate the TLS Session ID or >> some similar parameter - Require different credentials be used >> by a SASL mechanism when operating inside or outside a TLS >> tunnel. Nicolas> Why does this sound really familiar? Ah, because one Nicolas> solution is to "bind" one layer (SASL) to the key Nicolas> exchange and negotiation of the other (TLS) to prove that Nicolas> there's no MITM at the lower layer (TLS) - which, of Nicolas> course, relies on an MITM's inability to make the key Nicolas> exchange/nego look the same on both side of the lower Nicolas> layer channel. Nicolas> In the GSS-API we call this channel bindings. Perhaps Nicolas> SASL should have I wish SASL had this feature a lot. It's clearly out of scope for both the XMPP working group and for the SASL working group. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIIZA094244 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h99MIIG3094243 for ietf-sasl-bks; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from server.kniep.nl (node-c-9223.a2000.nl [62.194.146.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h99MIFZA094229 for ; Thu, 9 Oct 2003 15:18:18 -0700 (PDT) (envelope-from dick@kniep.nl) Received: from server.kniep.nl (localhost [127.0.0.1]) by server.kniep.nl (Postfix) with ESMTP id 4055D3342F9 for ; Thu, 9 Oct 2003 18:22:10 -0400 (EDT) Subject: Sasl problems From: Dick Kniep To: SASL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Oct 2003 00:22:09 +0200 Message-Id: <1065738130.31142.2.camel@server.kniep.nl> Mime-Version: 1.0 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi List, This is my first post on the sasl list, I am no guru on SASl, so please be gentle. We have installed a Kolab server (groupware with Sasl, postfix, cyrus imap etc.) Install went smoothly, but we cannot log on. I have posted to the kolab mailinglist, but got no answer whatsoever. So, next is my original post to the kolab mailinglist. If anyone can help, please do so. Since the original occurrance of the error, I have tried to remove the user 'dick' completely from the system, defining it again etc. All to no avail. ++++ Original message to Kolab mailinglist ++++ We have a strange phenomenon where we cannot get access to the server. We have entered a userid in the management module. This works OK (or so it seems) Next we try to login, but then we get a message that the userid is not authorized. The password is correct. When we look in the logs of SASL the following messages are shown: -------------------------- Oct 02 18:58:15 LinServ01 saslauthd[962]: Entry not found or more than one entries found ((|(uid=dick)(mail=dick)(alias=dick))). Oct 02 18:58:15 LinServ01 saslauthd[962]: do_auth : auth failure: [user=dick] [service=imap] [realm=] [mech=ldap] -------------------------- It says that there are more definitions of the user 'dick'. If that is the case how can we verify that? If not what could be the problem than???? Please help Kind regards, D. Kniep Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GTpKP074978 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GTpid074977 for ietf-sasl-bks; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GToKP074969 for ; Thu, 9 Oct 2003 09:29:51 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h99GT4X0024940; Thu, 9 Oct 2003 09:29:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GT42o017514; Thu, 9 Oct 2003 10:29:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GP8Qx021381; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GP8iN021380; Thu, 9 Oct 2003 09:25:08 -0700 (PDT) Date: Thu, 9 Oct 2003 09:25:07 -0700 From: Nicolas Williams To: Jeffrey Altman Cc: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009162507.GG17088@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> <3F85824A.5050806@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F85824A.5050806@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 11:44:10AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > >The second solution you give is an attempt at doing just this sort of > >binding. > > > >Unfortunately, a TLS MITM can make the TLS session ID be the same on > >both sides of the tunnel - that's because in TLS the server assigns the > >session ID which, in turn, is not bound or required to be bound in any > >way to the TLS key exchange / negotiation. So you can't use TLS session > >IDs as channel bindings. > > The channel binding would be made utilizing the TLS Client and Server > Finished Messages. If both the client and server concatenate those > messages in a well defined order, they can then attempt to verify that > both the client and server have the same bytes. This is how TELNET AUTH > binds to TLS when STARTTLS is used. The benefit of this is that we > would get mutual authentication from SASL which would allow TLS to be > used in anonymous-DH mode completely removing the need to have or > validate X.509 certificates. Yeah - I offer as much in the post I just followed up with. This sort of thing is extremely valuable. The NFSv4 WG is quite interested in channel bindings as a way to offload session cryptographic protection from RPCSEC_GSS/GSS-API to IPsec and others. See: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt (The I-D will be updated soon, I hope, and will include much improved text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well nonces and an additional 1/2 round-trip for the CCM-* pseudo- mechanisms' context tokens so as to make their context tokens un-replayable independently of the underlying, real mechanisms' context tokens' replayability.) > Unfortunately, SASL does not have this functionality at the current > time. I very much think it should. If it did, this entire discussion > of the use of SASL Security Layers on top of TLS could just go away. The discussion of what to use as channel bindings to TLS would still have to be had, though you point out that TELNET already solves that particular problem in a way that others could leverage. But that still leaves other channels to discuss (e.g., IPsec) - see my other followup to Joe. > I completely understand why the SASL folks want to be able to use a SASL > Security Layer on top of TLS when they do not have the ability to bind > to lower layers. Unfortunately, if SASL Security Layers are always to > be used then I believe that TLS should never be negotiated. To do so > adds nothing to the strength of the security of the session, increases > the complexity, wastes CPU cycles, and spreads FUD regarding the > trustworthiness of TLS. The lack of trust is not caused by TLS, but by > the inability of SASL to verify a previously known shared secret between > two parties. I agree. But note that SASL doesn't have to "verify a previously ..." - it just has to verify a value, public or not, that could not be made the same for both parties by an MITM at the lower layer. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074402 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99GJZlr074401 for ietf-sasl-bks; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GJZKP074396 for ; Thu, 9 Oct 2003 09:19:35 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99GIqVo006146; Thu, 9 Oct 2003 09:18:52 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99GIp58014068; Thu, 9 Oct 2003 10:18:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99GEuQx021373; Thu, 9 Oct 2003 09:14:56 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99GEtZZ021372; Thu, 9 Oct 2003 09:14:55 -0700 (PDT) Date: Thu, 9 Oct 2003 09:14:55 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009161455.GF17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <20031009150430.GD17088@binky.central.sun.com> <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote: Nico> Why does this sound really familiar? Ah, because one solution is Nico> to "bind" one layer (SASL) to the key exchange and negotiation of Nico> the other (TLS) to prove that there's no MITM at the lower layer Nico> (TLS) - which, of course, relies on an MITM's inability to make Nico> the key exchange/nego look the same on both side of the lower Nico> layer channel. > [Joe] Yes, this is all too familiar > > > Nico> In the GSS-API we call this channel bindings. Perhaps SASL should Nico> have [I meant to say "Perhaps SASL should have a channel bindings facility."] Nico> Unfortunately, a TLS MITM can make the TLS session ID be the same Nico> on both sides of the tunnel - that's because in TLS the server Nico> assigns the session ID which, in turn, is not bound or required to Nico> be bound in any way to the TLS key exchange / negotiation. So you Nico> can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice > (although in would probably work in the case outlined, it will fail if > the attacker can trick the client into accepting it as a valid TLS > endpoint, but this is a different problem). > > In any case SASL might benefit from channel bindings, although one has > to be careful with channel bindings (for example binding to addresses > tends to cause problems). Maybe it is possible to temporarily turn on > SASL integrity services to authenticate binding information. I don't > think that SASL intends for the security layer to be removed after it > starts, but I didn't find a place in the draft where it explicitly > forbids it. If it is allowed then applications which negotiate TLS can > use this binding technique. It's probably not possible to add a channel bindings facility to SASL at this point, but it should be possible to describe how applications should do channel binding with SASL, more or less as you describe. And as you point out, the traditional use of GSS-API channel bindings to bind to network addresses causes problems, and, I might add, isn't really secure. Therefore we need to generally address channel bindings for the channels one might like to bind to: - What to use as channel bindings for SSHv2? Easy, the SSHv2 session ID! - What to use as channel bindings for TLS? TLS defines no suitable value. So one may have to be constructed (e.g., hash of all TLS session setup messages). - What to use as channel bindings for IKEv1 IPsec? Don't. IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding to the previous or original IKE_SA - so that when the IKE_SA expires so do the bindings. - What to use as channel bindings for IKEv2 IPsec? IKEv2 rekeying does bind the new SA to the previous one, so binding to IPsec SAs negotiated with IKEv2 is ok, but we need to define the what to use as the channel bindings. I've asked the IPSEC WG to define a value for use as channel bindings, but so far they are ignoring me. Ultimately, the same octets of which signatures are exchanged in the AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft) can be used as channel bindings, or, rather, a hash thereof. - What to use as channel bindings for Kerberos V-protected tunnels? Again, nothing useful for this is provided in RFC1510. But who wants this? :) Still something could be defined (e.g., a hash of the AP exchange messages). - What to use as channel bindings for GSS-API-protected tunnels? Same thing. I'd propose: the ret_flags of the context and a hash of the byte-wise concatenation of the context tokens used to initialize the context, in order. - What to use as channel bindings for SASL-protected tunnels? Again, same thing... Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiWKP072767 for ; Thu, 9 Oct 2003 08:44:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FiVDM072766 for ietf-sasl-bks; Thu, 9 Oct 2003 08:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FiUKP072760 for ; Thu, 9 Oct 2003 08:44:30 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99FiCHU024300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 11:44:14 -0400 (EDT) Message-ID: <3F85824A.5050806@columbia.edu> Date: Thu, 09 Oct 2003 11:44:10 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Joseph Salowey , "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> <20031009150430.GD17088@binky.central.sun.com> In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000703080003050300080103" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000703080003050300080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > >>If the TLS tunnel is only server authenticated and the client supports a >>particular SASL method (perhaps even in a different protocol)that >>provides mutual authentication both inside and outside a TLS tunnel >>there is a vulnerability. In this case if only the message protection >>of TLS is used you cannot be sure that the client endpoint of the TLS >>tunnel is the same client endpoint that the server authenticated with >>SASL. >> >>To mitigate this problem you can: >> >>- Use the protection from the inner SASL method >>- Have the SASL authentication mechanism authenticate the TLS Session ID >>or some similar parameter >>- Require different credentials be used by a SASL mechanism when >>operating inside or outside a TLS tunnel. >> >> > >Why does this sound really familiar? Ah, because one solution is to >"bind" one layer (SASL) to the key exchange and negotiation of the other >(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of >course, relies on an MITM's inability to make the key exchange/nego look >the same on both side of the lower layer channel. > >In the GSS-API we call this channel bindings. Perhaps SASL should have > >The second solution you give is an attempt at doing just this sort of >binding. > >Unfortunately, a TLS MITM can make the TLS session ID be the same on >both sides of the tunnel - that's because in TLS the server assigns the >session ID which, in turn, is not bound or required to be bound in any >way to the TLS key exchange / negotiation. So you can't use TLS session >IDs as channel bindings. > >Cheers, > >Nico > > The channel binding would be made utilizing the TLS Client and Server Finished Messages. If both the client and server concatenate those messages in a well defined order, they can then attempt to verify that both the client and server have the same bytes. This is how TELNET AUTH binds to TLS when STARTTLS is used. The benefit of this is that we would get mutual authentication from SASL which would allow TLS to be used in anonymous-DH mode completely removing the need to have or validate X.509 certificates. Unfortunately, SASL does not have this functionality at the current time. I very much think it should. If it did, this entire discussion of the use of SASL Security Layers on top of TLS could just go away. I completely understand why the SASL folks want to be able to use a SASL Security Layer on top of TLS when they do not have the ability to bind to lower layers. Unfortunately, if SASL Security Layers are always to be used then I believe that TLS should never be negotiated. To do so adds nothing to the strength of the security of the session, increases the complexity, wastes CPU cycles, and spreads FUD regarding the trustworthiness of TLS. The lack of trust is not caused by TLS, but by the inability of SASL to verify a previously known shared secret between two parties. Jeffrey Altman Jeffrey Altman --------------ms000703080003050300080103 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTE1NDQxMFowIwYJKoZIhvcNAQkEMRYEFD2f/UNQ//7B jVMPyxGXkRLLUiiFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAv64q4pAT7kLCPtc/XIZuvm9jPAZ5 I792NJQ4KNAMn6BNdU1VGVm3ViBfqPRc7GqFo34dojUmhqxVj3epCWIVccmLQZeRsAWE/u46 eq/KF965kuSCsflGLFIWjGJWGK+e5hUtGSGTrzkeHVcWDxXkeobEtn393sdAwSq2tOj8N8Ef VHVOf6JWd76GWpGvOW4bk/NWAQg40BU2IWxrlc/e5uHht+ki+0UGJxqJyaVJpom6WpU2CQhq Mb74UgCxM4Z4nTI2rTfEgKwjMAsiMbXd3WCRspazsBmc0xpziVqAdL9fwDk4BZSePWwhYBal 0lD91cM4x9tHcsVXPtMpXPBopQAAAAAAAA== --------------ms000703080003050300080103-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FboKP072070 for ; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99FboXr072069 for ietf-sasl-bks; Thu, 9 Oct 2003 08:37:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FbnKP072063 for ; Thu, 9 Oct 2003 08:37:49 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 08:38:44 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h99FbcYb003490; Thu, 9 Oct 2003 08:37:39 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Oct 2003 08:42:18 -0700 From: "Joseph Salowey" To: "'Nicolas Williams'" Cc: "'EKR'" , , , "'SASL WG'" Subject: RE: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Date: Thu, 9 Oct 2003 08:37:37 -0700 Message-ID: <00a201c38e7b$44cccd20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20031009150430.GD17088@binky.central.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 15:42:18.0614 (UTC) FILETIME=[EBE2D960:01C38E7B] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Thursday, October 09, 2003 8:05 AM > To: Joseph Salowey > Cc: 'EKR'; xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: SASL channel bindings (was Re: [xmppwg] Last Call: > 'XMPP Core' to Proposed Standard) > > > On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > > > To mitigate this problem you can: > > > > - Use the protection from the inner SASL method > > - Have the SASL authentication mechanism authenticate the > TLS Session > > ID or some similar parameter > > - Require different credentials be used by a SASL mechanism when > > operating inside or outside a TLS tunnel. > > Why does this sound really familiar? Ah, because one > solution is to "bind" one layer (SASL) to the key exchange > and negotiation of the other > (TLS) to prove that there's no MITM at the lower layer (TLS) > - which, of course, relies on an MITM's inability to make the > key exchange/nego look the same on both side of the lower > layer channel. [Joe] Yes, this is all too familiar > > In the GSS-API we call this channel bindings. Perhaps SASL > should have > > The second solution you give is an attempt at doing just this > sort of binding. > > Unfortunately, a TLS MITM can make the TLS session ID be the > same on both sides of the tunnel - that's because in TLS the > server assigns the session ID which, in turn, is not bound or > required to be bound in any way to the TLS key exchange / > negotiation. So you can't use TLS session IDs as channel bindings. > [Joe] Yes, I agree the Session ID is probably not the best choice (although in would probably work in the case outlined, it will fail if the attacker can trick the client into accepting it as a valid TLS endpoint, but this is a different problem). In any case SASL might benefit from channel bindings, although one has to be careful with channel bindings (for example binding to addresses tends to cause problems). Maybe it is possible to temporarily turn on SASL integrity services to authenticate binding information. I don't think that SASL intends for the security layer to be removed after it starts, but I didn't find a place in the draft where it explicitly forbids it. If it is allowed then applications which negotiate TLS can use this binding technique. > Cheers, > > Nico > -- > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9CKP070984 for ; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99F9CC1070983 for ietf-sasl-bks; Thu, 9 Oct 2003 08:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F9BKP070976 for ; Thu, 9 Oct 2003 08:09:11 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h99F8SVo025764; Thu, 9 Oct 2003 08:08:28 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h99F8R2o010016; Thu, 9 Oct 2003 09:08:27 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h99F4WQx021341; Thu, 9 Oct 2003 08:04:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h99F4UFL021340; Thu, 9 Oct 2003 08:04:30 -0700 (PDT) Date: Thu, 9 Oct 2003 08:04:30 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031009150430.GD17088@binky.central.sun.com> Mail-Followup-To: Joseph Salowey , 'EKR' , xmppwg@jabber.org, iesg@ietf.org, 'SASL WG' References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey wrote: > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. > > To mitigate this problem you can: > > - Use the protection from the inner SASL method > - Have the SASL authentication mechanism authenticate the TLS Session ID > or some similar parameter > - Require different credentials be used by a SASL mechanism when > operating inside or outside a TLS tunnel. Why does this sound really familiar? Ah, because one solution is to "bind" one layer (SASL) to the key exchange and negotiation of the other (TLS) to prove that there's no MITM at the lower layer (TLS) - which, of course, relies on an MITM's inability to make the key exchange/nego look the same on both side of the lower layer channel. In the GSS-API we call this channel bindings. Perhaps SASL should have The second solution you give is an attempt at doing just this sort of binding. Unfortunately, a TLS MITM can make the TLS session ID be the same on both sides of the tunnel - that's because in TLS the server assigns the session ID which, in turn, is not bound or required to be bound in any way to the TLS key exchange / negotiation. So you can't use TLS session IDs as channel bindings. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYsKP069730 for ; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYsZQ069729 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKQ069717 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:36 +0100 Message-ID: <3F848CD6.9010804@isode.com> Date: Wed, 08 Oct 2003 23:16:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: SASL WG Subject: Replacing a SASL security layer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>> Below the term "realm" has the meaning as defined in the section 5. >>> A security layer that remains in effect when a client, which already >>> has authenticated and established the security layer with "Realm A", >>> authenticates to "Realm B", without negotiating a new security layer, >>> enables "Realm B" to make guesses about previously observed >>> ciphertext using the server's SASL engine as an oracle. "Realm B" may >>> observe how known cleartext is encrypted. >>> >>> +---------+ +---------+ >>> | | | | >>> | Realm B | | Realm A | >>> | | | | >>> +---------+ +---------+ >>> | ^ | >>> | : +-----------+ | >>> Traffic from | : | Encryption| | Traffic from A >>> B to client +-------->| end point |<-------+ to client >>> : | (SSL/SASL)| >>> : +-----------+ >>> : | >>> : | >>> : +---+ >>> : | | >>> : | | >>> : | | Encryption tunnel, e.g. SASL or >>> SSL, >>> : | | between the server >> >>> encrypted | | Separate tunnels to different >>> traffic between | | clients. >>> Realm A and client +---+ >>> | >>> | >>> +-----------> Traffic to clients >> > > This discussion is confusing and makes no sense to me. SASL doesn't > protect traffic between "realms" and clients; it protects traffic > between _servers_ and clients. This needs to be reworded so it makes > sense, in terms of entities known to the SASL framework. A "realm" is > not such an entity; it is no more than part of the autentication > identities used by some mechanisms, and has no place outside the > mechainsm specification. > > Put another way, and ignoring the issue of "realms"; the above > description makes so little sense to me that I cannot evaluate its > validity or understand what attack we are trying to avoid. Ignore for a moment any relationship of realm to DIGEST-MD5, GSSAPI or any other SASL mechanism. Let's use the definition I have in the document: Conceptually, realm is the name of a collection of user's accounts. Realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication mechanisms and/or authorization database. For example, a proxy/frontend can use different realms for different servers/backends it represents. So, each "realm" ("a protection space") is served by a separate server (proxy example above) or a separate process/plugin (frontend-backend example). Does it make more sense now? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYrKP069723 for ; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99EYra7069722 for ietf-sasl-bks; Thu, 9 Oct 2003 07:34:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99EYlKP069717 for ; Thu, 9 Oct 2003 07:34:52 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 15:34:35 +0100 Message-ID: <3F848A1A.6020006@isode.com> Date: Wed, 08 Oct 2003 23:05:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , Jeffrey Hutzelman , Hallvard B Furuseth CC: SASL WG Subject: SASL Realms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. (...) The realm value is a case- >> insensitive string, generally assigned by the origin server, which >> >> > It seems to me it is not rfc2222bis' business to define realms as > case-insensitive. The mechanism definitions can do that. I think > rfc2222bis should only say that it usually is case-insensitive, or > maybe say that it "SHOULD" be. As it is, a mechanism can define a > "case- sensitive realm" if it wants to anyway, provided it confuses > the issue by calling it something else than a "realm". Kurt D. Zeilenga wrote: >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. >> >> > >I think this SHOULD is not appropriate. First, interoperability is >not harmed by protocol profiles not providing such guidance. Secondly, >realms should be viewed as part of multi-component authentication >identity form. That is, in DIGEST-MD5, the authentication identity >is composed of two parts, the user's name (username) and the user's >realm (realm). Having profiles overload the semantics of the >any component of the authentication identity breaks the separation >of mechanism and profile. > > Jeffrey Hutzelman wrote: >>> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >>> of realm. >> >> >> I think it unwise to enter into a discussion of realms here. >> Realm syntax and semantics are, for mechanisms which have realms, >> mechanism specific. The mechanism specification should state how >> they are to be compared. The mechanism specification should state >> how they are to constructed and used in the mechanism and, where >> appropriate, state any protocol profiling requirements. (Note: >> I'd likely doubt any mechanism attempt to state protocol profiling >> requirements as this breaks SASL's separation of profile and >> mechanism). > > I agree. A realm is just part of the authentication identities used > by certain mechanisms. It is mechanism-specific, and a discussion of > realms is irrelevant to protocol profiling. Ok, the reason why I've added this text in the first place is because a lot of protocol implementors misunderstand what the realm is and is not. Unfortunately the original text in the DIGEST-MD5 document is too vague to be useful. Recent discussion on LDAP mailing list proves this. I was trying to clarify this, but your are right that the text doesn't belong to the base SASL specification. I will be adding a section to DIGEST-MD5 that tries to give some examples of realm usage. >>> A protocol profile SHOULD provide a guidance how realms are to be >>> constructed and used in the protocol and MAY further restrict its >>> syntax and protocol-specific semantics. >> > Absolutely not. Protocols may decide to include some concept of realm > in their authorization identities, but they have no business > whatsoever defining the semantics of authentication identities. That > is the responsibility of the mechanism. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaLKP060119 for ; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99AaLRu060118 for ietf-sasl-bks; Thu, 9 Oct 2003 03:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99AaIKP060113 for ; Thu, 9 Oct 2003 03:36:19 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 11:35:31 +0100 Message-ID: <3F8539F1.3020106@isode.com> Date: Thu, 09 Oct 2003 11:35:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman CC: xmppwg@jabber.org, "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> In-Reply-To: <3F849A43.6020508@columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Altman wrote: >> The requirement that initiating receiving entity drop all knowledge >> it learned before negotiating SASL layers (rule 5) is too broad. >> This could be viewed as requiring the implement to forget knowledge >> it gained previously in a secure manner (such as an externally >> established lower level (IPSEC or TLS) identity information). >> Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are > actively providing encryption/integrity protection. In this > situation, it is known that TLS is not in use. I doubt it is known > whether or not IPSec is in use for the entire communication path. > Therefore, all information obtained prior to the establishment of > encryption/integrity protection must be considered suspect. > > I believe the problem is one of language. Can we replace all > references to "security layer" to read "data protection layer"? "security layer" is a SASL term, so changing it to something else will cause additional confusion. Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p8KP057701 for ; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h999p8l1057700 for ietf-sasl-bks; Thu, 9 Oct 2003 02:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999p2KP057689 for ; Thu, 9 Oct 2003 02:51:07 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Thu, 9 Oct 2003 10:50:55 +0100 Message-ID: <3F852F7D.7030206@isode.com> Date: Thu, 09 Oct 2003 10:50:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: SASL WG Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 References: <3F841823.6010502@isode.com> <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> Content-Type: multipart/alternative; boundary="------------030505020004070308000607" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030505020004070308000607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>2). Clarification on replacing a security layer >> >> > >I would like to hear folks comments on the appropriateness of >uninstalling layers after a failed subsequent exchange. > This is not the issue. What you are talking about violates SASL spec. The issues is whether to keep the old security layer or remove it a). in protocols that allow for reauthentication (e.g. LDAP and HTTP) b). after a second or subsequent successful reauthentication. Alexey --------------030505020004070308000607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
2). Clarification on replacing a security layer
    

I would like to hear folks comments on the appropriateness of
uninstalling layers after a failed subsequent exchange.
This is not the issue. What you are talking about violates SASL spec.

The issues is whether to keep the old security layer or remove it
a). in protocols that allow for reauthentication (e.g. LDAP and HTTP)
b). after a second or subsequent successful reauthentication.

Alexey

--------------030505020004070308000607-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OvKP009626 for ; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h996OvRV009624 for ietf-sasl-bks; Wed, 8 Oct 2003 23:24:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h996OsKP009606 for ; Wed, 8 Oct 2003 23:24:56 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h996OaMV011034; Wed, 8 Oct 2003 23:24:36 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id h996PrH25214; Wed, 8 Oct 2003 23:25:53 -0700 (PDT) Message-Id: <200310090625.h996PrH25214@katroo.Sendmail.COM> To: "Joseph Salowey" From: Philip Guenther Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard In-reply-to: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> References: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> Date: Wed, 08 Oct 2003 23:22:20 -0700 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Joseph Salowey" writes: >> -----Original Message----- >> From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On ... >> This only works if the client would have been prepared to do >> this weak mechanism over a non-TLS connection. Generally the >> client knows when it expects to do TLS and when it doesn't. > >Agreed. If the client only uses this mechanism over TLS then this is >not a problem. How easy this is to enforce depends upon the deployment >environment, it may be reasonable to assume for XMPP (I'm not very >familiar with XMPP). I'm not completely sure, but with some mechanisms >using the same mechanism without TLS in a different protocol may lead to >the same problem (If the mechanism does not authenticate the >protocol/service context). For those who don't watch the ietf-announce list or didn't have their interest perked by the announcement, a discussion of this problem in the context of EAP can be found in: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt The Compound Authentication Binding Problem ... Abstract There are several motivations for using compound authentication methods using tunnels, but man-in-the-middle attacks are possible in certain circumstances when they are used, without cryptographically binding the methods together. At the time of writing this document, several protocols being proposed within the IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP. This document studies the problems and suggests potential solutions to mitigate them. (I have nothing to do with this document; it just seems extremely relevant and fairly thorough on the point under discussion. Perhaps SASL over TLS should be added to the list in the quoted abstract?) Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JtKP086958 for ; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995Jtea086956 for ietf-sasl-bks; Wed, 8 Oct 2003 22:19:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995JsKP086904 for ; Wed, 8 Oct 2003 22:19:54 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:28:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h995JncZ023880; Wed, 8 Oct 2003 22:19:49 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 22:24:28 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 22:19:47 -0700 Message-ID: <007101c38e24$f5af9e80$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 05:24:28.0752 (UTC) FILETIME=[9C86CD00:01C38E25] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 10:17 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > How's that again? Please explain the network topology you're > > > considering here. > > > > > > > Ok. I might be misunderstanding something, here is a summary: > > > > A client C that is willing to use SASL mechanism X both inside and > > outside a TLS tunnel. A server S that supports a server > authenticated > > TLS tunnel and then authenticates the client using SASL mechanism X > > within the tunnel. An attacker M who can act as a TLS client and a > > SASL server for mechanism X. > > > > The network topology/deployment must allow for M to trick C into > > trying to authenticate to him using SASL Mechanism X (without TLS) > > while M simultaneously establishes a TLS connection with S. > > > > M establishes a TLS session with S > > M tricks C into trying to authenticate to him using SASL mechanism X > > without TLS protection (these first steps could happen in > the reverse > > order) > > M forwards the SASL exchange from C to S and vice versa. > > The SASL authentication will succeed and S will believe that the > > endpoint of the TLS tunnel is C instead of M (For some > mechanisms M may > > have to spoof S's address in order for the authentication > to complete). > > M can disconnect from C and continue sending messages to S. > > S thinks the messages from M originate from C. > > Yes, this will work. But here's the thing: > > This only works if the client would have been prepared to do > this weak mechanism over a non-TLS connection. Generally the > client knows when it expects to do TLS and when it doesn't. > Agreed. If the client only uses this mechanism over TLS then this is not a problem. How easy this is to enforce depends upon the deployment environment, it may be reasonable to assume for XMPP (I'm not very familiar with XMPP). I'm not completely sure, but with some mechanisms using the same mechanism without TLS in a different protocol may lead to the same problem (If the mechanism does not authenticate the protocol/service context). Joe Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995ARKP084945 for ; Wed, 8 Oct 2003 22:10:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h995AQCr084944 for ietf-sasl-bks; Wed, 8 Oct 2003 22:10:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h995APKP084936 for ; Wed, 8 Oct 2003 22:10:25 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h995AAHU013767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2003 01:10:16 -0400 (EDT) Message-ID: <3F84EDAE.1060801@columbia.edu> Date: Thu, 09 Oct 2003 01:10:06 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey CC: "'EKR'" , xmppwg@jabber.org, iesg@ietf.org, "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060502010409050807070001" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060502010409050807070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joseph Salowey wrote: > >Ok. I might be misunderstanding something, here is a summary: > >A client C that is willing to use SASL mechanism X both inside and >outside a TLS tunnel. >A server S that supports a server authenticated TLS tunnel and then >authenticates the client using SASL mechanism X within the tunnel. >An attacker M who can act as a TLS client and a SASL server for >mechanism X. > >The network topology/deployment must allow for M to trick C into trying >to authenticate to him using SASL Mechanism X (without TLS) while M >simultaneously establishes a TLS connection with S. > >M establishes a TLS session with S >M tricks C into trying to authenticate to him using SASL mechanism X >without TLS protection (these first steps could happen in the reverse >order) >M forwards the SASL exchange from C to S and vice versa. >The SASL authentication will succeed and S will believe that the >endpoint of the TLS tunnel is C instead of M (For some mechanisms M may >have to spoof S's address in order for the authentication to complete). >M can disconnect from C and continue sending messages to S. >S thinks the messages from M originate from C. > >Joe > > > As far as I am aware, the endpoints negotiating the TLS tunnel are identical to endpoints negotiating SASL. Both TLS and SASL are negotiated as part of the same connect/accept operation. Jeffrey Altman --------------ms060502010409050807070001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTA1MTAwNlowIwYJKoZIhvcNAQkEMRYEFO1axPFRmWNP 67RIy8XDMKetb+FYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEADXQ1FtqhFe5OdSd/cDovPQGISHaw BLzXgvYSVukAr/0cgPQJJxMdLnR0GGyH52tV30C7C1cTL7KKAZ4RXtrhejAIUQzshGbBkCa8 wCqMV7nFKEX92ETM1BLM40FF5DEjs9f3BBgCedi9yDHuKte9XVniF7NkOVZ9sUZ3uqmrzKGO vTk70+sDgyCcL+qMrA+iXdaQJqhVZc3LXS0BsqsQ+MNvOPn4NfGjjmaLXM/Gh8k8/32cq2HL Wu5kPgOE9w4bKD5/Zb+wdy4zd8oJgG+wM940Nx3OBvBd9D+nfwaBNMqqDE6N210vzAb9+MW0 4gW8gFmh+G1Zl61qVK4tJDoZTgAAAAAAAA== --------------ms060502010409050807070001-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959NKP084730 for ; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9959Nlx084729 for ietf-sasl-bks; Wed, 8 Oct 2003 22:09:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9959MKP084719 for ; Wed, 8 Oct 2003 22:09:22 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 722D3AC09; Wed, 8 Oct 2003 22:16:31 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 22:16:31 -0700 In-Reply-To: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > How's that again? Please explain the network topology you're > > considering here. > > > > Ok. I might be misunderstanding something, here is a summary: > > A client C that is willing to use SASL mechanism X both inside and > outside a TLS tunnel. > A server S that supports a server authenticated TLS tunnel and then > authenticates the client using SASL mechanism X within the tunnel. > An attacker M who can act as a TLS client and a SASL server for > mechanism X. > > The network topology/deployment must allow for M to trick C into trying > to authenticate to him using SASL Mechanism X (without TLS) while M > simultaneously establishes a TLS connection with S. > > M establishes a TLS session with S > M tricks C into trying to authenticate to him using SASL mechanism X > without TLS protection (these first steps could happen in the reverse > order) > M forwards the SASL exchange from C to S and vice versa. > The SASL authentication will succeed and S will believe that the > endpoint of the TLS tunnel is C instead of M (For some mechanisms M may > have to spoof S's address in order for the authentication to complete). > M can disconnect from C and continue sending messages to S. > S thinks the messages from M originate from C. Yes, this will work. But here's the thing: This only works if the client would have been prepared to do this weak mechanism over a non-TLS connection. Generally the client knows when it expects to do TLS and when it doesn't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rdKP082836 for ; Wed, 8 Oct 2003 21:53:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994rc4k082835 for ietf-sasl-bks; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994rcKP082829 for ; Wed, 8 Oct 2003 21:53:38 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 22:01:43 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h994rXJs005754; Wed, 8 Oct 2003 21:53:33 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 21:58:12 -0700 From: "Joseph Salowey" To: "'EKR'" Cc: , , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 21:53:32 -0700 Message-ID: <006201c38e21$4a76caf0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 04:58:12.0976 (UTC) FILETIME=[F14A7700:01C38E21] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 9:21 PM > To: Joseph Salowey > Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG' > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > "Joseph Salowey" writes: > > > > -----Original Message----- > > > From: owner-ietf-sasl@mail.imc.org > > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > > Sent: Wednesday, October 08, 2003 1:28 PM > > > To: xmppwg@jabber.org > > > Cc: iesg@ietf.org; SASL WG > > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > > > > > "Kurt D. Zeilenga" writes: > > > > I concur with Alexey's recent comments regarding XMPP's > > > SASL Profile. > > > > I have a few addition concerns regarding this profile. The > > > scope of my > > > > review was, due to time constraints, was limited to the profile. > > > > > > > > I not sure why the documents says that SASL and TLS security > > > > layers > > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > > but this > > > > recommendation is, I believe, flawed. There are numerous use > > > > cases > > > > where implementations SHOULD establish additional layers. > > > For example, > > > > establishing additional SASL layers may prevent certain kinds of > > > > tunneling man-in-the-middle attacks. > > > Could you describe some of them? > > > > > > > If the TLS tunnel is only server authenticated and the > client supports > > a particular SASL method (perhaps even in a different protocol)that > > provides mutual authentication both inside and outside a TLS tunnel > > there is a vulnerability. In this case if only the message > protection > > of TLS is used you cannot be sure that the client endpoint > of the TLS > > tunnel is the same client endpoint that the server > authenticated with > > SASL. > > How's that again? Please explain the network topology you're > considering here. > Ok. I might be misunderstanding something, here is a summary: A client C that is willing to use SASL mechanism X both inside and outside a TLS tunnel. A server S that supports a server authenticated TLS tunnel and then authenticates the client using SASL mechanism X within the tunnel. An attacker M who can act as a TLS client and a SASL server for mechanism X. The network topology/deployment must allow for M to trick C into trying to authenticate to him using SASL Mechanism X (without TLS) while M simultaneously establishes a TLS connection with S. M establishes a TLS session with S M tricks C into trying to authenticate to him using SASL mechanism X without TLS protection (these first steps could happen in the reverse order) M forwards the SASL exchange from C to S and vice versa. The SASL authentication will succeed and S will believe that the endpoint of the TLS tunnel is C instead of M (For some mechanisms M may have to spoof S's address in order for the authentication to complete). M can disconnect from C and continue sending messages to S. S thinks the messages from M originate from C. Joe Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DVKP081670 for ; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h994DVOc081669 for ietf-sasl-bks; Wed, 8 Oct 2003 21:13:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h994DUKP081664 for ; Wed, 8 Oct 2003 21:13:30 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id 151AEAC09; Wed, 8 Oct 2003 21:20:35 -0700 (PDT) To: "Joseph Salowey" Cc: , , "'SASL WG'" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 21:20:35 -0700 In-Reply-To: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Joseph Salowey" writes: > > -----Original Message----- > > From: owner-ietf-sasl@mail.imc.org > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > > Sent: Wednesday, October 08, 2003 1:28 PM > > To: xmppwg@jabber.org > > Cc: iesg@ietf.org; SASL WG > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > > > > > "Kurt D. Zeilenga" writes: > > > I concur with Alexey's recent comments regarding XMPP's > > SASL Profile. > > > I have a few addition concerns regarding this profile. The > > scope of my > > > review was, due to time constraints, was limited to the profile. > > > > > > I not sure why the documents says that SASL and TLS security layers > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > > but this > > > recommendation is, I believe, flawed. There are numerous use cases > > > where implementations SHOULD establish additional layers. > > For example, > > > establishing additional SASL layers may prevent certain kinds of > > > tunneling man-in-the-middle attacks. > > Could you describe some of them? > > > > If the TLS tunnel is only server authenticated and the client supports a > particular SASL method (perhaps even in a different protocol)that > provides mutual authentication both inside and outside a TLS tunnel > there is a vulnerability. In this case if only the message protection > of TLS is used you cannot be sure that the client endpoint of the TLS > tunnel is the same client endpoint that the server authenticated with > SASL. How's that again? Please explain the network topology you're considering here. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993euKP080566 for ; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h993eudj080565 for ietf-sasl-bks; Wed, 8 Oct 2003 20:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h993etKP080554 for ; Wed, 8 Oct 2003 20:40:55 -0700 (PDT) (envelope-from jsalowey@cisco.com) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 20:49:00 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h993ejXg001235; Wed, 8 Oct 2003 20:40:46 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.67.198]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Oct 2003 20:45:24 -0700 From: "Joseph Salowey" To: "'EKR'" , Cc: , "'SASL WG'" Subject: RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Date: Wed, 8 Oct 2003 20:40:43 -0700 Message-ID: <005701c38e17$1ec86f30$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Oct 2003 03:45:24.0730 (UTC) FILETIME=[C59D05A0:01C38E17] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla > Sent: Wednesday, October 08, 2003 1:28 PM > To: xmppwg@jabber.org > Cc: iesg@ietf.org; SASL WG > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard > > > > "Kurt D. Zeilenga" writes: > > I concur with Alexey's recent comments regarding XMPP's > SASL Profile. > > I have a few addition concerns regarding this profile. The > scope of my > > review was, due to time constraints, was limited to the profile. > > > > I not sure why the documents says that SASL and TLS security layers > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this > > recommendation is, I believe, flawed. There are numerous use cases > > where implementations SHOULD establish additional layers. > For example, > > establishing additional SASL layers may prevent certain kinds of > > tunneling man-in-the-middle attacks. > Could you describe some of them? > If the TLS tunnel is only server authenticated and the client supports a particular SASL method (perhaps even in a different protocol)that provides mutual authentication both inside and outside a TLS tunnel there is a vulnerability. In this case if only the message protection of TLS is used you cannot be sure that the client endpoint of the TLS tunnel is the same client endpoint that the server authenticated with SASL. To mitigate this problem you can: - Use the protection from the inner SASL method - Have the SASL authentication mechanism authenticate the TLS Session ID or some similar parameter - Require different credentials be used by a SASL mechanism when operating inside or outside a TLS tunnel. Joe > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990lmKP075378 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990lmFa075377 for ietf-sasl-bks; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990llKP075371 for ; Wed, 8 Oct 2003 17:47:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D663F151D9B; Wed, 8 Oct 2003 20:47:49 -0400 (EDT) To: xmppwg@jabber.org Cc: "Kurt D. Zeilenga" , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <3F849A43.6020508@columbia.edu> From: Sam Hartman Date: Wed, 08 Oct 2003 20:47:49 -0400 In-Reply-To: <3F849A43.6020508@columbia.edu> (Jeffrey Altman's message of "Wed, 08 Oct 2003 19:14:11 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: Do we actually need to have this argument here? I tend to agree with Kurt but it's not clear that having this discussion will actually influence the draft. Jeff, do you see anything wrong with allowing a SASL security layer and TLS to be used in conjunction? If I'm reading your argument right, you have not actually presented any argument against this configuration, you have just argued that Kurt's reason for wanting to do so is not correct. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990PAKP074524 for ; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h990PAcl074523 for ietf-sasl-bks; Wed, 8 Oct 2003 17:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h990P8KP074518 for ; Wed, 8 Oct 2003 17:25:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h990P1lg084317; Thu, 9 Oct 2003 00:25:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008172120.03d58f10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 17:24:30 -0700 To: Jeffrey Altman From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: <3F849FC1.1080104@columbia.edu> References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> <3F849FC1.1080104@columbia.edu> 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: At 04:37 PM 10/8/2003, Jeffrey Altman wrote: >Kurt D. Zeilenga wrote: > >>At 01:28 PM 10/8/2003, Eric Rescorla wrote: >> >> >>>"Kurt D. Zeilenga" writes: >>> >>> >>>>I concur with Alexey's recent comments regarding XMPP's SASL >>>>Profile. I have a few addition concerns regarding this profile. >>>>The scope of my review was, due to time constraints, was limited >>>>to the profile. >>>> >>>>I not sure why the documents says that SASL and TLS security >>>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>>but this recommendation is, I believe, flawed. There are numerous use >>>>cases where implementations SHOULD establish additional layers. >>>>For example, establishing additional SASL layers may prevent >>>>certain kinds of tunneling man-in-the-middle attacks. >>>> >>>Could you describe some of them? >>> >> >>XMPP's TLS profile allows establishment of TLS even though the >>implementation's certificate verification has failed: >> If the above methods fail, the certificate SHOULD be presented >> to a human (e.g., an end user or server administrator) for >> approval; if presented, the receiver MUST deliver the entire >> certificate chain to the human, who SHOULD be given the option >> to store the Root CA certificate (not the service or End Entity >> certificate) and to not be queried again regarding acceptance of >> the certificate for some reasonable period of time. >> >>Given the likelihood that the end user will inappropriately >>accept the certificate, attackers can easily insert a >>TLS-protected machine in the middle. Given this, it is quite >>reasonable for implementors to offer (and deployers to demand) >>additional safeguards. >> >>Kurt >If the policy requirement of the deployers is to not accept the risk >that the end user will accept certificate chains which cannot be verified >by algorithmic means, The policy might be to mitigate the risk that users won't do the appropriate checks by requiring an additional layer of security. >There is zero benefit to negotiating both TLS and SASL encryption/integrity >protection. I disagree. Multiple layer defenses have benefits. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbmKP073194 for ; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NbmRc073193 for ietf-sasl-bks; Wed, 8 Oct 2003 16:37:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NbkKP073181 for ; Wed, 8 Oct 2003 16:37:47 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NbegG021882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:37:44 -0400 (EDT) Message-ID: <3F849FC1.1080104@columbia.edu> Date: Wed, 08 Oct 2003 19:37:37 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: EKR , xmppwg@jabber.org, iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600070607010700010909" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050600070607010700010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 01:28 PM 10/8/2003, Eric Rescorla wrote: > > >>"Kurt D. Zeilenga" writes: >> >> >>>I concur with Alexey's recent comments regarding XMPP's SASL >>>Profile. I have a few addition concerns regarding this profile. >>>The scope of my review was, due to time constraints, was limited >>>to the profile. >>> >>>I not sure why the documents says that SASL and TLS security >>>layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >>>but this recommendation is, I believe, flawed. There are numerous use >>>cases where implementations SHOULD establish additional layers. >>>For example, establishing additional SASL layers may prevent >>>certain kinds of tunneling man-in-the-middle attacks. >>> >>> >>Could you describe some of them? >> >> > >XMPP's TLS profile allows establishment of TLS even though the >implementation's certificate verification has failed: > If the above methods fail, the certificate SHOULD be presented > to a human (e.g., an end user or server administrator) for > approval; if presented, the receiver MUST deliver the entire > certificate chain to the human, who SHOULD be given the option > to store the Root CA certificate (not the service or End Entity > certificate) and to not be queried again regarding acceptance of > the certificate for some reasonable period of time. > >Given the likelihood that the end user will inappropriately >accept the certificate, attackers can easily insert a >TLS-protected machine in the middle. Given this, it is quite >reasonable for implementors to offer (and deployers to demand) >additional safeguards. > >Kurt > > If the policy requirement of the deployers is to not accept the risk that the end user will accept certificate chains which cannot be verified by algorithmic means, then the policy should fail the certificate validation without presenting the certificates to the end user. The TLS session at that point must be aborted. At this point the TCP session must be closed. When XMPP attempts to reconnect, it must not attempt to establish a TLS session and in turn must attempt to negotiate a SASL mechanism which provides encryption/integrity protection. There is zero benefit to negotiating both TLS and SASL encryption/integrity protection. Btw, if it is possible for SASL to validate the TLS Client and Server Finished messages as computed by both the client and server, this can be performed during SASL authentication to detect a man-in-the-middle attack. This is the process which is used in TELNET START-TLS when combined with TELNET AUTH. Jeffrey Altman --------------ms050600070607010700010909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMzczN1owIwYJKoZIhvcNAQkEMRYEFL7qB6VLKFhA xcvIVRWzNb7OwJiYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAnbQCkWQGl0WeHwIi1zvOG7Gx2LK0 ITzK27cRdxMy9nvy5ZRMW8oYxUNoMghWjAqwvsMnoBFkeUUnqCajwU/KCcAasU7liZAus95p i4pAt8ja4O0+i8YimxPJCW1AryYsTXHdZJOD8ejXrQEOpCd6ZoTWnBjC1YWsWqg+ru4VI+ip M1oLJ+97Xs0F7EAoTP92Bjmog47ugTVtMsGvHcWFqWZk7kes5jsIKNrdjRqQKDtcgiCC+84T XtnAL05PH1JgG953sq8ABwtddTCwG6uzJlsPv5tiZxTI7HwBzhHhOjesSTYh9BushM9KTDeM nIiXLVE/XvBpjhV7Fwa+woXzqAAAAAAAAA== --------------ms050600070607010700010909-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEKKP072462 for ; Wed, 8 Oct 2003 16:14:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NEKZN072458 for ietf-sasl-bks; Wed, 8 Oct 2003 16:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.59.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NEIKP072453 for ; Wed, 8 Oct 2003 16:14:19 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98NEETO017641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2003 19:14:17 -0400 (EDT) Message-ID: <3F849A43.6020508@columbia.edu> Date: Wed, 08 Oct 2003 19:14:11 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Re: Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090408090503010507000209" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090408090503010507000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >To the IESG, > >I concur with Alexey's recent comments regarding XMPP's SASL >Profile. I have a few addition concerns regarding this profile. >The scope of my review was, due to time constraints, was limited >to the profile. > >I not sure why the documents says that SASL and TLS security >layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >but this recommendation is, I believe, flawed. There are numerous use >cases where implementations SHOULD establish additional layers. >For example, establishing additional SASL layers may prevent >certain kinds of tunneling man-in-the-middle attacks. > > The "security" is specific to the SASL encryption and integrity protection; not authentication. Clearly, SASL authentication might be used to help detect a man-in-the-middle attack. If you are arguing that SASL encryption/integrity protection should be used on top of TLS encryption/integrity protection, the only reason for doing so is that you do not trust the TLS encryption/integrity protection. I do not see where the man-in-the-middle attack would be coming from? >The requirement that initiating receiving entity drop all knowledge >it learned before negotiating SASL layers (rule 5) is too broad. >This could be viewed as requiring the implement to forget knowledge >it gained previously in a secure manner (such as an externally >established lower level (IPSEC or TLS) identity information). >Likewise for rule 6. > > Rules 5 and 6 are specific to the use of SASL mechanisms which are actively providing encryption/integrity protection. In this situation, it is known that TLS is not in use. I doubt it is known whether or not IPSec is in use for the entire communication path. Therefore, all information obtained prior to the establishment of encryption/integrity protection must be considered suspect. I believe the problem is one of language. Can we replace all references to "security layer" to read "data protection layer"? >I am also concerned by the use of the term "stream encryption" >in the document as this doesn't imply, in my eyes, "stream >integrity". It's unclear to me which imperatives imply when >encryption, integrity, and/or in combination with other security >services which TLS provides. > > I agree. We are not concerned with Stream Encryption but Data Protection. Replace "Stream Encryption" with "Data Protection" throughout. I have not completed a security review of these documents as yet. I am simply responding to Kurt's comments. Jeffrey Altman --------------ms090408090503010507000209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODIzMTQxMVowIwYJKoZIhvcNAQkEMRYEFPSFDtAa4rTl gsvSQ23L6JnMGdqZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAJL99vPLNN9ZLX+NXMt5FZ6G8loGh zTc412pdHSq2PnQWkH/IRwbLb0riGgm1FIUPx85msJgIxHlbzuioX670UivRi5esVZJitT0H MMa6NtTc2+Mt391srr4T0QdhglgJUaZ0181nhm1dQzwNZmZ8A+JGWtbWqeceyg7axT2lOg32 rNFAiemS+i9C1kUiROICpXwjiqYg2qvXH2rV3ffKrYHfeTG9KWBZRWgqlcYDO2hMDQz+oa1b VknnzdTZXeiq7KgH2CJZMqfpuqYUPBudNSZ+ny9ojGxucpmuHkvxuG4+UApPCup8VBfVcO1e bJIzwCN9mbE7YEi3mPCCqeFYLQAAAAAAAA== --------------ms090408090503010507000209-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9rKP072180 for ; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98N9rG4072179 for ietf-sasl-bks; Wed, 8 Oct 2003 16:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98N9qKP072174 for ; Wed, 8 Oct 2003 16:09:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98N9qlg083607; Wed, 8 Oct 2003 23:09:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009024912.02bbfbe8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:41:49 -0700 To: EKR From: "Kurt D. Zeilenga" Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, iesg@ietf.org, SASL WG In-Reply-To: References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> 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: At 01:28 PM 10/8/2003, Eric Rescorla wrote: >"Kurt D. Zeilenga" writes: >> I concur with Alexey's recent comments regarding XMPP's SASL >> Profile. I have a few addition concerns regarding this profile. >> The scope of my review was, due to time constraints, was limited >> to the profile. >> >> I not sure why the documents says that SASL and TLS security >> layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), >> but this recommendation is, I believe, flawed. There are numerous use >> cases where implementations SHOULD establish additional layers. >> For example, establishing additional SASL layers may prevent >> certain kinds of tunneling man-in-the-middle attacks. >Could you describe some of them? XMPP's TLS profile allows establishment of TLS even though the implementation's certificate verification has failed: If the above methods fail, the certificate SHOULD be presented to a human (e.g., an end user or server administrator) for approval; if presented, the receiver MUST deliver the entire certificate chain to the human, who SHOULD be given the option to store the Root CA certificate (not the service or End Entity certificate) and to not be queried again regarding acceptance of the certificate for some reasonable period of time. Given the likelihood that the end user will inappropriately accept the certificate, attackers can easily insert a TLS-protected machine in the middle. Given this, it is quite reasonable for implementors to offer (and deployers to demand) additional safeguards. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4ZKP070106 for ; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98M4YaP070105 for ietf-sasl-bks; Wed, 8 Oct 2003 15:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98M4XKP070100 for ; Wed, 8 Oct 2003 15:04:33 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98M4Xlg083031; Wed, 8 Oct 2003 22:04:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009030341.02bc0108@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 03:04:16 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: Alexey Melnikov , ietf-sasl@imc.org In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> 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: At 07:19 AM 10/8/2003, Jeffrey Hutzelman wrote: >>Would you rather reference the SASL WG as the Change Controller? > >No, especially since the SASL WG will likely conclude within the foreseeable future. The IESG should have change control mechanisms registered by Standards Action. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L25KP068097 for ; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98L25rp068096 for ietf-sasl-bks; Wed, 8 Oct 2003 14:02:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L24KP068091 for ; Wed, 8 Oct 2003 14:02:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98L26lg082716; Wed, 8 Oct 2003 21:02:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009014942.02affe78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 02:01:48 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Cc: SASL WG In-Reply-To: <3F841823.6010502@isode.com> References: <3F841823.6010502@isode.com> 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: At 06:58 AM 10/8/2003, Alexey Melnikov wrote: >I have an impression that there are two many little things to change so that we will need a new Last Call anyway. >Is my perception correct? Yes. Given the large number of issues, I prefer to give you as fairly wide latitude to make the changes you believe are appropriate. Once a new I-D is ready, we'll then ask the WG to review the I-D to see consensus supports the changes made and the document as a whole. >If it is, I will issue a new revision shortly. Great! >Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): >1). IANA considerations and registering a familily of SASL mechanisms. You might look at BCP 64 (RFC 3383) guidelines for OID descriptors and families of OID descriptors as an example. >2). Clarification on replacing a security layer I would like to hear folks comments on the appropriateness of uninstalling layers after a failed subsequent exchange. >3). Realm I have not yet heard any arguments to keep the realm text. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr5KP067641 for ; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kr5X1067639 for ietf-sasl-bks; Wed, 8 Oct 2003 13:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kr3KP067634 for ; Wed, 8 Oct 2003 13:53:04 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h98Kr0js010724 for ; Wed, 8 Oct 2003 15:53:00 -0500 Received: from att.com (unknown[135.210.35.140](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031008205022gw100lr6v3e> (Authid: tony); Wed, 8 Oct 2003 20:50:22 +0000 Message-ID: <3F84792B.1000301@att.com> Date: Wed, 08 Oct 2003 16:52:59 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011022 Netscape6/6.2 X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: xmppwg@jabber.org CC: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> In-Reply-To: <3F8334ED.80504@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: White space and CRLFs were specifically allowed in the original MIME base64 specification because of: line length limitations in the underlying protocols gateways that would add or subtract white space willy-nilly it was useful being able to work with base64 data in small chunks when doing development and debugging The first two issues don't apply here, but the last one certainly still does. So I'd recommend that whitespace and CRLFs be ignored. Tony Hansen tony@att.com Alexey Melnikov wrote: > The IESG wrote: > >> The IESG has received a request from the Extensible Messaging and >> Presence Protocol WG to consider the following document: >> >> - 'XMPP Core ' >> as a Proposed Standard > > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. > > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk3KP067429 for ; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Kk3Xn067428 for ietf-sasl-bks; Wed, 8 Oct 2003 13:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Kk2KP067421 for ; Wed, 8 Oct 2003 13:46:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Kk3lg082611; Wed, 8 Oct 2003 20:46:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031009013724.02b007f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 09 Oct 2003 01:45:45 -0700 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: <3F83FA6D.1030909@isode.com> References: <3F83FA6D.1030909@isode.com> 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: At 04:52 AM 10/8/2003, Alexey Melnikov wrote: >>> In >>> order to avoid noninteroperability due to differing normalizations, >>> when a mechanism specifies that a string authentication identity or >>> password used as input to a cryptographic function (or used for >>> comparison) it SHOULD specify that the string first be prepared using >>> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >>> [StringPrep]. This should be done by both the client (upon getting >>> user input or retrieving a value from configuration) and by the >>> server (upon receiving the value from the client). >>> >> >>What's the point of this duplicate preparation? Why not do it only >>at the server side? >> >Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. Alexey, the current text suggests that client (1) prep the value before sending, the server then preps it (2) again (before comparing it to the store value, which also should be prep'ed (3) either before storing it or before each compare). We need to REQUIRE that mechanisms specify how character strings are to be prepared for comparison and RECOMMEND that they use SASLprep for simple user names and passwords. We should not suggest that mechanisms should do both (1) and (2). (1) and (3) OR (2) or (3) are sufficient to ensure proper matching. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL8KP066772 for ; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98KL8Dg066771 for ietf-sasl-bks; Wed, 8 Oct 2003 13:21:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KL7KP066766 for ; Wed, 8 Oct 2003 13:21:07 -0700 (PDT) (envelope-from ekr@rtfm.com) Received: by romeo.rtfm.com (Postfix, from userid 556) id A832AAC0A; Wed, 8 Oct 2003 13:28:14 -0700 (PDT) To: xmppwg@jabber.org Cc: iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard References: <3F8334ED.80504@isode.com> <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Reply-To: EKR From: Eric Rescorla Date: 08 Oct 2003 13:28:14 -0700 In-Reply-To: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Kurt D. Zeilenga" writes: > I concur with Alexey's recent comments regarding XMPP's SASL > Profile. I have a few addition concerns regarding this profile. > The scope of my review was, due to time constraints, was limited > to the profile. > > I not sure why the documents says that SASL and TLS security > layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), > but this recommendation is, I believe, flawed. There are numerous use > cases where implementations SHOULD establish additional layers. > For example, establishing additional SASL layers may prevent > certain kinds of tunneling man-in-the-middle attacks. Could you describe some of them? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JW1KP065291 for ; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JW1Zi065290 for ietf-sasl-bks; Wed, 8 Oct 2003 12:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JVxKP065282 for ; Wed, 8 Oct 2003 12:31:59 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:31:35 +0100 Message-ID: <3F846616.8070808@isode.com> Date: Wed, 08 Oct 2003 20:31:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>1). >> >> >>> 7. The initiating entity MUST provide an authzid during SASL >>> negotiation. The authzid-value MUST be a valid JID of the form >>> (i.e., a domain identifier only) for servers and of the >>> form (i.e., node identifier, domain >>> identifier, and resource identifier) for clients. The initiating >>> entity MAY process the authzid-value in accordance with the rules >>> defined in Addressing Scheme (Section 3) before providing it to >>> the receiving entity, but is NOT REQUIRED to do so; however, the >>> receiving entity MUST verify that the authzid-value provided by >>> the initiating entity conforms to the rules defined therein. >>> >>> >>Not all SASL mechanisms are capable of transmitting authorization >>identity, so this requirement might be problematic. >> >>Also, the revision of RFC 2222 says that the client must not specify >>authorization-id unless it wants to impersonate some other entity: >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >>So, the text should be reworded reflect that an authorization identity >>is optional and that if one is provided, it is in the form described above. >> >> > >My understanding from an earlier thread on the XMPP WG list was that >providing the authorization identity in this manner was the approach >preferred by the SASL community. I think the fundamental issue here is >that for XMPP clients, the authorization identity is a "full JID" (i.e., >node@host/resource) that is asserted by the connecting client, not >derived by the server. Perhaps this usage is not consistent with the >definition of authorization identity in RFC 2222? We'd have to look at >the implications of this for client assertion of a full JID (perhaps >this should be defined only in draft-ietf-xmpp-im). > There are two issues here: 1). Format of an authorization identity - your document has to define it 2). Requirement to always specify authorization identity. Short answer to the second issue is probably "you can't do that". But here I will try to give a long answer to explain that you probably don't need 2 anyway. This is a bit tricky. SASL defines two types of identities. Authentication identity is derived from your authentication credentials and its format is SASL mechanism specific. Authorization identity is protocol specific. If authorization identity is not specified ("empty authorization identity"), it is derived from the authentication identity. This is the usual case ("just act as yourself"). However is authorization identity is specified, additional authorization checks take place. The server has to verify that the authentication identity can act as the authorization identity. Authorization identity is useful, for example, when an administrator (or proxy server) wants to authenticate as himself, but act as the user. In XMPP case I can also imagine a client that tries to authenticate as "node@host", but act as "node@host/resource". So, what does this means for a server implementor? The text below describes my implementation experience and doesn't specify a standard of any kind. Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put any restrictions on how an authentication identity looks like. So, in most cases "node@host/resource" (for the client-to-server) or "host" (for the server-to-server) format will be used. For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity has the format dictated by Kerberos (usually user@realm or service@realm). An XMPP implementation will have to internally map Kerberos principals to XMPP JID format (or host), before verifying an authorization identity, if the one was provided. Of course, there is also SASL EXTERNAL that can be used together with TLS. In this case authentication identity will have syntax of a DN. The bottom line is that the syntax used for authorization identities for a protocol is [most likely] the syntax that is going to be used internally by the server and is the same syntax that is used by the user in the "enter your username" dialog for the protocol. (Hopefully this makes sense ;-)). So, the paragraph should probable read: 7. An authorization identity used in SASL is a valid JID of the form (i.e., a domain identifier only) for servers and of the form (i.e., node identifier, domain identifier, and resource identifier) for clients. ... Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAuKP064383 for ; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JAuvd064382 for ietf-sasl-bks; Wed, 8 Oct 2003 12:10:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JAmKP064372 for ; Wed, 8 Oct 2003 12:10:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 20:10:25 +0100 Message-ID: <3F84611F.9020601@isode.com> Date: Wed, 08 Oct 2003 20:10:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> In-Reply-To: <20031008174046.GB31898@jabber.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Saint-Andre wrote: >>2). >> >> >>> This series of challenge/response pairs continues until one of three >>> things happens: >>> >>> 1. The initiating entity aborts the handshake by sending an >>> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' >>> namespace to the receiving entity. Upon receiving the >>> element, the receiving entity MUST terminate the TCP connection. >>> >>> >>I think the requirement to drop TCP connection is unreasonable here. >>There are several valid reasons why the client may retry failed >>authentication: >>1). User typed in a wrong password, the client should retry the same >>SASL mechanism a reasonable number of times. >>2). The client invoked a SASL mechanism that reported that it can't be >>used because of misconfiguration (e.g. kerberos configuration file is >>missing). The client than sends to the server and tries another >>mechanism. >> >> > >This seems reasonable. I think we were attempting to ensure that the >connecting entity could not abuse the opened TCP connection for an >unspecified period of time. > Closing connection or refusing to perform any tasks after a certain number of failures are two common implementation practice in SMTP and other protocols. I think you should mention them, but don't require everyone to implement them. >>3). >> >> >>> 3. The receiving entity reports success of the handshake by sending >>> a element qualified by the >>> 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating >>> entity; this element MAY optionally contain character data (in >>> SASL terminology "additional data with success"). Upon receiving >>> the element, the initiating entity MUST initiate a new >>> stream by sending an opening XML stream header to the receiving >>> entity (it is not necessary to send a closing >>> element first, since the receiving entity and initiating entity >>> MUST consider the original stream to be closed upon sending or >>> receiving the element). Upon receiving the new stream >>> header from the initiating entity, the receiving entity MUST >>> respond by sending a new XML stream header to the initiating >>> entity, along with any remaining available features (but NOT >>> including the STARTTLS feature or any authentication mechanisms) >>> or an empty features element (to signify that no additional >>> features are available); note that any such additional features >>> are not defined herein, and MUST be defined by the relevant >>> extension to XMPP. >>> >>> >>Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a >>successful SASL authentication. >>Some of them require that the client compares the list of the advertised >>mechanism with the one before the authentication. >>This is done to prevent man-in-the-middle attacks when an attacker >>removes strong SASL mechanisms from the list of supported mechanisms. >>(Whether this check is useful in practice is another matter. I am not >>sure whether anybody implements it). >> >> > >OK, I'll look at what those other protocols require, and how they word >the requirement. It seems good to have this check in place. > I don't have a strong feeling about this. I am just emphasizing the difference between other protocols and XMPP in this case. A security person should comment on this. >>4). There was a recent discussion on the bugtraq mailing list about >>handling invalid base64 data. It turned out that different >>implementations handle >>this differently, for example: >>... >> >>(You might decide to relax this for XMPP and to allow spaces and/or >>CRLFs anywhere in the data.) >> >> > >I see no strong reason to relax the requirement just for XMPP. > This is fine. I was just thinking about a base64 encoder that enforces a line length limit and will insert CRLF automatically. >>5). >> >> >>>6.3 SASL Errors >>> >>> o -- The data provided by the initiating entity >>> could not be processed, e.g. because does not adhere to the >>> protocol for the requested mechanism; sent in response to the >>> element. >>> >>> >>Do you mean invalid base64 encoding here or something else? >> >> > >It could be invalid base64 encoding, but we were thinking especially >that the decoded response is not consistent with the challenge format >required by the selected SASL mechanism. > > Challenge format is specific to a SASL mechanism. As far as the protocol using SASL is concerned, invalid SASL mechanism format is not different from "authentication failure". An error from a SASL mechanism is different from an error resulting in inability to decode base64 data. These errors happen at different layers, so they should have different error tags. Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com Cell: +44 7753759732 IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html Personal Home Page: http://orthanc.ab.ca/mel __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPvKP062655 for ; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98IPvQb062654 for ietf-sasl-bks; Wed, 8 Oct 2003 11:25:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98IPuKP062648 for ; Wed, 8 Oct 2003 11:25:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h98IOf5t013327; Wed, 8 Oct 2003 14:24:41 -0400 Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT) From: Rob Siemborski To: Peter Saint-Andre cc: xmppwg@jabber.org, Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) In-Reply-To: <20031008174046.GB31898@jabber.org> Message-ID: References: <3F8334ED.80504@isode.com> <20031008174046.GB31898@jabber.org> 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: On Wed, 8 Oct 2003, Peter Saint-Andre wrote: > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > > successful SASL authentication. > > Some of them require that the client compares the list of the advertised > > mechanism with the one before the authentication. This claim isn't true. SMTP has a MAY for this, the other protocols don't express an opinion one way or the other. I know some IMAP and POP implementations remove the capability after a successful authentication (to indicate that the AUTHENTICATE/AUTH command is no longer valid) > > This is done to prevent man-in-the-middle attacks when an attacker > > removes strong SASL mechanisms from the list of supported mechanisms. > > (Whether this check is useful in practice is another matter. I am not > > sure whether anybody implements it). > > OK, I'll look at what those other protocols require, and how they word > the requirement. It seems good to have this check in place. I'm not sure its terribly useful, since the real way to prevent this MitM attack is that a client should not use a mechanism that does not support its minimum security requirements, not find out after the fact that you have an active attacker. I will also be posting IDs within the next few days that are revisions to RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be useful to look at (hopefully they will be clearer). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv3KP060293 for ; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Hv3p5060292 for ietf-sasl-bks; Wed, 8 Oct 2003 10:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Hv2KP060286 for ; Wed, 8 Oct 2003 10:57:02 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h98Huulg081187; Wed, 8 Oct 2003 17:56:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008195111.03af8bc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 22:56:38 -0700 To: iesg@ietf.org From: "Kurt D. Zeilenga" Subject: Last Call: 'XMPP Core' to Proposed Standard Cc: xmppwg@jabber.org, SASL WG In-Reply-To: <3F8334ED.80504@isode.com> References: <3F8334ED.80504@isode.com> 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: To the IESG, I concur with Alexey's recent comments regarding XMPP's SASL Profile. I have a few addition concerns regarding this profile. The scope of my review was, due to time constraints, was limited to the profile. I not sure why the documents says that SASL and TLS security layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), but this recommendation is, I believe, flawed. There are numerous use cases where implementations SHOULD establish additional layers. For example, establishing additional SASL layers may prevent certain kinds of tunneling man-in-the-middle attacks. The requirement that initiating receiving entity drop all knowledge it learned before negotiating SASL layers (rule 5) is too broad. This could be viewed as requiring the implement to forget knowledge it gained previously in a secure manner (such as an externally established lower level (IPSEC or TLS) identity information). Likewise for rule 6. For rule 8, a normative reference to the base64 encoding algorithm should be provided. I am also concerned by the use of the term "stream encryption" in the document as this doesn't imply, in my eyes, "stream integrity". It's unclear to me which imperatives imply when encryption, integrity, and/or in combination with other security services which TLS provides. Additionally, I would like to note that the document suffers from a number of nits. As I only did a casual scan, this list is likely no where near complete. I suggest that XMMP WG members be asked to do a more careful review for nits. Acronym not spelled out in title: XMMP Citiation in abstract Used old citation style (numeric tags instead of mnemonic tags) Acronyms not spelled out on first use in Abstract: XML Table of contents too long Acronyms not spelled out on first use in body: XML, JID Confusing upper casing of words: COULD Odd use of 2119 keywords: "MAY optionally" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HnfKP059704 for ; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HneC2059703 for ietf-sasl-bks; Wed, 8 Oct 2003 10:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-FORTY-SIX.MIT.EDU [18.187.6.191]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HndKP059698 for ; Wed, 8 Oct 2003 10:49:40 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id C891F151D9B; Wed, 8 Oct 2003 13:49:38 -0400 (EDT) To: Ken Murchison , "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> From: Sam Hartman Date: Wed, 08 Oct 2003 13:49:38 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 8 Oct 2003 08:35:11 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: It seems like you may want to document clearly the interoperability concern. Mention specific products as examples if it makes your text more clear. Just make sure your claims are accurate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HelKP059213 for ; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HelkI059212 for ietf-sasl-bks; Wed, 8 Oct 2003 10:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hades.jabber.org (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HejKP059207 for ; Wed, 8 Oct 2003 10:40:46 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: by hades.jabber.org (Postfix, from userid 1005) id E3F3C63EB6; Wed, 8 Oct 2003 12:40:46 -0500 (CDT) Date: Wed, 8 Oct 2003 12:40:46 -0500 From: Peter Saint-Andre To: xmppwg@jabber.org Cc: Jeremie Miller , iesg@ietf.org, SASL WG Subject: Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) Message-ID: <20031008174046.GB31898@jabber.org> References: <3F8334ED.80504@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8334ED.80504@isode.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Oct 07, 2003 at 10:49:33PM +0100, Alexey Melnikov wrote: > I would like to raise several SASL related issues in XMPP document. > (Sorry for crosspost and sorry for being late with reviewing this.) No apologies necessary -- your feedback is appreciated. > 1). > > 7. The initiating entity MUST provide an authzid during SASL > > negotiation. The authzid-value MUST be a valid JID of the form > > (i.e., a domain identifier only) for servers and of the > > form (i.e., node identifier, domain > > identifier, and resource identifier) for clients. The initiating > > entity MAY process the authzid-value in accordance with the rules > > defined in Addressing Scheme (Section 3) before providing it to > > the receiving entity, but is NOT REQUIRED to do so; however, the > > receiving entity MUST verify that the authzid-value provided by > > the initiating entity conforms to the rules defined therein. > > Not all SASL mechanisms are capable of transmitting authorization > identity, so this requirement might be problematic. > > Also, the revision of RFC 2222 says that the client must not specify > authorization-id unless it wants to impersonate some other entity: > > As a client might not have the same information as the server, > clients SHOULD NOT themselves try to derive authorization identities > from authentication identities when clients could instead transmit an > authorization identity of the empty string. > > So, the text should be reworded reflect that an authorization identity > is optional and that if one is provided, it is in the form described above. My understanding from an earlier thread on the XMPP WG list was that providing the authorization identity in this manner was the approach preferred by the SASL community. I think the fundamental issue here is that for XMPP clients, the authorization identity is a "full JID" (i.e., node@host/resource) that is asserted by the connecting client, not derived by the server. Perhaps this usage is not consistent with the definition of authorization identity in RFC 2222? We'd have to look at the implications of this for client assertion of a full JID (perhaps this should be defined only in draft-ietf-xmpp-im). > 2). > > > This series of challenge/response pairs continues until one of three > > things happens: > > > > 1. The initiating entity aborts the handshake by sending an > > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > > namespace to the receiving entity. Upon receiving the > > element, the receiving entity MUST terminate the TCP connection. > > I think the requirement to drop TCP connection is unreasonable here. > There are several valid reasons why the client may retry failed > authentication: > 1). User typed in a wrong password, the client should retry the same > SASL mechanism a reasonable number of times. > 2). The client invoked a SASL mechanism that reported that it can't be > used because of misconfiguration (e.g. kerberos configuration file is > missing). The client than sends to the server and tries another > mechanism. This seems reasonable. I think we were attempting to ensure that the connecting entity could not abuse the opened TCP connection for an unspecified period of time. > 3). > > > 3. The receiving entity reports success of the handshake by sending > > a element qualified by the > > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > > entity; this element MAY optionally contain character data (in > > SASL terminology "additional data with success"). Upon receiving > > the element, the initiating entity MUST initiate a new > > stream by sending an opening XML stream header to the receiving > > entity (it is not necessary to send a closing > > element first, since the receiving entity and initiating entity > > MUST consider the original stream to be closed upon sending or > > receiving the element). Upon receiving the new stream > > header from the initiating entity, the receiving entity MUST > > respond by sending a new XML stream header to the initiating > > entity, along with any remaining available features (but NOT > > including the STARTTLS feature or any authentication mechanisms) > > or an empty features element (to signify that no additional > > features are available); note that any such additional features > > are not defined herein, and MUST be defined by the relevant > > extension to XMPP. > > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a > successful SASL authentication. > Some of them require that the client compares the list of the advertised > mechanism with the one before the authentication. > This is done to prevent man-in-the-middle attacks when an attacker > removes strong SASL mechanisms from the list of supported mechanisms. > (Whether this check is useful in practice is another matter. I am not > sure whether anybody implements it). OK, I'll look at what those other protocols require, and how they word the requirement. It seems good to have this check in place. > 4). There was a recent discussion on the bugtraq mailing list about > handling invalid base64 data. It turned out that different > implementations handle > this differently, for example: > 1). Ignore invalid characters > 2). Treat an invalid character as the end of the base64 encoded data > (and ignore the rest) > 3). Truncate base64 encoded data before the invalid character. > > In particular there was a discussion regarding the padding character > ('=') in the middle of a base64 data. > > I suggest that some text about this be added to the Security > considerations sections. For example: > > Both the client and the server should verify the received base64 data > and reject (and not ignore) any characters not explicitly allowed by the > base64 alphabet > [BASE64] and should reject any sequence of base64 characters that > contains the pad ('=') character not as the last > character of the (e.g. "=AAA" or "BBBB=CCC"). > > [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", > RFC 3548, July 2003. Thanks for the suggested text. > (You might decide to relax this for XMPP and to allow spaces and/or > CRLFs anywhere in the data.) I see no strong reason to relax the requirement just for XMPP. > 5). > >6.3 SASL Errors > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > Do you mean invalid base64 encoding here or something else? It could be invalid base64 encoding, but we were thinking especially that the decoded response is not consistent with the challenge format required by the selected SASL mechanism. > 6). > > >6.3 SASL Errors > > > > The following SASL-related error conditions are defined: > > > > o -- The receiving entity acknowledges an > > element sent by the initiating entity; sent in response to the > > element. > > > > o -- The data provided by the initiating entity > > could not be processed, e.g. because does not adhere to the > > protocol for the requested mechanism; sent in response to the > > element. > > or with initial challenge data. Example: SASL PLAIN mechanism. > > > o -- The mechanism chosen by the initiating > > entity may be used only if the stream is already encrypted; sent > > in response to the element. > > > > o -- The authzid provided by the initiating > > entity is invalid, either because it is incorrectly formatted or > > because the initiating entity does not have permissions to > > authorize that ID; sent in response to a element. > > or with initial challenge data. > > > o -- The initiating entity did not provide a > > mechanism or requested a mechanism that is not supported by the > > receiving entity; sent in response to the element. > > > > o -- The realm provided by the initiating entity > > (in mechanisms that support the concept of a realm) does not match > > one of the hostnames served by the receiving entity; sent in > > response to a element. > > or with initial challenge data. > > > o -- The mechanism requested by the initiating > > entity is weaker than server policy permits for that initiating > > entity; sent in response to the element. > > or with initial challenge data. > > > o -- The authentication failed because the > > initiating entity did not provide valid credentials (this includes > > the case of an unknown username); sent in response to a > element. > > or with initial challenge data. I've fixed these in my working copy. > 7). > > >12.4 Order of Layers > > > > The order of layers in which protocols MUST be stacked is as follows: > > > > 1. TCP > > > > 2. TLS > > > > 3. SASL > > > > 4. XMPP > > > > The rationale for this order is that TCP is the base connection layer > > used by all of the protocols stacked on top of TCP, TLS is often > > provided at the operating system layer, SASL is often provided at the > > application layer, and XMPP is the application itself. > > This should be referenced in "6.4 SASL Definition" section, because it > is related to the XMPP profile of SASL. Fixed in my working copy. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOxKP055202 for ; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98GOxTG055201 for ietf-sasl-bks; Wed, 8 Oct 2003 09:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GOvKP055196 for ; Wed, 8 Oct 2003 09:24:58 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 17:24:57 +0100 Message-ID: <3F843A58.20103@isode.com> Date: Wed, 08 Oct 2003 17:24:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org, Peter Saint-Andre Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <6370000.1065622769@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>>>> When using SASL underneath a sufficiently strong Transport Security >>>>> service, a SASL security layer would most likely be redundant. The >>>>> client and server would thus probably want to negotiate off the use >>>>> of a SASL security layer. >>>> >>> Please don't say this without a _lot_ more text explaining when it is >>> safe. A common configuration is to run SASL under TLS, using SASL for >>> client authentication and negotation of the authorization identity. >>> In this configuration, it is _not_ safe to skip using a SASL security >>> layer if the client did not check the server's certificate (there is a >>> tunnelling MitM attack), and it's not a particularly good idea even if >>> the server cert was checked, because the client's authentication is >>> still not bound to the encryption keys used at the TLS layer. >>> >>> We already have problems with people who think it is actively bad to >>> use a SASL security layer under TLS. The result is that some insecure >>> configurations are now widely deployed. Let's not encourage this any >>> further. >> >> Should I just drop this paragraph? > > Yeah, IMHO it would be reasonable to just drop the paragraph starting > "When using SASL underneath..." Done. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZKKP051880 for ; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98FZKF7051879 for ietf-sasl-bks; Wed, 8 Oct 2003 08:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98FZJKP051870 for ; Wed, 8 Oct 2003 08:35:19 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZBaZ018004; Wed, 8 Oct 2003 08:35:11 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h98FZB5b002839; Wed, 8 Oct 2003 08:35:11 -0700 Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F84154B.7080006@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> <3F84154B.7080006@oceana.com> 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: On Wed, 8 Oct 2003, Ken Murchison wrote: > > Especially since c-client is the first, reference, and most widely > > deployed implementation of the LOGIN mechanism; and was written by its > > inventor. > I'm not going to argue numbers, but I'm guessing that there are a > significant number of deployed Outlook clients. ;) Even if Outlook may be more widespread, there are millions of deployed Pine clients (we have the numbers). c-client is more than just client code; it's also the engine behind UW imapd and ipop3d. UW imapd is the most widely deployed IMAP server. > Your comment seems somewhat self serving, Well, I could say the same for many comments from ... Let's not go here. > but I also find it distasteful > to have to cater to M$. > The problem is that LOGIN was never a standard, > and M$ took it and did their (incorrect) own thing. LOGIN was not documented because I followed the rules. IESG said "no more plaintext password authentication mechanisms." IESG didn't offer any wiggle room the way. Politics allowed PLAIN to be snuck through but not LOGIN (which preceeded PLAIN by 3 1/2 years). If you're going to cater to Microsoft's bugs, then much of IMAP needs to be thrown out because of broken behavior in their software. Microsoft should be made to fix their bugs instead. I would like to see the security people redefine TLS so that that the maximum payload is 5 bytes less than 16K (rather than 16K), since Microsoft requires that. > This is probably because c-client isn't used in any SMTP server code (at > least AFAIK). AFAIK, the challenge strings are only an issue with > Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a > SHOULD/MUST for SMTP server code only. I don't think this will make > c-client noncompliant, will it? I am working an an SMTP server. I don't think that an SMTP-only kludge to accomodate a bug is appropriate when there is another alternative (that is, PLAIN). The correct answer is that if Outlook has problems using LOGIN, then it can always use PLAIN. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98EJnKP048151 for ; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98EJnH8048149 for ietf-sasl-bks; Wed, 8 Oct 2003 07:19:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98EJiKP048140 for ; Wed, 8 Oct 2003 07:19:44 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa18273; 8 Oct 2003 10:19 EDT Date: Wed, 08 Oct 2003 10:19:29 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <6370000.1065622769@mariner.pc.cs.cmu.edu> In-Reply-To: <3F840549.3040101@isode.com> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <3F840549.3040101@isode.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 08, 2003 13:38:33 +0100 Alexey Melnikov wrote: >>>> 8.3. Change control >>>> >>>> Once a SASL mechanism registration has been published by IANA, the >>>> author may request a change to its definition. The change request >>>> follows the same procedure as the registration request. >>> >> This sounds a lot like the stringprep loophole, and it makes me nervous. > > Can you be more specific in what do you want to be changed. No. Perhaps I'm being paranoid, but the concern is that if mechanism FOO gets registered and implemented, no one should be able to come along later and change FOO to mean some other, non-compatible mechanism. Maybe it's not worth worrying about.. In any case, no, I can't be more specific; I don't know what change could make this better, and I don't think I was really asking for one. It just makes me nervous. > Would you rather reference the SASL WG as the Change Controller? No, especially since the SASL WG will likely conclude within the foreseeable future. >>>> In certain situations, it is reasonable to use SASL underneath one of >>>> these Transport Security services. The transport service would >>>> secure the connection, either service would authenticate the client, >>>> and SASL would negotiate the authorization identity. The SASL >>>> negotiation would be what moves the protocol from "unauthenticated" >>>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>>> explicitly intended to handle the case where the transport service >>>> secures the connection and authenticates the client and SASL >>>> negotiates the authorization identity. >>>> >>>> When using SASL underneath a sufficiently strong Transport Security >>>> service, a SASL security layer would most likely be redundant. The >>>> client and server would thus probably want to negotiate off the use >>>> of a SASL security layer. >>> >> >> Please don't say this without a _lot_ more text explaining when it is >> safe. A common configuration is to run SASL under TLS, using SASL for >> client authentication and negotation of the authorization identity. >> In this configuration, it is _not_ safe to skip using a SASL security >> layer if the client did not check the server's certificate (there is a >> tunnelling MitM attack), and it's not a particularly good idea even if >> the server cert was checked, because the client's authentication is >> still not bound to the encryption keys used at the TLS layer. >> >> We already have problems with people who think it is actively bad to >> use a SASL security layer under TLS. The result is that some insecure >> configurations are now widely deployed. Let's not encourage this any >> further. > > Should I just drop this paragraph? Yeah, IMHO it would be reasonable to just drop the paragraph starting "When using SASL underneath..." >> Put the TOC at the _top_ of the document, just after the abstract. >> See the "Tabel of Contents" section at >> http://www.rfc-editor.org/policy.html > > This is editorial and I don't want to spend time doing this at this stage. > I am going to sort this out with the RFC editor directly. Fair enough. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx1KP047180 for ; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Dx1Gc047179 for ietf-sasl-bks; Wed, 8 Oct 2003 06:59:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98Dx0KP047174 for ; Wed, 8 Oct 2003 06:59:00 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:59:01 +0100 Message-ID: <3F841823.6010502@isode.com> Date: Wed, 08 Oct 2003 14:58:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: WG Last Call on draft-ietf-sasl-rfc2222bis-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have an impression that there are two many little things to change so that we will need a new Last Call anyway. Is my perception correct? If it is, I will issue a new revision shortly. Below is the list of open issues I still have to deal with (read this: I am planning to either update the document or send my comments): 1). IANA considerations and registering a familily of SASL mechanisms. 2). Clarification on replacing a security layer 3). Realm 4). Other minor editorial issues. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwCKP047147 for ; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DwCW6047146 for ietf-sasl-bks; Wed, 8 Oct 2003 06:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DwBKP047141 for ; Wed, 8 Oct 2003 06:58:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:58:10 +0100 Message-ID: <3F8417F0.6000407@isode.com> Date: Wed, 08 Oct 2003 14:58:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >>7. The EXTERNAL mechanism >> >> The mechanism name associated with external authentication is >> "EXTERNAL". >> >> The client sends an initial response with the UTF-8 encoding of the >> authorization identity. The form of the authorization identity is >> further restricted by the application-level protocol's SASL profile. >> >> The server uses information, external to SASL, to determine whether >> the client is authorized to authenticate as the authorization >> identity. >> >> > >It may be appropriate to note that the client can make no >assumptions as what information the server uses in determining >client authorization. E.g., just because TLS was established, >doesn't mean the server will use TLS-provided information. > > Done. The new text reads: The system providing this external information may be, for example, IPSec or TLS. However, the client can make no assumptions as to what information the server can use in determining client authorization. E.g., just because TLS was established, doesn't mean that the server will use the information provided by TLS. >>7.2. Example >> >> The following is an example of an EXTERNAL authentication in the SMTP >> protocol [SMTP-AUTH]. >> >> > >Replace [SMTP-AUTH] with an informative reference to the SMTP base >specification. Insert [SMTP-AUTH] after the word "profile" below. > Done. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiNKP046617 for ; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DiNVd046616 for ietf-sasl-bks; Wed, 8 Oct 2003 06:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DiJKP046606 for ; Wed, 8 Oct 2003 06:44:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h98DiBo5027156; Wed, 8 Oct 2003 09:44:11 -0400 (EDT) Message-ID: <3F84154B.7080006@oceana.com> Date: Wed, 08 Oct 2003 09:46:51 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 7 Oct 2003, Ken Murchison wrote: > >>FWIW, I wanted to make the challenge strings used by M$ products a >>SHOULD and those originally intended by c-client a MAY. Mark is against >>making c-client [semi-]uncompliant, which I can also agree with. > > > Especially since c-client is the first, reference, and most widely > deployed implementation of the LOGIN mechanism; and was written by its > inventor. I'm not going to argue numbers, but I'm guessing that there are a significant number of deployed Outlook clients. ;) > I think that c-client's needs are more important that the evil empire's, > and that it would be reprehensible to change specifications to match a > broken implementation in evil empireware. Your comment seems somewhat self serving, but I also find it distasteful to have to cater to M$. The problem is that LOGIN was never a standard, and M$ took it and did their (incorrect) own thing. Since the cat is already out of the bag, and I don't think we can get M$ to change their code, we have to deal with it. > I have never encountered the reported problems with evil empireware. This is probably because c-client isn't used in any SMTP server code (at least AFAIK). AFAIK, the challenge strings are only an issue with Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a SHOULD/MUST for SMTP server code only. I don't think this will make c-client noncompliant, will it? We probably need more input from others on the list, since Mark and I are just rehashing discussions that we've already had. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXCKP046247 for ; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98DXCSS046246 for ietf-sasl-bks; Wed, 8 Oct 2003 06:33:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98DXBKP046240 for ; Wed, 8 Oct 2003 06:33:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 14:33:05 +0100 Message-ID: <3F841210.7030700@isode.com> Date: Wed, 08 Oct 2003 14:33:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >My main gripe here is that the I-D implied incorrectly that >the IETF character set policy RECOMMENDs protocols be able >to use UTF-8 when the police that protocols are REQUIRED >to be able to use UTF-8. > >I think both these "Per IETF character set policy" statements >should be deleted. Inserting a note like shown below might >be appropriate. > > >> The character encoding scheme used >> >> >(see [CHARSET-POLICY]for IETF policy regarding character sets in IETF protocols) > > > >> for transmitting an authorization identity over protocol is >> specified in each authentication mechanism (with the >> authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> I've changed the first reference as you suggested, and the last to: Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). > > >>>> Per IETF character set >>>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>>> these and other strings in UTF-8 [UTF-8]. >>>> >>>> >>>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>>not support UTF-8 transfer of character data. >>>[CHARSET-POLICY] says: >>> Protocols MUST be able to use the UTF-8 charset, which consists of >>> the ISO 10646 coded character set combined with the UTF-8 character >>> encoding scheme, as defined in [10646] Annex R (published in >>> Amendment 2), for all text. >>> >>> >>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. >>Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. >> >>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> >> Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcaKP043368 for ; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98CcaCQ043367 for ietf-sasl-bks; Wed, 8 Oct 2003 05:38:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98CcZKP043356 for ; Wed, 8 Oct 2003 05:38:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:38:34 +0100 Message-ID: <3F840549.3040101@isode.com> Date: Wed, 08 Oct 2003 13:38:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman wrote: >>> 5. Protocol profile requirements >>> >>> In order to use this specification, a protocol definition MUST supply >>> the following information: >>> >>> A service name, to be selected from the IANA registry of "service" >>> elements for the GSSAPI host-based service name form. [GSSAPI] This >>> service name is made available to the authentication mechanism. >>> >>> The registry is available at the URL >>> "http://www.iana.org/assignments/gssapi-service-names" A definition >> > Paragraph break. Yes, this is already fixed in my copy. >>> A definition of the method by which the authentication protocol >>> exchange is carried out, including how the challenges and responses >>> are encoded, how the server indicates completion or failure of the >>> exchange, how the client aborts an exchange, and how the exchange >>> method interacts with any line length limits in the protocol. >>> >>> The command SHOULD have a method for the server to include an >>> optional challenge with a success notification. This allows the >>> server to avoid a round trip when using a mechanism which is defined >>> to have the server send additional data along with the indication of >>> successful completion. See section 6.2 of this document for further >>> information. >> > What command? Who says "the method by which the authentication > protocol exchange is carried out" is a command? s/The command/The > exchange method/ Yes. >>> 8.3. Change control >>> >>> Once a SASL mechanism registration has been published by IANA, the >>> author may request a change to its definition. The change request >>> follows the same procedure as the registration request. >> > This sounds a lot like the stringprep loophole, and it makes me nervous. Can you be more specific in what do you want to be changed. Would you rather reference the SASL WG as the Change Controller? >>> In certain situations, it is reasonable to use SASL underneath one of >>> these Transport Security services. The transport service would >>> secure the connection, either service would authenticate the client, >>> and SASL would negotiate the authorization identity. The SASL >>> negotiation would be what moves the protocol from "unauthenticated" >>> to "authenticated" state. The "EXTERNAL" SASL mechanism is >>> explicitly intended to handle the case where the transport service >>> secures the connection and authenticates the client and SASL >>> negotiates the authorization identity. >>> >>> When using SASL underneath a sufficiently strong Transport Security >>> service, a SASL security layer would most likely be redundant. The >>> client and server would thus probably want to negotiate off the use >>> of a SASL security layer. >> > > Please don't say this without a _lot_ more text explaining when it is > safe. A common configuration is to run SASL under TLS, using SASL for > client authentication and negotation of the authorization identity. > In this configuration, it is _not_ safe to skip using a SASL security > layer if the client did not check the server's certificate (there is a > tunnelling MitM attack), and it's not a particularly good idea even if > the server cert was checked, because the client's authentication is > still not bound to the encryption keys used at the TLS layer. > > We already have problems with people who think it is actively bad to > use a SASL security layer under TLS. The result is that some insecure > configurations are now widely deployed. Let's not encourage this any > further. Should I just drop this paragraph? >>> The IANA is directed to modify the SASL mechanisms registry as >>> follows: >> >> >> Please reword this to be not so demanding. For example, >> It is requested that IANA update the SASL mechanisms registry >> as follows: > > > It's not demanting; it's perfectly reasonable usage. The IANA works > for the IETF; it is appropriate for the IETF, in the form of a > standards-track document, to direct it to make changes to a registry. > It is also common usage. I've already changed this to be "nicer" to IANA ;-). > Put the TOC at the _top_ of the document, just after the abstract. > See the "Tabel of Contents" section at > http://www.rfc-editor.org/policy.html This is editorial and I don't want to spend time doing this at this stage. I am going to sort this out with the RFC editor directly. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6RKP042074 for ; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98C6RTI042073 for ietf-sasl-bks; Wed, 8 Oct 2003 05:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98C6PKP042068 for ; Wed, 8 Oct 2003 05:06:26 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 13:06:21 +0100 Message-ID: <3F83FDBB.70702@isode.com> Date: Wed, 08 Oct 2003 13:06:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Proxy authentication (was WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt) References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Because there are too many issues raised I will be starting a separate thread for each] Kurt D. Zeilenga wrote: >> During the authentication protocol exchange, the mechanism performs >> authentication, transmits an authorization identity (frequently known >> as a userid) from the client to server, and negotiates the use of a >> mechanism-specific security layer. If the use of a security layer is >> agreed upon, then the mechanism must also define or negotiate the >> maximum security layer buffer size that each side is able to receive. >> >>4.2. Authorization identities and proxy authentication >> > > >See note below regarding the term "proxy authentication". > > > ... >> The identity derived from the client's authentication credentials is >> known as the "authentication identity". With any mechanism, >> transmitting an authorization identity of the empty string directs >> the server to derive an authorization identity from the client's >> authentication identity. >> >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". >> >> > >Personally, I refer to this as "proxy authorization". Proxy >authentication makes it sound like the feature can be used by a >proxy to authenticate its users. > > > Jeffrey Hutzelman wrote: >>> If the authorization identity transmitted during the authentication >>> protocol exchange is not the empty string, this is typically referred >>> to as "proxy authentication". >> >> Personally, I refer to this as "proxy authorization". Proxy >> authentication makes it sound like the feature can be used by a >> proxy to authenticate its users. > > The same argument can be made for "proxy authorization". We are > talking about "authentication by proxy", not "authentication to a > proxy". And yes, we're really talking about authorization, not > authentication, but it's not really "authorization by proxy"; it's > just authorization. > > The terminology is pretty bad. It's not clear to me that we need a > name for this at all. But I'm pretty sure the phrase "proxy > authentication" has been in use for a while, and to change it might > cause more confusion than leaving it alone. So, I will leave it as is. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqMKP041254 for ; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98BqMs2041253 for ietf-sasl-bks; Wed, 8 Oct 2003 04:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98BqGKP041248 for ; Wed, 8 Oct 2003 04:52:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Wed, 8 Oct 2003 12:52:14 +0100 Message-ID: <3F83FA6D.1030909@isode.com> Date: Wed, 08 Oct 2003 12:52:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sorry about coming with these comments so late. I have just discovered >the SASL list, and there was a lot to read:-) >Feel free to ignore comments that have already been discussed. > >>4. Authentication mechanisms >> >> SASL mechanisms are named by >> >> > >ASCII > > > >> strings, >> (...) >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase >> >> > >ASCII > Ok. >>letters, >> ; digits, "-" and "_" >> >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; >> >> > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > IMHO, this was the intent. I will try to clarify this. >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, >> > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? > Does it matter in this section? >>4.2. Authorization identities and proxy authentication >> >> (...) >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> >> > ^^^^ > >What's a blob? I don't think it's 'something ill-defined or amorphous', >like the dictionary says:-) > I've changed this to "data". >>4.3. Security layers >> >> If use of a security layer is negotiated by the authentication >> protocol exchange, the security layer is applied to all subsequent >> data sent over the connection >> > >... until another security layer or no security layer is negotiated. > >[Added according to section 6.3.] > > > Done. >> In >> order to avoid noninteroperability due to differing normalizations, >> when a mechanism specifies that a string authentication identity or >> password used as input to a cryptographic function (or used for >> comparison) it SHOULD specify that the string first be prepared using >> the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm >> [StringPrep]. This should be done by both the client (upon getting >> user input or retrieving a value from configuration) and by the >> server (upon receiving the value from the client). >> >> > >What's the point of this duplicate preparation? Why not do it only >at the server side? > > Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] >> > >Nitpick: I think the period should be after [GSSAPI]. > Fixed. >> This >> service name is made available to the authentication mechanism. >> >> > >There should be no paragraph break here. > Fixed. >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" >> >> > >Instead, a paragraph break here. (And a trailing '.'.) > > Fixed. >> A definition >> of the command to initiate the authentication protocol exchange. >> >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. >> >> > >I suggest you rename "an optional challenge" to "optional data", or >put "challenge" in quotes. > > Ok. >> A protocol profile MAY further refine the definition of an >> authorization identity by adding additional syntactic restrictions >> and protocol-specific semantics. >> >> > >Add a paragraph break here, since the following is a new item. Remove >"A protocol profile MUST specify" to just make the following a new item >in the list of things that must be specified. > > > >> A protocol profile MUST specify the >> form of the authorization identity (as it is protocol specific, as >> >> I would rather not do this, as this is a single logic item. > > > >>6.3. Multiple authentications >> >> Unless otherwise stated by the protocol's profile, only one >> successful SASL negotiation may occur in a protocol session. >> >> > >This should be mentioned in the "Protocol profile requirements" section. > I agree. >>7.1. Formal syntax >> >> initial-response = *( UTF8-char-no-null ) >> >> > >Why is initial-response required to be UTF-8 when the character encoding >scheme of the rest of the exchange is left to the specifications of the >individual mechanisms? I would think that either initial-response >merely "SHOULD" be UTF-8, like the rest of the exchange. > This is specific to EXTERNAL. I've changed "initial-response" to "extern-init-resp" in order to avoid confusion. > > > >And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the >top. > > I've added a sentence about this in the introduction section. Alexey > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986spKP098288 for ; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h986spsu098287 for ietf-sasl-bks; Tue, 7 Oct 2003 23:54:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h986soKP098275 for ; Tue, 7 Oct 2003 23:54:50 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h986smlg075769; Wed, 8 Oct 2003 06:54:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008112004.02b2a0b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 11:54:31 -0700 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Cc: ietf-sasl@imc.org In-Reply-To: <2070817856.1065023014@mariner.pc.cs.cmu.edu> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> <2070817856.1065023014@mariner.pc.cs.cmu.edu> 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: My main gripe here is that the I-D implied incorrectly that the IETF character set policy RECOMMENDs protocols be able to use UTF-8 when the police that protocols are REQUIRED to be able to use UTF-8. I think both these "Per IETF character set policy" statements should be deleted. Inserting a note like shown below might be appropriate. > The character encoding scheme used (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols) for > transmitting an authorization identity over protocol is > specified in each authentication mechanism (with the > authentication mechanism's blob being further > restricted/encoded by the protocol profile). At 08:43 AM 10/1/2003, Jeffrey Hutzelman wrote: >>> Per IETF character set >>> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >>> these and other strings in UTF-8 [UTF-8]. >> >>This seems counter to [CHARSET-POLICY] as it allows a mechanism to >>not support UTF-8 transfer of character data. >>[CHARSET-POLICY] says: >> Protocols MUST be able to use the UTF-8 charset, which consists of >> the ISO 10646 coded character set combined with the UTF-8 character >> encoding scheme, as defined in [10646] Annex R (published in >> Amendment 2), for all text. > >It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. >While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. > Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. > >So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SnKP070098 for ; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h985Sn0O070096 for ietf-sasl-bks; Tue, 7 Oct 2003 22:28:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985SlKP070085 for ; Tue, 7 Oct 2003 22:28:48 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h985Splg075247; Wed, 8 Oct 2003 05:28:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008095643.02b27bf0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 10:28:30 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: empty authzid in draft-ietf-sasl-plain-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: 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: At 06:49 AM 10/1/2003, Hallvard B Furuseth wrote: >draft-ietf-sasl-plain-02.txt says that > > The client leaves > the authorization identity empty if it wishes the server to derive the > authorization identity from the provided authentication identity. > >and > > Note that the parameters provided to the Authorize function are not > prepared. > >so I think the pseudo-code for empty authzid should say > authzid = DeriveAuthzid(authcid); >and not > authzid = DeriveAuthzid(pAuthcid); I think the current psuedo-code is correct, the first quoted text is misleading. The word "provided" should be deleted as it implies the provided representation (as opposed to prepared representation of the provided authentication identity). Also, I recommend the following text be added immediately above the paragraph which ends with "that string MUST be prepared before generation of the hash." When the no authorization identity is provided, the server SHALL derive the authorization identity from the prepared representation of the provided authentication identity string. This ensures that the derivation of different representations of the authentication identity produce the same authorization identity. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bIKP062198 for ; Tue, 7 Oct 2003 21:37:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h984bIKP062197 for ietf-sasl-bks; Tue, 7 Oct 2003 21:37:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984bFKP062190 for ; Tue, 7 Oct 2003 21:37:17 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h984bHlg074914; Wed, 8 Oct 2003 04:37:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008090509.03ad6350@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 09:37:00 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments Cc: ietf-sasl@imc.org In-Reply-To: References: 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: Hallvard, This wording concerns me a bit too. I think we need to have one registry which lists all "public" mechanisms. Hence, I suggest the text be reworded to allow a standard track RFC to establish additional registration requirements for portions of the name space (or "families of names"). That is, the SASL-GSSAPI specification can establish additional requirements for GSSAPI mechanisms. However, SASL-GSSAPI cannot (without updating the base specification) remove requirements established by the base specification. Also, I think having the text belongs only in the IANA Considerations section. Section 4 should just say SASL mechanism names must be registered with the IANA in accordance with Section 8 of this document. Section 8 should include both the guidelines for IANA to follow (for individual names and for families of names) and procedures for those requesting registration. (I suggest having two subsections "Guidelines for IANA" and "Registration Procedures". Kurt At 01:48 PM 9/30/2003, Hallvard B Furuseth wrote: >> SASL mechanism names must be registered with the IANA. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; > >Huh? So I must search through all Standards Track RFCs as well as the >IANA registry in order to find out if a mechanism name is reserved? >Why not register these name reservations with IANA too? > >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, > >Does this mean that the initial auth command from the client is not >considered part of the authentication protocol exchange? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OUKP055551 for ; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h981OUx6055550 for ietf-sasl-bks; Tue, 7 Oct 2003 18:24:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h981OSKP055545 for ; Tue, 7 Oct 2003 18:24:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUmw007879; Tue, 7 Oct 2003 18:24:30 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h981OUx1021400; Tue, 7 Oct 2003 18:24:30 -0700 Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT) From: Mark Crispin To: Ken Murchison cc: "Kurt D. Zeilenga" , Steven F Siirila , SASL mailing list Subject: Re: draft-murchison-sasl-login-00 Last Call In-Reply-To: <3F834860.6050807@oceana.com> Message-ID: References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> <3F834860.6050807@oceana.com> 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: On Tue, 7 Oct 2003, Ken Murchison wrote: > FWIW, I wanted to make the challenge strings used by M$ products a > SHOULD and those originally intended by c-client a MAY. Mark is against > making c-client [semi-]uncompliant, which I can also agree with. Especially since c-client is the first, reference, and most widely deployed implementation of the LOGIN mechanism; and was written by its inventor. I think that c-client's needs are more important that the evil empire's, and that it would be reprehensible to change specifications to match a broken implementation in evil empireware. I have never encountered the reported problems with evil empireware. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NqLKP052559 for ; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NqLck052558 for ietf-sasl-bks; Tue, 7 Oct 2003 16:52:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from web103.bizmail.yahoo.com (web103.bizmail.yahoo.com [216.136.172.120]) by above.proper.com (8.12.9/8.12.8) with SMTP id h97NqJKP052551 for ; Tue, 7 Oct 2003 16:52:19 -0700 (PDT) (envelope-from syy@gama-tech.com) Message-ID: <20031007234715.54450.qmail@web103.bizmail.yahoo.com> Received: from [218.102.39.129] by web103.bizmail.yahoo.com via HTTP; Tue, 07 Oct 2003 16:47:15 PDT Date: Tue, 7 Oct 2003 16:47:15 -0700 (PDT) From: SY Yip Subject: linkage to data security To: ietf-sasl@imc.org 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: Hi All I'm new to this list. Just wonder if ietf-sasl addresses the linkage of authentication to data security. Meaning, a user logs on to a system, the system is able to use the user identity to determine data access security from LDAP or RDBMS. Today most applications can authenticate users but they use system id to connect to LDAP or RDBMS. As a result, they can't link the login ID to Data Access. Much appreciated for any help. Regards sy yip Gama Technology Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NCmKP051035 for ; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NCmoY051034 for ietf-sasl-bks; Tue, 7 Oct 2003 16:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NClKP051017 for ; Tue, 7 Oct 2003 16:12:47 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4d-167.buf.adelphia.net [68.66.168.167]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97NCao5011151; Tue, 7 Oct 2003 19:12:40 -0400 (EDT) Message-ID: <3F834860.6050807@oceana.com> Date: Tue, 07 Oct 2003 19:12:32 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Steven F Siirila , SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: > Ken, > > This use of MAY is a bit problematic. MAY items are suppose to be > truly optional (see RFC 2119). As servers using the > alternative protocol tokens won't interoperate with client not > expecting those alternatives, this item isn't. > > Likely this can be addressed by (more explicitly) limiting the > applicability of the option. I'll let Mark argue for the continued use of MAY. FWIW, I wanted to make the challenge strings used by M$ products a SHOULD and those originally intended by c-client a MAY. Mark is against making c-client [semi-]uncompliant, which I can also agree with. Cyrus SASL uses the M$ challenges and we are not aware of any products which fail to work with these strings, since clients other than M$ correctly ignore the contents of the challenges. Mark, Rob and myself struggled with this issue a lot. >>Steven F Siirila wrote: >> >> >>>In reading section 2.2: >>>2.2. Server side of authentication protocol exchange >>> The server issues the string "User Name" in challenge, and receives a >>> client response. This response is recorded as the authorization >>> identity. The server then issues the string "Password" in challenge, >>> and receives a client response. This response is recorded as the >>> authorization authenticator. The server must verify that the >>> authorization authenticator permits login as the authorization >>> identity. >>> Note: There is at least one widely deployed client which requires >>> that the challenge strings transmitted by the server be "Username:" >>> and "Password:" respectively. For this reason, server >>> implementations MAY send these challenge strings instead of those >>> listed above. >>>Why is the string "User name" chosen as the suggested challenge to be sent >>>by the server instead of "Username:", considering that second paragraph? >>>Are there other clients out there that expect "User name" as a challenge >>>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>>"Password:". >> >>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). >> >>The wording in the draft is a compromise between the authors. >> >>-- >>Kenneth Murchison Oceana Matrix Ltd. >>Software Engineer 21 Princeton Place >>716-662-8973 x26 Orchard Park, NY 14127 >>--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4RKP047888 for ; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97M4R4U047887 for ietf-sasl-bks; Tue, 7 Oct 2003 15:04:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M4QKP047881 for ; Tue, 7 Oct 2003 15:04:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h97M4Mlg071146; Tue, 7 Oct 2003 22:04:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031008025723.03a7e808@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 08 Oct 2003 03:04:05 -0700 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: draft-murchison-sasl-login-00 Last Call Cc: Steven F Siirila , SASL mailing list , Mark Crispin In-Reply-To: <3F83083F.10600@oceana.com> References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> <3F83083F.10600@oceana.com> 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: Ken, This use of MAY is a bit problematic. MAY items are suppose to be truly optional (see RFC 2119). As servers using the alternative protocol tokens won't interoperate with client not expecting those alternatives, this item isn't. Likely this can be addressed by (more explicitly) limiting the applicability of the option. Kurt At 11:38 AM 10/7/2003, Ken Murchison wrote: >Steven F Siirila wrote: > >>In reading section 2.2: >>2.2. Server side of authentication protocol exchange >> The server issues the string "User Name" in challenge, and receives a >> client response. This response is recorded as the authorization >> identity. The server then issues the string "Password" in challenge, >> and receives a client response. This response is recorded as the >> authorization authenticator. The server must verify that the >> authorization authenticator permits login as the authorization >> identity. >> Note: There is at least one widely deployed client which requires >> that the challenge strings transmitted by the server be "Username:" >> and "Password:" respectively. For this reason, server >> implementations MAY send these challenge strings instead of those >> listed above. >>Why is the string "User name" chosen as the suggested challenge to be sent >>by the server instead of "Username:", considering that second paragraph? >>Are there other clients out there that expect "User name" as a challenge >>string? Note that the current Cyrus SASL (V2) returns "Username:" and >>"Password:". > >The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). > >The wording in the draft is a compromise between the authors. > >-- >Kenneth Murchison Oceana Matrix Ltd. >Software Engineer 21 Princeton Place >716-662-8973 x26 Orchard Park, NY 14127 >--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97LoFKP047316 for ; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97LoFOf047315 for ietf-sasl-bks; Tue, 7 Oct 2003 14:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Lo9KP047305 for ; Tue, 7 Oct 2003 14:50:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Tue, 7 Oct 2003 22:49:34 +0100 Message-ID: <3F8334ED.80504@isode.com> Date: Tue, 07 Oct 2003 22:49:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre , Jeremie Miller CC: iesg@ietf.org, xmppwg@jabber.org, SASL WG Subject: Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard) References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG wrote: >The IESG has received a request from the Extensible Messaging and Presence >Protocol WG to consider the following document: > >- 'XMPP Core ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-09. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt > I would like to raise several SASL related issues in XMPP document. (Sorry for crosspost and sorry for being late with reviewing this.) 1). > 7. The initiating entity MUST provide an authzid during SASL > negotiation. The authzid-value MUST be a valid JID of the form > (i.e., a domain identifier only) for servers and of the > form (i.e., node identifier, domain > identifier, and resource identifier) for clients. The initiating > entity MAY process the authzid-value in accordance with the rules > defined in Addressing Scheme (Section 3) before providing it to > the receiving entity, but is NOT REQUIRED to do so; however, the > receiving entity MUST verify that the authzid-value provided by > the initiating entity conforms to the rules defined therein. Not all SASL mechanisms are capable of transmitting authorization identity, so this requirement might be problematic. Also, the revision of RFC 2222 says that the client must not specify authorization-id unless it wants to impersonate some other entity: As a client might not have the same information as the server, clients SHOULD NOT themselves try to derive authorization identities from authentication identities when clients could instead transmit an authorization identity of the empty string. So, the text should be reworded reflect that an authorization identity is optional and that if one is provided, it is in the form described above. 2). > This series of challenge/response pairs continues until one of three > things happens: > > 1. The initiating entity aborts the handshake by sending an > element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' > namespace to the receiving entity. Upon receiving the > element, the receiving entity MUST terminate the TCP connection. I think the requirement to drop TCP connection is unreasonable here. There are several valid reasons why the client may retry failed authentication: 1). User typed in a wrong password, the client should retry the same SASL mechanism a reasonable number of times. 2). The client invoked a SASL mechanism that reported that it can't be used because of misconfiguration (e.g. kerberos configuration file is missing). The client than sends to the server and tries another mechanism. 3). > 3. The receiving entity reports success of the handshake by sending > a element qualified by the > 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating > entity; this element MAY optionally contain character data (in > SASL terminology "additional data with success"). Upon receiving > the element, the initiating entity MUST initiate a new > stream by sending an opening XML stream header to the receiving > entity (it is not necessary to send a closing > element first, since the receiving entity and initiating entity > MUST consider the original stream to be closed upon sending or > receiving the element). Upon receiving the new stream > header from the initiating entity, the receiving entity MUST > respond by sending a new XML stream header to the initiating > entity, along with any remaining available features (but NOT > including the STARTTLS feature or any authentication mechanisms) > or an empty features element (to signify that no additional > features are available); note that any such additional features > are not defined herein, and MUST be defined by the relevant > extension to XMPP. Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a successful SASL authentication. Some of them require that the client compares the list of the advertised mechanism with the one before the authentication. This is done to prevent man-in-the-middle attacks when an attacker removes strong SASL mechanisms from the list of supported mechanisms. (Whether this check is useful in practice is another matter. I am not sure whether anybody implements it). 4). There was a recent discussion on the bugtraq mailing list about handling invalid base64 data. It turned out that different implementations handle this differently, for example: 1). Ignore invalid characters 2). Treat an invalid character as the end of the base64 encoded data (and ignore the rest) 3). Truncate base64 encoded data before the invalid character. In particular there was a discussion regarding the padding character ('=') in the middle of a base64 data. I suggest that some text about this be added to the Security considerations sections. For example: Both the client and the server should verify the received base64 data and reject (and not ignore) any characters not explicitly allowed by the base64 alphabet [BASE64] and should reject any sequence of base64 characters that contains the pad ('=') character not as the last character of the (e.g. "=AAA" or "BBBB=CCC"). [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. (You might decide to relax this for XMPP and to allow spaces and/or CRLFs anywhere in the data.) 5). >6.3 SASL Errors > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. Do you mean invalid base64 encoding here or something else? 6). >6.3 SASL Errors > > The following SASL-related error conditions are defined: > > o -- The receiving entity acknowledges an > element sent by the initiating entity; sent in response to the > element. > > o -- The data provided by the initiating entity > could not be processed, e.g. because does not adhere to the > protocol for the requested mechanism; sent in response to the > element. or with initial challenge data. Example: SASL PLAIN mechanism. > o -- The mechanism chosen by the initiating > entity may be used only if the stream is already encrypted; sent > in response to the element. > > o -- The authzid provided by the initiating > entity is invalid, either because it is incorrectly formatted or > because the initiating entity does not have permissions to > authorize that ID; sent in response to a element. or with initial challenge data. > o -- The initiating entity did not provide a > mechanism or requested a mechanism that is not supported by the > receiving entity; sent in response to the element. > > o -- The realm provided by the initiating entity > (in mechanisms that support the concept of a realm) does not match > one of the hostnames served by the receiving entity; sent in > response to a element. or with initial challenge data. > o -- The mechanism requested by the initiating > entity is weaker than server policy permits for that initiating > entity; sent in response to the element. or with initial challenge data. > o -- The authentication failed because the > initiating entity did not provide valid credentials (this includes > the case of an unknown username); sent in response to a element. or with initial challenge data. 7). >12.4 Order of Layers > > The order of layers in which protocols MUST be stacked is as follows: > > 1. TCP > > 2. TLS > > 3. SASL > > 4. XMPP > > The rationale for this order is that TCP is the base connection layer > used by all of the protocols stacked on top of TCP, TLS is often > provided at the operating system layer, SASL is often provided at the > application layer, and XMPP is the application itself. This should be referenced in "6.4 SASL Definition" section, because it is related to the XMPP profile of SASL. Cheers, Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaNKP040195 for ; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97IaNbC040194 for ietf-sasl-bks; Tue, 7 Oct 2003 11:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IaLKP040189 for ; Tue, 7 Oct 2003 11:36:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97IaGo5001378; Tue, 7 Oct 2003 14:36:16 -0400 (EDT) Message-ID: <3F83083F.10600@oceana.com> Date: Tue, 07 Oct 2003 14:38:55 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steven F Siirila CC: SASL mailing list , Mark Crispin Subject: Re: draft-murchison-sasl-login-00 Last Call References: <3F82F762.20507@oceana.com> <20031007180404.GA16933@earth.tc.umn.edu> In-Reply-To: <20031007180404.GA16933@earth.tc.umn.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steven F Siirila wrote: > In reading section 2.2: > > 2.2. Server side of authentication protocol exchange > > The server issues the string "User Name" in challenge, and receives a > client response. This response is recorded as the authorization > identity. The server then issues the string "Password" in challenge, > and receives a client response. This response is recorded as the > authorization authenticator. The server must verify that the > authorization authenticator permits login as the authorization > identity. > > Note: There is at least one widely deployed client which requires > that the challenge strings transmitted by the server be "Username:" > and "Password:" respectively. For this reason, server > implementations MAY send these challenge strings instead of those > listed above. > > Why is the string "User name" chosen as the suggested challenge to be sent > by the server instead of "Username:", considering that second paragraph? > Are there other clients out there that expect "User name" as a challenge > string? Note that the current Cyrus SASL (V2) returns "Username:" and > "Password:". The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA). The wording in the draft is a compromise between the authors. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IToKP039969 for ; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97ITo82039968 for ietf-sasl-bks; Tue, 7 Oct 2003 11:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97ITmKP039958 for ; Tue, 7 Oct 2003 11:29:49 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h97ITjo5001254 for ; Tue, 7 Oct 2003 14:29:45 -0400 (EDT) Message-ID: <3F8306B8.3010207@oceana.com> Date: Tue, 07 Oct 2003 14:32:24 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00 Last Call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we did not receive any negative feedback (or positive, for that matter) and Mark, Rob Siemborski and I feel that the current doc accurately describes the existing deployed implementation, I intend ask the IETF to Last Call it shortly. If you have any comments on the existing doc, please send them soon. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnEKP079404 for ; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NnEaN079403 for ietf-sasl-bks; Mon, 6 Oct 2003 16:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnDKP079396 for ; Mon, 6 Oct 2003 16:49:13 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDC2028637; Mon, 6 Oct 2003 16:49:13 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h96NnDSS006277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2003 16:49:13 -0700 Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> Organization: Networks & Distributed Computing 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: On Mon, 6 Oct 2003, Rob Siemborski wrote: > Currently, the argument against > creating such an extention is that "implementors get client-initial-send > wrong" (Specifically, servers get it wrong when clients choose to not > perform the optional initial send). Mark, as this is your argument, > please correct me if I have summarized it incorrectly. Yes, that is an incorrect summary. The argument against creating such an extension is that the current specifications for SASL in POP3 and SMTP (which permit client-initial-send) are complex, and as a result many POP3/SMTP servers are not handling client-initial-send properly when the client does not provide an initial response. Consequently, I do not believe that IMAP should be extended to provide client-initial-send until after the specifications are clarified. This is especially the case because IMAP will be a *more* complex case than POP3/SMTP because client-initial-send is mandatory to implement in POP3/SMTP servers but must be optional (due to compatibility with the installed base) in IMAP servers. Thus, the interoperability matrix with IMAP is 4 possible configurations instead of 2 with POP3/SMTP. The one-line summary: Before making it more complex, fix the existing complexity > Isn't it typical that a SASL implementor should need to look at 3 > documents however? The one for their protocol, the one for the mechanism > that interests them, and RFC2222 or its replacement. Empirical data suggests that this requires considerably more care than currently exists among implementors. An understanding of the correct server behavior for "AUTH PLAIN" in SMTP requires reading three documents. > My personal reading of 2554 is that it could use a lot of rework anyway, > and I'm toying with writing an update to it right now. Such an update > would include examples. Excellent; I'll be glad to help you. > I don't see a strong technical reason for reducing the requirement for > SHOULD to MAY (reducing the round trips used should be encouraged). I do > see a strong argument for making it abundantly clear that servers MUST > implement the correct omitted-challenge behavior (to be distinguished from > an empty challenge -- "" is not the same as NIL) I see it as a matter of semantics. Too many people see a SHOULD as an excuse to overlook a MUST. > The examples situation should be fixed. I don't think that we can expect > SASL implementors to (in the general case) have to read only two RFCs, > especially as we are breaking all of the mechanisms into their own > documents. I fear that it is a lot to expect them to read *one* RFC, much less grasp concepts that only come through by reading three. We seem to be in a world where protocol engines are written by empirical tests and a cursory glance at the examples in RFCs. It is a helpful exercise to go through the steps to figure out what is the correct server response to "AUTH PLAIN" in SMTP. You have to start with 2554, then 2595, then 2222, then back to 2554, then back to 2595. You have to remember certain statements in each of these documents which make no apparent sense until you read certain equally-obscure statements in the other documents. And you have to put this all together. I went through this exercise with someone who I knew to be of above-average intelligence. It took some time before he grasped it. That told me that the documents have a problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGTKP077980 for ; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NGTaG077979 for ietf-sasl-bks; Mon, 6 Oct 2003 16:16:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NGSKP077974 for ; Mon, 6 Oct 2003 16:16:28 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NGT5t009824 for ; Mon, 6 Oct 2003 19:16:29 -0400 Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: SASL Initial Response? (fwd) 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: Here are some of Mark's comments on RFC2222bis: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- ---------- Forwarded message ---------- Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski Cc: RL 'Bob' Morgan , IMAP Extensions WG Subject: Re: SASL Initial Response? On Mon, 6 Oct 2003, Rob Siemborski wrote: > I agree. I also suspect an example or two could help the appropriate > sections of 2222bis. But further discussion of this should probably move > to the ietf-sasl list. I'm not on the ietf-sasl list, so would appreciate this being passed on. I guess that I should be at the SASL session in Minneapolis (assuming I go there which seems likely). Examples are always helpful. Section 6.1 of 2222bis should give examples of AUTH PLAIN in SMTP both with and without initial client data. Similar examples should appear in the specification for the PLAIN mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!) *and* in the specifications for POP3 SASL and SMTP SASL. > Obviously. But currently it seems that the primary reason that we don't > have an initial SASL response in IMAP is concerns over clarity of the > SASL specification. Actually, the primary reason was compatibility with the past; IMAP SASL is older than SASL. I'm willing to go along with it as a server-optional extension *IF* the problems with the current client-optional server-mandatory initial client data POP3/SMTP SASL are fixed. Since implementation of initial client data will be server-optional in IMAP, it will be more complex than in POP3/SMTP. This is because it's mandatory to implement in POP3/SMTP servers. > If fixing *that* specification still isn't good enough, I'm totally > willing to supply text in the draft for the IMAP extention to the effect > of "pay careful attention to the fact that initial responses are > *optional*," even to the point of making it a Security Consideration. We will need that text, and much more. > And indeed, any IMAP server that didn't get this right would immediately > have a large number of old-style clients fail to work against it anyway, > since it is an extention and not part of the base protocol. It's not just IMAP servers we have to worry about. It's also IMAP clients. We already have clients which fail to interoperate with a server that does not have a particular extension and/or declare such servers to be "broken." The offenders know who they are. We have to concern ourselves about the possibility of clients that think that initial data is mandatory to implement in the server (since it is mandatory in POP3 and SMTP). Thus, the situation is *worse* with IMAP than with POP3 or SMTP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFhKP077954 for ; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96NFh8e077953 for ietf-sasl-bks; Mon, 6 Oct 2003 16:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NFfKP077944 for ; Mon, 6 Oct 2003 16:15:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h96NFe5t009820; Mon, 6 Oct 2003 19:15:40 -0400 Date: Mon, 6 Oct 2003 19:15:41 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Ken Murchison , IMAP Extensions WG Subject: Re: SASL Initial Response? In-Reply-To: Message-ID: References: <3F81908D.5000101@oceana.com> <3F8198A2.3070105@oceana.com> <3F81B45E.6050909@oceana.com> 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: I am moving this discussion to the ietf-sasl list, since it seems to have wandered somewhat from a discussion of IMAP's specific case. Background for members of the IETF SASL list: This was part of a discussion in the IMAPEXT working group about the creation of an initial client response extention for IMAP. Currently, the argument against creating such an extention is that "implementors get client-initial-send wrong" (Specifically, servers get it wrong when clients choose to not perform the optional initial send). Mark, as this is your argument, please correct me if I have summarized it incorrectly. On Mon, 6 Oct 2003, Mark Crispin wrote: > On Mon, 6 Oct 2003, Ken Murchison wrote: > > > The most common offense is to implement PLAIN and LOGIN as the same thing, > > > thus giving LOGIN challenges to PLAIN with no initial response. > > That's inexcusable, since they are clearly NOT the same thing, and PLAIN > > has always had a standardized SPEC. Obviously we can't make people read > > the specs correctly, all we can do is make them clear and unambiguous. > > Agreed completely. However, multiple commercial implementations have done > this blunder. > > > > The second most common offense is "334 ok, go on" or "+ ok, go on". > > > Somtimes you also find extra CRLFs in the responses. > > This might be an ambiguous/incomplete specification for SMTP AUTH. I'll > > take a look. > > It's not ambiguous, but you have to read three separate documents (RFCs > 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in > SMTP. For POP3, you just need to read 2222 and 2595. > > There is no single document, and *NO* examples, that explains this. RFC > 2554 is a bit better in talking about empty challenges than 2595 (see > first paragraph of page 3, RFC 2554) but without the context of RFC 2222 > it makes no sense. Isn't it typical that a SASL implementor should need to look at 3 documents however? The one for their protocol, the one for the mechanism that interests them, and RFC2222 or its replacement. My personal reading of 2554 is that it could use a lot of rework anyway, and I'm toying with writing an update to it right now. Such an update would include examples. > > > Over and over again, I get told "just make Pine send the initial > > > challenge"; in other words, that the initial challenge is mandatory. But > > > the SASL specification does not say that; and the idea of inflicting the > > > non-interoperable brokenness of POP/SMTP on IMAP repels me. > > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead > > of SHOULD? For some mechs (e.g. DIGEST-MD5) this could become > > problematic because the initial response truely is optional. > > Actually, I would like the SHOULD to become a MAY, and it be emphasized > that servers MUST implement the correct empty challenge behavior. > > However, a MUST is preferable to the status quo, which is a de jure SHOULD > but (at least according to certain individuals) a de facto MUST. I don't see a strong technical reason for reducing the requirement for SHOULD to MAY (reducing the round trips used should be encouraged). I do see a strong argument for making it abundantly clear that servers MUST implement the correct omitted-challenge behavior (to be distinguished from an empty challenge -- "" is not the same as NIL) > > I will do this. Just to be clear, we are only talking about > > client-first mechanisms in which the client chooses to not send an > > initial response, correct? > > Correct. SMTP is the worst case, since you have to read three RFCs to > work out how to implement PLAIN in SMTP. > > Note that there are no examples. The examples situation should be fixed. I don't think that we can expect SASL implementors to (in the general case) have to read only two RFCs, especially as we are breaking all of the mechanisms into their own documents. I will be forwarding your other message along to the SASL list momentarily. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0FKP035504 for ; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93I0FPK035503 for ietf-sasl-bks; Fri, 3 Oct 2003 11:00:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93I0EKP035498 for ; Fri, 3 Oct 2003 11:00:14 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BA80C151D9B; Fri, 3 Oct 2003 13:59:57 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> From: Sam Hartman Date: Fri, 03 Oct 2003 13:59:57 -0400 In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 03 Oct 2003 06:41:43 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> I'm thinking a malformed message should be treated as a Kurt> protocol error in the application protocol. Kurt> Comments? This seems reasonable during the authentication phase, but I think we may need to say something more specific about security layers. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FsFKP027698 for ; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FsFn3027697 for ietf-sasl-bks; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Fs8KP027684 for ; Fri, 3 Oct 2003 08:54:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 3 Oct 2003 16:53:55 +0100 Message-ID: <3F7D9B91.7060906@isode.com> Date: Fri, 03 Oct 2003 16:53:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've started with the easy (editorial) stuff and I will reply to other comments after the weekend. Kurt D. Zeilenga wrote: >Attached are my raw review notes... mostly editorial, >clarifications, and such. I do raise (as Hallvard did) >some concerns with the realm text. I'll try to pull >that issue (and maybe a couple of other issues) out as >separate threads. > >Kurt > > >> >>1. Abstract >> >> SASL provides a method for adding authentication support with an >> optional security layer to connection-based protocols. >> >> > >SASL needs to be spelled out here (first use in Abstract). > Done. >> It also >> describes a structure for authentication mechanisms. The result is >> an abstraction layer between protocols and authentication mechanisms >> such that any SASL-compatible authentication mechanism can be used >> with any SASL-compatible protocol. >> >> This document describes how a SASL authentication mechanism is >> structured, how a protocol adds support for SASL, defines the >> protocol for carrying a security layer over a connection, and defines >> the EXTERNAL SASL authentication mechanism. >> >>... >> >>2.2. Conventions used in this document >> >> In examples, "C:" and "S:" indicate lines sent by the client and >> server respectively. >> >> The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" >> in this document are to be interpreted as defined in "Key words for >> use in RFCs to Indicate Requirement Levels" [KEYWORDS]. >> > >Add U+ convent description (see SASLprep). > > > Done. >>... >> >>4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. >> >> > >IANA should be spelled out here. > Ok. >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". >> >> The "sasl-mech" rule below defines the syntax of a SASL mechanism >> name. This uses the augmented Backus-Naur Form (BNF) notation as >> > >s/augmented Backus-Naur Form (BNF)/Augmented Backus-Naur Form (ABNF)/ > Done. >> specified in [ABNF] and the ABNF core rules as specified in Appendix >> A of the ABNF specification [ABNF]. >> >> >> sasl-mech = 1*20mech-char >> mech-char = %x41-5A / DIGIT / "-" / "_" >> ; mech names restricted to uppercase letters, >> ; digits, "-" and "_" >> >> >> >> >> >> >>A. Melnikov FORMFEED[Page 3] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >>4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an authentication >> protocol exchange. This consists of a series of server challenges >> and client responses, the contents of which are specific to and >> defined by the mechanism. >> >> > >Can't the client challenge the server as well? > Rob has already answered this question. > ... > >> After receiving a challenge, a client mechanism may issue a response >> or abort the exchange. The protocol's profile specifies how each of >> these is then represented over the connection. >> >> > >Indicate here that mechanisms may also involve challenges to >the server by the client. > > See Rob's reply. >>... >> >> An authorization identity is a string of zero or more ISO 10646 >> [ISO-10646] coded characters. The NUL (U+0000) character is not >> permitted in authorization identities. The meaning of an >> authorization identity of the empty string (zero length) is defined >> below in this section. The authorization identity is used by the >> server as the primary identity for making access policy decisions. >> >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). >> >> > >I'm thinking "blob" is not a good word choice here. > > Blob \Blob\ (bl[o^]b), n. [See {Bleb}.] > 1. Something blunt and round; a small drop or lump of > something viscid or thick; a drop; a bubble; a blister. > --Wright. > > 2. (Zo["o]l.) A small fresh-water fish ({Uranidea > Richardsoni}); the miller's thumb. > >>From WordNet (r) 2.0 [wn]: > > blob > n : an indistinct shapeless form > v : make a spot or mark onto; "The wine spotted the tablecloth" > [syn: {spot}, {fleck}, {blot}] > [also: {blobbing}, {blobbed}] > > >You could have meant BLOB (Binary Large OBject), but this seems not to >fit as well. > >I'm thinking "blob" should be replaced with "string". > I would rather use "data". >> While some legacy >> mechanisms are incapable of transmitting an authorization identity >> other than the empty string, >> >> > >I know of mechanisms which do not transmit an authorization identity... >but are there ones which only allow transfers of empty authorization >identity strings? > No, I am not aware of any such mechanism >> newly defined mechanisms are expected to >> be capable of carrying the entire Unicode repertoire (with the >> exception of the NUL character). An authorization identity of the >> empty string and and an absent authorization identity MUST be treated >> >> > >s/and and/and/ > Yes, already fixed in my diff ;-). >> as equivalent. However, mechanisms SHOULD NOT allow both (i.e. if an >> >> >> >>A. Melnikov FORMFEED[Page 4] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> authorization identity is allowed to be absent, but one is >> transferred, it SHOULD NOT be an empty string). >> >> > >Suggest this be reworded: > However, mechanisms SHOULD NOT allow both. That is, a mechanism > which provides an optional field for an authorization identity, > SHOULD NOT allow that field, when present, to be empty. > > Done (I didn't like the original either, but couldn't think of anything better). >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. >> >> The server makes an implementation defined policy decision as to >> whether the authentication identity is permitted to have the access >> privileges of the authorization identity and whether the >> authorization identity is permitted to receive service. If it is >> not, the server indicates failure of the authentication protocol >> exchange. >> >> As a client might not have the same information as the server, >> clients SHOULD NOT themselves try to derive authorization identities >> from authentication identities when clients could instead transmit an >> authorization identity of the empty string. >> >> > >I suggest rewording this: > As a client might not have the same information as the > server, clients SHOULD NOT derive authorization identities > from authentication identities. Instead, clients SHOULD > provide no (or empty) authorization identity when the user > has not provided an authorization identity. > Ok. >>... >> >> In this example, the client is proxy >> authenticating, sending the authorization id "fred". The server has >> determined the client's identity through IPsec and has a security >> policy that permits that identity to proxy authenticate as any other >> identity. >> >> To the protocol profile, the four octet sequence "fred" is an opaque >> binary blob. The SASL protocol profile for SMTP specifies that >> server challenges and client responses are encoded in BASE64; the >> BASE64 encoding of "fred" is "ZnJlZA==". >> >> > >s/binary blob/string/ > I've changed this to "data" instead, as above. >>... >> >> S: 220 smtp.example.com ESMTP server ready >> C: EHLO jgm.example.com >> S: 250-smtp.example.com >> S: 250 AUTH DIGEST-MD5 EXTERNAL >> C: AUTH EXTERNAL ZnJlZA== >> S: 235 Authentication successful. >> >>8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. >> >> >> >> >>A. Melnikov FORMFEED[Page 11] >> >> >> >> >> >>Internet DRAFT SASL 19 August 2003 >> >> >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. >> >> While the registration procedures do not require it, authors of SASL >> mechanisms are encouraged to seek community review and comment >> whenever that is feasible. Authors may seek community review by >> posting a specification of their proposed mechanism as an internet- >> draft. SASL mechanisms intended for widespread use should be >> standardized through the normal IETF process, when appropriate. >> >>8.1. Comments on SASL mechanism registrations >> >> Comments on registered SASL mechanisms should first be sent to the >> "owner" of the mechanism. Submitters of comments may, after a >> reasonable attempt to contact the owner, request IANA to attach their >> comment to the SASL mechanism registration itself. If IANA approves >> of this the comment will be made accessible in conjunction with the >> SASL mechanism registration itself. >> >>8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism >> >> > >Replace quotes with < and >, and insert a period at the end of the >sentence. > > Already done. >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). >> >> > >Drop "by sending (...)". > Done. >>... >> >>9. References >> >>9.1. Normative References >> >> [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: >> ABNF", RFC 2234, November 1997 >> >> [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and >> Languages", RFC 2277, January 1998 >> >> [GSSAPI] Linn, "Generic Security Service Application Program >> Interface, Version 2, Update 1", RFC 2743, January 2000 >> >> [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - >> Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. >> >> > >For consistency (all other references use tags not associated with >their document numbers), I suggest replacing the tag [ISO-10646] >with [UCS]. > > I frankly doubt that this make it any better. >> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate >> Requirement Levels", RFC 2119, March 1997 >> >> [Stringprep] P. Hoffman, M. Blanchet, "Preparation of >> Internationalized Strings ("stringprep")", RFC 3454, December 2002. >> >> [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names >> and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. >> >> [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work >> in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, >> Janyary 1998 >> >>... >> >>12. Acknowledgments >> >> This document is a revision of RFC 2222 written by John G. Myers >> . He also wrote the major part of this >> document. >> >> > >Drop John's e-mail address here. I suggest replacing the second >sentence with: > He also contributed significantly to this revision. > Ok. >> Thank you to Magnus Nystrom for the ASCII picture used in section >> 6.3. >> > > Magnus Nystrom provided the ASCII art used in Section 6.3. > > Ok. >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). >> >> Contributions of many members of the SASL mailing list are gratefully >> acknowledged. >> >> > >s/mailing list/working group/ > A lot of contribution was done before we had a working group. (Not that it worth arguing about anyway.) >>... >> >>Appendix B. IANA considerations >> >> The IANA is directed to modify the SASL mechanisms registry as >> follows: >> >> > >Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: > > Ok. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dpKP091053 for ; Fri, 3 Oct 2003 00:39:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h937dpbV091052 for ietf-sasl-bks; Fri, 3 Oct 2003 00:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937dmKP091031 for ; Fri, 3 Oct 2003 00:39:48 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h937dlJV076012; Fri, 3 Oct 2003 01:39:47 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Date: Fri, 03 Oct 2003 01:39:46 -0600 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt) Message-ID: <2147483647.1065145186@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> References: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Mailer: Mulberry/3.1.0b8 (Mac OS X) MIME-Version: 1.0 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: > At 02:19 PM 10/2/2003, Simon Josefsson wrote: >> * The document doesn't mandate any specific action when the client >> send an invalid string (e.g., one that is rejected by string >> processing) [...] > That is, what should the implementation do if the message it receives > is malformed? In the absence of a very compelling reason to do otherwise, the application should immediately fail the transaction. "Be liberal in what you accept" has no place here. However, I'm more concerned about protocol parser state machines getting out of sync (see the recent spate of -- again -- ASN.1 parser bugs) than applications misinterpreting bogus realm strings. > I note that this issue is likely not unique to ANONYMOUS. So, maybe > it should be dealt with in base SASL specification. [...] > I'm thinking a malformed message should be treated as a protocol > error in the application protocol. [Son-of-]2222 is a framework document, so I'm not sure if we can mandate that sort of behaviour in it. But that cannot stop us from suggesting some extremely rude behaviour towards authors of deviant software in the Security Considerations section. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fwKP025631 for ; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h931fwa0025630 for ietf-sasl-bks; Thu, 2 Oct 2003 18:41:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931fvKP025624 for ; Thu, 2 Oct 2003 18:41:57 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h931fxlg022341 for ; Fri, 3 Oct 2003 01:41:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031003061141.040ed080@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 03 Oct 2003 06:41:43 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: malformed messages (Re: draft-ietf-sasl-anon-01.txt) In-Reply-To: References: 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: Simon raised this issue to me privately... but I think it needs broader discussion (given that it is a technical issue). At 02:19 PM 10/2/2003, Simon Josefsson wrote: >* The document doesn't mandate any specific action when the client > send an invalid string (e.g., one that is rejected by string > processing). That is, what should the implementation do if the message it receives is malformed? I note that this issue is likely not unique to ANONYMOUS. So, maybe it should be dealt with in base SASL specification. I'm thinking a malformed message should be treated as a protocol error in the application protocol. Comments? Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkIKP096361 for ; Wed, 1 Oct 2003 11:46:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IkHGh096360 for ietf-sasl-bks; Wed, 1 Oct 2003 11:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IkGKP096354 for ; Wed, 1 Oct 2003 11:46:16 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h91IkF5t031925; Wed, 1 Oct 2003 14:46:15 -0400 Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: Message-ID: References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> 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: On Wed, 1 Oct 2003, Sam Hartman wrote: > Kurt> Can't the client challenge the server as well? > > I always thought that in SASL, the challenge was defined to be the > message from the server to the client even if it didn't serve that > purpose in a security sense. I agree. Indeed, in 6.1 we refer to an "initial client response" even though it could, in fact, be an initial challenge from client to server. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKNKP095438 for ; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91IKNSw095437 for ietf-sasl-bks; Wed, 1 Oct 2003 11:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THIRTY-NINE.MIT.EDU [18.187.5.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91IKMKP095432 for ; Wed, 1 Oct 2003 11:20:22 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 740CF151D9B; Wed, 1 Oct 2003 14:20:02 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> From: Sam Hartman Date: Wed, 01 Oct 2003 14:20:02 -0400 In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> (Kurt D. Zeilenga's message of "Wed, 01 Oct 2003 10:17:55 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) 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: >>>>> "Kurt" == Kurt D Zeilenga writes: >> 4.1. Authentication protocol exchange >> >> A SASL mechanism is responsible for conducting an >> authentication protocol exchange. This consists of a series of >> server challenges and client responses, the contents of which >> are specific to and defined by the mechanism. Kurt> Can't the client challenge the server as well? I always thought that in SASL, the challenge was defined to be the message from the server to the client even if it didn't serve that purpose in a security sense. --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Fi0KP089583 for ; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Fi01P089582 for ietf-sasl-bks; Wed, 1 Oct 2003 08:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h91FhxKP089577 for ; Wed, 1 Oct 2003 08:43:59 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa23323; 1 Oct 2003 11:43 EDT Date: Wed, 01 Oct 2003 11:43:34 -0400 From: Jeffrey Hutzelman To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Message-ID: <2070817856.1065023014@mariner.pc.cs.cmu.edu> In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 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 Wednesday, October 01, 2003 10:17:55 -0700 "Kurt D. Zeilenga" wrote: >> Network Working Group A. Melnikov >> Internet Draft Editor >> Document: draft-ietf-sasl-rfc2222bis-02.txt August 2003 >> Expires in six months Well, it doesn't matter now, but "expires in six months" is not acceptable; a specific date must be specified. See the "Formatting" section in 1id-guidelines.txt >> 1. Abstract Don't number the abstract. >> 4. Authentication mechanisms >> >> SASL mechanisms are named by strings, from 1 to 20 characters in >> length, consisting of upper-case letters, digits, hyphens, and/or >> underscores. SASL mechanism names must be registered with the IANA. > > IANA should be spelled out here. > >> IETF Standards Track documents may override this registration >> requirement by reserving a portion of the SASL mechanism namespace >> for their own use; the GSSAPI mechanism specification [SASL-GSSAPI] >> does this. Procedures for registering new SASL mechanisms are given >> in the section "Registration procedures". Ick. IMHO this phrasing is ugly and not necessary. It appears to encourage authors of documents like SASL-GSSAPI to allocate themselves parts of the namespace without bothering to direct the IANA to reserve them. This would be a bad thing, and would indeed require that a potential future protocol designer (and/or the IANA itself) search the complete space of standards-track documents to see if the name they want to use has been reserved. IETF standards-track documents do not need the SASL spec's permission to direct the IANA to reserve parts of the namespace; thus, I don't think it's necessary to mention it at all. However, if it is mentioned, it should be in the IANA considerations section, not here, and with text like "IETF standards track documents may direct the IANA to reserve a portion of the SASL mechansim namespace and may specify different registration criteria for the reserved portion." Given the large size of the mechanism namespace, it is unfortunate that we have failed to provide for mechanism names of the form foo@domain. Delegated registration is much less work for IANA. >> Per IETF character set >> policy [CHARSET-POLICY], authentication mechanisms SHOULD encode >> these and other strings in UTF-8 [UTF-8]. > > This seems counter to [CHARSET-POLICY] as it allows a mechanism to > not support UTF-8 transfer of character data. > > [CHARSET-POLICY] says: > Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help. While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built. Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set. So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so. But it may not be appropriate for "other strings". >> If the authorization identity transmitted during the authentication >> protocol exchange is not the empty string, this is typically referred >> to as "proxy authentication". > > Personally, I refer to this as "proxy authorization". Proxy > authentication makes it sound like the feature can be used by a > proxy to authenticate its users. The same argument can be made for "proxy authorization". We are talking about "authentication by proxy", not "authentication to a proxy". And yes, we're really talking about authorization, not authentication, but it's not really "authorization by proxy"; it's just authorization. The terminology is pretty bad. It's not clear to me that we need a name for this at all. But I'm pretty sure the phrase "proxy authentication" has been in use for a while, and to change it might cause more confusion than leaving it alone. >> This feature permits agents such as >> proxy servers to authenticate using their own credentials, yet >> request the access privileges of the identity for which they are >> proxying. Sure, but that's not really all it's good for. It also allows jhutz@CS.CMU.EDU to log in to the IMAP server on CYRUS.ANDREW.CMU.EDU as 'jhutz', even though the server is in the ANDREW.CMU.EDU realm. And similar functionality, though not using SASL, allows me to type "jhutz@CS.CMU.EDU,maint:" at a login prompt, followed by jhutz@CS.CMU.EDU's password, and log in as the user 'maint'. >> The server SHOULD verify the correctness of a received authorization >> identity. > > "Correctness" here doesn't appear to be correct. And it should > be a MUST. I suggest: > The server SHALL fail the authentication exchange if the > authenticated client is not allowed to assume the asserted > authorization identity. s/SHALL/MUST/ >> 4.4. Character string issues >> >> Per IETF character set policy [CHARSET-POLICY], authentication >> mechanisms SHOULD encode character strings in UTF-8 [UTF-8]. > > See above note about charset-policy. And my response. It's really quite important that we get this right for authentication identities, or we risk invalidating a number of popular mechanisms because they are based on underlying authentication technology which does not use UTF-8. >> 5. Protocol profile requirements >> >> In order to use this specification, a protocol definition MUST supply >> the following information: >> >> A service name, to be selected from the IANA registry of "service" >> elements for the GSSAPI host-based service name form. [GSSAPI] This >> service name is made available to the authentication mechanism. >> >> The registry is available at the URL >> "http://www.iana.org/assignments/gssapi-service-names" A definition Paragraph break. >> A definition of the method by which the authentication protocol >> exchange is carried out, including how the challenges and responses >> are encoded, how the server indicates completion or failure of the >> exchange, how the client aborts an exchange, and how the exchange >> method interacts with any line length limits in the protocol. >> >> The command SHOULD have a method for the server to include an >> optional challenge with a success notification. This allows the >> server to avoid a round trip when using a mechanism which is defined >> to have the server send additional data along with the indication of >> successful completion. See section 6.2 of this document for further >> information. What command? Who says "the method by which the authentication protocol exchange is carried out" is a command? s/The command/The exchange method/ >> Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept >> of realm. > > I think it unwise to enter into a discussion of realms here. > Realm syntax and semantics are, for mechanisms which have realms, > mechanism specific. The mechanism specification should state how > they are to be compared. The mechanism specification should state > how they are to constructed and used in the mechanism and, where > appropriate, state any protocol profiling requirements. (Note: > I'd likely doubt any mechanism attempt to state protocol profiling > requirements as this breaks SASL's separation of profile and > mechanism). I agree. A realm is just part of the authentication identities used by certain mechanisms. It is mechanism-specific, and a discussion of realms is irrelevant to protocol profiling. >> A protocol profile SHOULD provide a guidance how realms are to be >> constructed and used in the protocol and MAY further restrict its >> syntax and protocol-specific semantics. Absolutely not. Protocols may decide to include some concept of realm in their authorization identities, but they have no business whatsoever defining the semantics of authentication identities. That is the responsiblity of the mechanism. >> Below the term "realm" has the meaning as defined in the section 5. >> A security layer that remains in effect when a client, which already >> has authenticated and established the security layer with "Realm A", >> authenticates to "Realm B", without negotiating a new security layer, >> enables "Realm B" to make guesses about previously observed >> ciphertext using the server's SASL engine as an oracle. "Realm B" may >> observe how known cleartext is encrypted. >> >> +---------+ +---------+ >> | | | | >> | Realm B | | Realm A | >> | | | | >> +---------+ +---------+ >> | ^ | >> | : +-----------+ | >> Traffic from | : | Encryption| | Traffic from A >> B to client +-------->| end point |<-------+ to client >> : | (SSL/SASL)| >> : +-----------+ >> : | >> : | >> : +---+ >> : | | >> : | | >> : | | Encryption tunnel, e.g. SASL or SSL, >> : | | between the server > >> encrypted | | Separate tunnels to different >> traffic between | | clients. >> Realm A and client +---+ >> | >> | >> +-----------> Traffic to clients This discussion is confusing and makes no sense to me. SASL doesn't protect traffic between "realms" and clients; it protects traffic between _servers_ and clients. This needs to be reworded so it makes sense, in terms of entities known to the SASL framework. A "realm" is not such an entity; it is no more than part of the autentication identities used by some mechanisms, and has no place outside the mechainsm specification. Put another way, and ignoring the issue of "realms"; the above description makes so little sense to me that I cannot evaluate its validity or understand what attack we are trying to avoid. >> 8. IANA Considerations >> >> Registration of a SASL mechanism is done by filling in the template >> in section 8.4 and sending it in to iana@iana.org. IANA has the >> right to reject obviously bogus registrations, but will perform no >> review of claims made in the registration form. Provide the template. Do not specify how to communicate the registration to the IANA, because that may change over time and is out of scope for this document. >> There is no naming convention for SASL mechanisms; any name that >> conforms to the syntax of a SASL mechanism name can be registered. >> An IETF Standards Track document may reserve a portion of the SASL >> mechanism namespace for its own use, amending the registration rules >> for that portion of the namespace. Again, too bad we didn't allow for foo@domain.com. >> 8.2. Location of registered SASL mechanism list >> >> SASL mechanism registrations are available at the URL >> "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism > > Replace quotes with < and >, and insert a period at the end of the > sentence. > >> description and other supporting material may also be published as an >> Informational RFC by sending it to "rfc-editor@rfc-editor.org" >> (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]). > > Drop "by sending (...)". IMHO, drop the whole subsection. IANA considerations are about telling the IANA what it needs to do and be aware of with respect to this document. It's appropriate to specify the form of registration and the rules which govern whether IANA should accept a registration. It is not appropriate to specify the means used to communicate with the IANA or the RFC Editor, or to direct the IANA as to the URL at which it must provide the registration data. These things may change over time, and it is out of scope for the SASL working group (or, indeed, the IETF) to specify them. >> 8.3. Change control >> >> Once a SASL mechanism registration has been published by IANA, the >> author may request a change to its definition. The change request >> follows the same procedure as the registration request. This sounds a lot like the stringprep loophole, and it makes me nervous. >> 9.2. Informative References >> >> <> [SASL-GSSAPI] Myers, "SASL GSSAPI >> mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt, >> September 2000 >> [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest >> Authentication as a SASL Mechanism", work in progress, draft-ietf- >> sasl-rfc2831bis-XX.txt, replaces RFC 2831 I think it would be good to eliminate references to new or updated mechanisms if at all possible, since otherwise we are forced to either publish a document with incorrect or incomplete references, or wait until those documents are ready. If we keep them, use the correct reference form: [SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms" (draft-ietf-cat-sasl-gssapi-01.txt) See "References" in section 2 of ID-nits. >> [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) >> MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. Ew. I don't think this is necessary. Also, references to URL's are to be avoided, as they may change, rendering the document obsolete and confusing. See "References" in section 2 of id-nits. >> "stringprep" and Unicode security considerations apply to >> authentication identities, authorization identities and passwords. Include references to these. Put Security Considerations _before_ references, not after. >> 12. Acknowledgments >> Definition of realm was extracted from RFC 2617 ("HTTP >> Authentication: Basic and Digest Access Authentication"). Except we should be dropping the definition of "realm". >> In certain situations, it is reasonable to use SASL underneath one of >> these Transport Security services. The transport service would >> secure the connection, either service would authenticate the client, >> and SASL would negotiate the authorization identity. The SASL >> negotiation would be what moves the protocol from "unauthenticated" >> to "authenticated" state. The "EXTERNAL" SASL mechanism is >> explicitly intended to handle the case where the transport service >> secures the connection and authenticates the client and SASL >> negotiates the authorization identity. >> >> When using SASL underneath a sufficiently strong Transport Security >> service, a SASL security layer would most likely be redundant. The >> client and server would thus probably want to negotiate off the use >> of a SASL security layer. Please don't say this without a _lot_ more text explaining when it is safe. A common configuration is to run SASL under TLS, using SASL for client authentication and negotation of the authorization identity. In this configuration, it is _not_ safe to skip using a SASL security layer if the client did not check the server's certificate (there is a tunnelling MitM attack), and it's not a particularly good idea even if the server cert was checked, because the client's authentication is still not bound to the encryption keys used at the TLS layer. We already have problems with people who think it is actively bad to use a SASL security layer under TLS. The result is that some insecure configurations are now widely deployed. Let's not encourage this any further. >> Appendix B. IANA considerations Uh, no. IANA considerations were section 8. Please merge them. >> The IANA is directed to modify the SASL mechanisms registry as >> follows: > > Please reword this to be not so demanding. For example, > It is requested that IANA update the SASL mechanisms registry > as follows: It's not demanting; it's perfectly reasonable usage. The IANA works for the IETF; it is appropriate for the IETF, in the form of a standards-track document, to direct it to make changes to a registry. It is also common usage. Put the TOC at the _top_ of the document, just after the abstract. See the "Tabel of Contents" section at http://www.rfc-editor.org/policy.html -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnjKP085367 for ; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Dnj3Q085366 for ietf-sasl-bks; Wed, 1 Oct 2003 06:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DnhKP085361 for ; Wed, 1 Oct 2003 06:49:44 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1A4hML-0001VS-TL for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1A4hMK-00010R-B0 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:49:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4hMK-0004Gr-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:49:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: empty authzid in draft-ietf-sasl-plain-02.txt Date: Wed, 1 Oct 2003 15:49:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: draft-ietf-sasl-plain-02.txt says that The client leaves the authorization identity empty if it wishes the server to derive the authorization identity from the provided authentication identity. and Note that the parameters provided to the Authorize function are not prepared. so I think the pseudo-code for empty authzid should say authzid = DeriveAuthzid(authcid); and not authzid = DeriveAuthzid(pAuthcid); -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPUKP084014 for ; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91DPUnA084011 for ietf-sasl-bks; Wed, 1 Oct 2003 06:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DPTKP084005 for ; Wed, 1 Oct 2003 06:25:29 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1A4gyt-0006QG-76 for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:27 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1A4gys-00013a-0j for ietf-sasl@imc.org; Wed, 01 Oct 2003 15:25:26 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1A4gyr-0004C6-00 for ietf-sasl@imc.org; Wed, 1 Oct 2003 15:25:25 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 1 Oct 2003 15:25:25 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >> The character encoding scheme used for transmitting an authorization >> identity over protocol is specified in each authentication mechanism >> (with the authentication mechanism's blob being further >> restricted/encoded by the protocol profile). > > I'm thinking "blob" is not a good word choice here. (...) > I'm thinking "blob" should be replaced with "string". But which string is the draft talking about? -- Hallvard