From owner-ietf-sasl Tue Aug 3 09:58:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw68L078968; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Gw6Sa078967; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-129-194.ietf60.ietf.org [130.129.129.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw5Vm078961 for ; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id DD0EC160487; Tue, 3 Aug 2004 12:56:34 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> <4104263B.2000707@isode.com> From: Sam Hartman Date: Tue, 03 Aug 2004 12:56:34 -0400 In-Reply-To: <4104263B.2000707@isode.com> (Alexey Melnikov's message of "Sun, 25 Jul 2004 22:29:31 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I don't mind the changes you are proposing (at least I Alexey> agree with their motivation), however this suggestion is a Alexey> bit late and I would like to point out that there several Alexey> independent implementations of GSSAPI (Kerberos) mechanism Alexey> that interoperate well (at least better than DIGEST-MD5). We cannot make these changes for the SASL mechanism called GSSAPI; that seems clear. From owner-ietf-sasl Wed Aug 4 14:36:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaVRs019191; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74LaVHD019190; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-130-188.ietf60.ietf.org [130.129.130.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaUWO019184 for ; Wed, 4 Aug 2004 14:36:30 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 762741608F7; Wed, 4 Aug 2004 17:35:06 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: SASL working group summary for IETF 60 From: Sam Hartman Date: Wed, 04 Aug 2004 17:35:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: The SASL working group met for one hour. The SASL base spec (draft-ietf-sasl-rfc2222bis) is in last call. We need more review of this document; without this review the chairs will be unable to recommend the document for publication. Nicolas Williams will provide security considerations text for rekeying to be considered by the group. Not much progress has been made on digest-md5 since the last IETF. The explicit IV issues for CBC have been discussed but are still open. The character set conversion issues are still open although there is still a possibility we will be able to move exclusively to UTF8. At least two more revisions of the draft are expected. There was discussion of the GSSAPI mechanism. everyone agrees we need to maintain compatibility with the widely deployed Kerberos 5 mechanism. Sam Hartman proposed significant changes to other GSSAPI SASL mechanisms for improved efficiency. One reason we may want this change is HTTP SASL. Discussion will continue on the list. From owner-ietf-sasl Wed Aug 4 15:07:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7eqR021631; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74M7eVU021630; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7cdp021624 for ; Wed, 4 Aug 2004 15:07:39 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BsTvD-0005VW-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASL working group summary for IETF 60 Date: Thu, 05 Aug 2004 00:07:38 +0200 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:1UGFIBfleUZDGUKIZYN4HerfHRM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > There was discussion of the GSSAPI mechanism. everyone agrees we need > to maintain compatibility with the widely deployed Kerberos 5 > mechanism. Sam Hartman proposed significant changes to other GSSAPI > SASL mechanisms for improved efficiency. One reason we may want this > change is HTTP SASL. Discussion will continue on the list. How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" document, and one document for the generic "GSS-*" mechanism set? If the protocol for "GSS-*" will be different from the "GSSAPI" protocol, perhaps it doesn't make sense to describe both in the same document. It might also help focus on making the "GSS-*" protocol better, without having to pay attention to Kerberos 5 specific issues. Regards, Simon From owner-ietf-sasl Fri Aug 6 17:11:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i770BjYF077525; Fri, 6 Aug 2004 17:11:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i770BjAV077524; Fri, 6 Aug 2004 17:11:45 -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.11/8.12.9) with ESMTP id i770BjZj077514 for ; Fri, 6 Aug 2004 17:11:45 -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 i770BkJ6007146 for ; Fri, 6 Aug 2004 17:11:46 -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 i770BjDi008488 for ; Fri, 6 Aug 2004 18:11:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7709DTP005761 for ; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7709DCZ005760 for ietf-sasl@imc.org; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Date: Fri, 6 Aug 2004 19:09:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Text on re-keying for rfc2222bis Message-ID: <20040807000913.GZ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Diffs for section 6.3: --- /tmp/sasl-6.3-orig Fri Aug 6 19:08:10 2004 +++ /tmp/sasl-6.3 Fri Aug 6 19:08:00 2004 @@ -1,5 +1,6 @@ + 6.3. Multiple authentications Unless otherwise stated by the protocol's profile, only one successful SASL negotiation may occur in a protocol session. In this case, once an authentication protocol exchange has successfully @@ -8,18 +9,22 @@ If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. 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 remains in effect. + second security layer replaces the first; this can be used as a form + of re-keying, where SASL mechanisms that provide security layers fail + to provide for re-keying, provided that the authenticated identities + remain the same. If a security layer is in effect and a subsequent + SASL negotiation selects no security layer, the original security + layer remains in effect. Where a protocol profile permits multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. + New text for the security considerations section: The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. The use of cryptographic keys and the passage of time after the initial use of a cryptographic key weakens said keys by increasing the amount of ciphertext, other cryptographic material, and/or time that is available to cryptanalysts in any effort to attack the security layers. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. SASL does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers SHOULD provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should re-authenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Sorry for the delay. Nico -- From owner-ietf-sasl Wed Aug 11 07:07:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BE7Y7a046659; Wed, 11 Aug 2004 07:07:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BE7YEN046658; Wed, 11 Aug 2004 07:07:34 -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.11/8.12.9) with ESMTP id i7BE7SP8046560 for ; Wed, 11 Aug 2004 07:07:29 -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 (internal) with ESMTPA; Wed, 11 Aug 2004 15:11:11 +0100 Message-ID: <411A280D.5080404@isode.com> Date: Wed, 11 Aug 2004 15:07:09 +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: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: SASL working group summary for IETF 60 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: Simon Josefsson wrote: >Sam Hartman writes: > > >>There was discussion of the GSSAPI mechanism. everyone agrees we need >>to maintain compatibility with the widely deployed Kerberos 5 >>mechanism. Sam Hartman proposed significant changes to other GSSAPI >>SASL mechanisms for improved efficiency. One reason we may want this >>change is HTTP SASL. Discussion will continue on the list. >> >> > >How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" >document, and one document for the generic "GSS-*" mechanism set? If >the protocol for "GSS-*" will be different from the "GSSAPI" protocol, >perhaps it doesn't make sense to describe both in the same document. >It might also help focus on making the "GSS-*" protocol better, >without having to pay attention to Kerberos 5 specific issues. > This is pretty much what I've suggested. From owner-ietf-sasl Wed Aug 11 12:17:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH8d0079107; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BJH8GM079106; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH7Cu079100 for ; Wed, 11 Aug 2004 12:17:07 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D2CEB1602F7; Wed, 11 Aug 2004 15:17:07 -0400 (EDT) To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2222bis.txt Message-Id: <20040811191707.D2CEB1602F7@cz.mit.edu> Date: Wed, 11 Aug 2004 15:17:07 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2, the draft claims that the layer does not generally hide the details of mechanisms from protocols. I actually believe the statement we want to be making is that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. In particular, I consider it a requirement to be able to specify a SASL binding to a protocol without thinking about mechanism details. I believe this requirement is met by the base spec. However actually implementing this protocol spec for a particular mechanism requires the server and client to be aware of the mechanism details. I would not in general consider it acceptable for mechanism specifications to place requirements on protocol specifications. Besides this concern and some editorial issues I've sent to the editor, I have read this document and believe it is of high quality. As a chair however, I believe we still have not received sufficient review to publish the document. --Sam From owner-ietf-sasl Wed Aug 11 14:27:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRT6N092382; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLRTXh092381; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRSTI092373 for ; Wed, 11 Aug 2004 14:27:28 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 93ED5E003D; Wed, 11 Aug 2004 17:27:32 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis References: <20040807000913.GZ892@binky.central.sun.com> From: Sam Hartman Date: Wed, 11 Aug 2004 17:27:32 -0400 In-Reply-To: <20040807000913.GZ892@binky.central.sun.com> (Nicolas Williams's message of "Fri, 6 Aug 2004 19:09:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: I'm a bit uncomfortable saying that SASL mechanisms should support rekeying. I'm not sure that the community understands what this would mean well enough that mechanisms would converge on solutions with similar properties. Also, do we want to point out that for interop reasons SASL mechanisms may want to provide advisory notice that rekeying is necessary rather than invalidating security contexts. I'm particularly concerned about the transferring large file case. From owner-ietf-sasl Thu Aug 12 01:30:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C8U078098182; Thu, 12 Aug 2004 01:30:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C8U0Fj098181; Thu, 12 Aug 2004 01:30:00 -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.11/8.12.9) with ESMTP id i7C8U0kg098169 for ; Thu, 12 Aug 2004 01:30:00 -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 i7C8Tt0R016834 for ; Thu, 12 Aug 2004 01:29:55 -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 i7C8TtUT027964 for ; Thu, 12 Aug 2004 02:29:55 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C8RHfS007662; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C8RHdh007661; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Date: Thu, 12 Aug 2004 03:27:17 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis Message-ID: <20040812082717.GO892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040807000913.GZ892@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.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Aug 11, 2004 at 05:27:32PM -0400, Sam Hartman wrote: > > I'm a bit uncomfortable saying that SASL mechanisms should support > rekeying. I'm not sure that the community understands what this would > mean well enough that mechanisms would converge on solutions with > similar properties. Ok, how about this: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. > > Also, do we want to point out that for interop reasons SASL mechanisms > may want to provide advisory notice that rekeying is necessary rather > than invalidating security contexts. I'm particularly concerned about > the transferring large file case. I sympathize. I don't mind seeing text in rfc2222bis about advisory vs. mandatory security layer expiration. But I think that text about this that is specific to the GSS mechanisms seems well beyond the scope of rfc2222bis. Suggestions? Nico -- From owner-ietf-sasl Thu Aug 12 10:42:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHgXrr005758; Thu, 12 Aug 2004 10:42:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHgXhe005757; Thu, 12 Aug 2004 10:42:33 -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.11/8.12.9) with ESMTP id i7CHgWgo005748 for ; Thu, 12 Aug 2004 10:42:32 -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 (internal) with ESMTPA; Thu, 12 Aug 2004 18:46:33 +0100 Message-ID: <411BAC01.7040407@isode.com> Date: Thu, 12 Aug 2004 18:42:25 +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: DIGEST-MD5 interop issue 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: Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as "username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): >realm > >The realm containing the user's account, encoded according to the >value of the "charset" directive. This directive is required >if the server provided any realms in the "digest-challenge", in which case it >may appear exactly once and its value SHOULD be one of those realms. If the >directive is missing, "realm-value" will set to the empty string when >computing A1 (see below for details). So, the client has violated SHOULD and the server is treating SHOULD as MUST. So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. I have a reason to believe that the client is using a library implementing DIGEST-MD5, which is widely deployed. Alexey From owner-ietf-sasl Thu Aug 12 12:15:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFUeT017060; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJFULP017059; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SEVENTY-SIX.MIT.EDU [18.187.6.221]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFTWw017053 for ; Thu, 12 Aug 2004 12:15:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 627641602F9; Thu, 12 Aug 2004 15:15:37 -0400 (EDT) To: ietf-sasl@imc.org Subject: rfc2222bis: confidentiality and integrity Message-Id: <20040812191537.627641602F9@cz.mit.edu> Date: Thu, 12 Aug 2004 15:15:37 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. There's another change I thought would be editorial but apparently is not. The document currently says in section 1 that confidentiality protection usually implies integrity protection. This seems less than ideal from a security standpoint. I believe that applications need to be able to depend on the fact that confidentiality protection comes along with integrity protection. I propose to drop the word usually. From owner-ietf-sasl Thu Aug 12 17:44:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0imt5053291; Thu, 12 Aug 2004 17:44:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0im52053290; Thu, 12 Aug 2004 17:44:48 -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.11/8.12.9) with ESMTP id i7D0imac053281 for ; Thu, 12 Aug 2004 17:44:48 -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 i7D0inJ6008666 for ; Thu, 12 Aug 2004 17:44:49 -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 i7D0imUT019792 for ; Thu, 12 Aug 2004 18:44:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0gALO018314; Thu, 12 Aug 2004 19:42:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0g93e018313; Thu, 12 Aug 2004 19:42:09 -0500 (CDT) Date: Thu, 12 Aug 2004 19:42:09 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity Message-ID: <20040813004209.GI892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040812191537.627641602F9@cz.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 12, 2004 at 03:15:37PM -0400, Sam Hartman wrote: > > > Hi. There's another change I thought would be editorial but > apparently is not. The document currently says in section 1 that > confidentiality protection usually implies integrity protection. > > This seems less than ideal from a security standpoint. I believe that > applications need to be able to depend on the fact that > confidentiality protection comes along with integrity protection. If there are any mechanisms that provide confidentiality protection without providing integrity protection then I propose: a) that rfc2222bis identify such mechanisms, b) say new mechs MUST NOT do such Bad Things. > I propose to drop the word usually. Yes. Nico -- From owner-ietf-sasl Thu Aug 12 17:49:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0npBt053683; Thu, 12 Aug 2004 17:49:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0npT5053682; Thu, 12 Aug 2004 17:49: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-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0nplN053675 for ; Thu, 12 Aug 2004 17:49:51 -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 i7D0nqJ6010211 for ; Thu, 12 Aug 2004 17:49:52 -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 i7D0npUT021379 for ; Thu, 12 Aug 2004 18:49:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0lDXP018321 for ; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0lDFv018320 for ietf-sasl@imc.org; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Date: Thu, 12 Aug 2004 19:47:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Does rfc2222bis need text on channel bindings? Message-ID: <20040813004713.GJ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I figure the new SASL GSS mech document will say something about channel bindings, but perhaps rfc2222bis should also. Specifically I think that rfc2222bis could use: a) Security Considerations text about use of mechanisms that don't support channel bindings in conjunction with TLS. Clients should be admonished to validate TLS server IDs to prevent MITM attacks when using SASL-over-TLS. Similarly with other variants of SASL-over-TLS. SACRED is an example of an application where such text could be useful. b) Text recommending support for channel bindings in future mechanisms, where possible. Digest-MD5, for example, could easily support channel bindings. Comments? Shall I just send proposed text to the list? Nico -- From owner-ietf-sasl Thu Aug 12 19:14:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2Ehe9061126; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D2Ehdf061125; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-5.MIT.EDU [18.101.1.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2EgfO061117 for ; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id BAF13E0036; Thu, 12 Aug 2004 22:14:51 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity References: <20040812191537.627641602F9@cz.mit.edu> <20040813004209.GI892@binky.central.sun.com> From: Sam Hartman Date: Thu, 12 Aug 2004 22:14:51 -0400 In-Reply-To: <20040813004209.GI892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:42:09 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> If there are any mechanisms that provide confidentiality Nicolas> protection without providing integrity protection then I Nicolas> propose: a) that rfc2222bis identify such mechanisms, b) Nicolas> say new mechs MUST NOT do such Bad Things. I know of no such mechanisms. From owner-ietf-sasl Fri Aug 13 03:21:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALBSH028402; Fri, 13 Aug 2004 03:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALBcn028401; Fri, 13 Aug 2004 03:21:11 -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.11/8.12.9) with ESMTP id i7DAL9rM028377 for ; Fri, 13 Aug 2004 03:21:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN0014781; Fri, 13 Aug 2004 10:21:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:32:05 +0200 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: DIGEST-MD5 interop issue Cc: SASL WG In-Reply-To: <411BAC01.7040407@isode.com> References: <411BAC01.7040407@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 07:42 PM 8/12/2004, Alexey Melnikov wrote: >Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: > >While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. >I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as >"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). > >At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): > >>realm >>The realm containing the user's account, encoded according to the value of the "charset" directive. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and its value SHOULD be one of those realms. If the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details). > > >So, the client has violated SHOULD and the server is treating SHOULD as MUST. No, the server is treating the client provided realm as invalid and hence the exchange fails. The server behavior is proper. >So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. > >There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, This is real issue. >instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. Exactly, the client is making assumptions which prevent users from being able to use it with independently developed servers. A client which cannot handle the full range of identity and realm values is simply broken. For instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in the realm project@OPENLDAP.ORG. I would not be able to use this or like clients. Kurt From owner-ietf-sasl Fri Aug 13 03:21:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALHvb028425; Fri, 13 Aug 2004 03:21:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALHWb028424; Fri, 13 Aug 2004 03:21:17 -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.11/8.12.9) with ESMTP id i7DALGMF028418 for ; Fri, 13 Aug 2004 03:21:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN2014781 for ; Fri, 13 Aug 2004 10:21:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:34:04 +0200 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: 2222bis: identities and authorization 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 have completed my review of draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor editorial comments (which I have separately sent to the Editor). This note discussions problems I found related to identities and authorization. The 'Authorization and authentication identities' section (3.2) starts off by stating that 'SASL authentication deals with two identities' but then describes the processing model to involve three identities, two of which it simply refers to as 'authorization' identities. I believe we either need better distinguish these identities within the document, by through qualification (proxy authorization identity v. application authorization identity) or by use of replacement terminology (proxied identity v. authorization identity). I prefer the latter approach as the former qualifications are themselves a bit confused and the latter seems more in step with RFC 2828. I am willing to prepare replacement text for consideration. Kurt From owner-ietf-sasl Fri Aug 13 03:27:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DARuZp030020; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DARuBh030019; Fri, 13 Aug 2004 03:27:56 -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.11/8.12.9) with ESMTP id i7DARu9n030009 for ; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DARpMw014819; Fri, 13 Aug 2004 10:27:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813122737.085d65d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 12:28:27 +0200 To: hartmans@mit.edu (Sam Hartman) From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: confidentiality and integrity Cc: ietf-sasl@imc.org In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> References: <20040812191537.627641602F9@cz.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: I support this suggestion. The subsequent sentence is sufficent to suggest other kinds (including poorly designed :-) layers may be supported. At 09:15 PM 8/12/2004, Sam Hartman wrote: >Hi. There's another change I thought would be editorial but >apparently is not. The document currently says in section 1 that >confidentiality protection usually implies integrity protection. > >This seems less than ideal from a security standpoint. I believe that >applications need to be able to depend on the fact that >confidentiality protection comes along with integrity protection. > >I propose to drop the word usually. From owner-ietf-sasl Fri Aug 13 07:52:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DEqArs017759; Fri, 13 Aug 2004 07:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DEqA5r017758; Fri, 13 Aug 2004 07:52:10 -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.11/8.12.9) with SMTP id i7DEq9pO017732 for ; Fri, 13 Aug 2004 07:52:09 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30845; 13 Aug 2004 10:51 EDT Date: Fri, 13 Aug 2004 10:51:31 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: SASL WG Subject: Re: DIGEST-MD5 interop issue Message-ID: <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@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 Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" wrote: >> So, the client has violated SHOULD and the server is treating SHOULD as >> MUST. > > No, the server is treating the client provided realm as invalid and hence > the exchange fails. The server behavior is proper. Put another way... The server is not rejecting the exchange because it thinks the client has violated the protocol. It's doing so based on policy -- the client provided a name in bar.example.com, and the server is only willing to deal with clients in test.example.com. The reason for the SHOULD is that the server has indicated which realms it is willing/able to accept, and it's expected that the server will usually reject any other realms. From owner-ietf-sasl Fri Aug 13 08:15:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFFKjk025988; Fri, 13 Aug 2004 08:15:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFFKt2025987; Fri, 13 Aug 2004 08:15:20 -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.11/8.12.9) with ESMTP id i7DFFJiI025981 for ; Fri, 13 Aug 2004 08:15: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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:19:10 +0100 Message-ID: <411CDAF2.4070804@isode.com> Date: Fri, 13 Aug 2004 16:14:58 +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 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.edu> MIME-version: 1.0 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: > On Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" > wrote: > >>> So, the client has violated SHOULD and the server is treating SHOULD as >>> MUST. >> >> No, the server is treating the client provided realm as invalid and >> hence >> the exchange fails. The server behavior is proper. > > Put another way... > > The server is not rejecting the exchange because it thinks the client > has violated the protocol. It's doing so based on policy -- the > client provided a name in bar.example.com, and the server is only > willing to deal with clients in test.example.com. This make sense. But in case of CMU SASL the realm value doesn't matter, it is only used for constructing the authentication verifier. Alexey From owner-ietf-sasl Fri Aug 13 08:12:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFCwc8025731; Fri, 13 Aug 2004 08:12:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFCwc2025730; Fri, 13 Aug 2004 08:12:58 -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.11/8.12.9) with ESMTP id i7DFCubb025717 for ; Fri, 13 Aug 2004 08:12:57 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:16:45 +0100 Message-ID: <411CDA64.6080408@isode.com> Date: Fri, 13 Aug 2004 16:12: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: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.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: Jeffrey Hutzelman wrote: > The reason for the SHOULD is that the server has indicated which > realms it is willing/able to accept, and it's expected that the server > will usually reject any other realms. One problem with the DIGEST-MD5 spec I can see is that there is no way for the server to tell whether it only accepts certain realms or whether it will accept any realms. There are servers that implement either policy. Servers that implement the latter policy can accept authentication for any realm and will try to proxy authenticate if possible. Alexey From owner-ietf-sasl Fri Aug 13 08:52:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFqkhk030227; Fri, 13 Aug 2004 08:52:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFqkdi030226; Fri, 13 Aug 2004 08:52:46 -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.11/8.12.9) with ESMTP id i7DFqjpO030219 for ; Fri, 13 Aug 2004 08:52:46 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:56:55 +0100 Message-ID: <411CE3CE.1000905@isode.com> Date: Fri, 13 Aug 2004 16:52:46 +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: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> In-Reply-To: <20040813004713.GJ892@binky.central.sun.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: Nicolas Williams wrote: >I figure the new SASL GSS mech document will say something about channel >bindings, but perhaps rfc2222bis should also. > >Specifically I think that rfc2222bis could use: > >a) Security Considerations text about use of mechanisms that don't > support channel bindings in conjunction with TLS. > > Clients should be admonished to validate TLS server IDs to prevent > MITM attacks when using SASL-over-TLS. Similarly with other variants > of SASL-over-TLS. > I suspect you mean "SASL-over-". > SACRED is an example of an application where such text could be > useful. > >b) Text recommending support for channel bindings in future mechanisms, > where possible. Digest-MD5, for example, could easily support > channel bindings. > If you mean that it can be easily extended, then I agree. >Comments? Shall I just send proposed text to the list? > Please do. Alexey From owner-ietf-sasl Fri Aug 13 09:57:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvE3Q036998; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGvEu2036997; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvDc5036899 for ; Fri, 13 Aug 2004 09:57:13 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 09:57:13 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:56:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:57:08 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 09:56:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 09:57:32 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBIQCJAp+5L9SWQf2IEz1lwX0AyQANRB4w From: "Paul Leach" To: "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 16:56:21.0608 (UTC) FILETIME=[75C2AE80:01C48156] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DGvDc5036965 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 Kurt D. Zeilenga > Sent: Friday, August 13, 2004 12:32 AM > To: Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Exactly, the client is making assumptions which prevent users from being > able to use it with independently developed servers. A client which > cannot > handle the full range of identity and realm values is simply broken. For > instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in > the realm project@OPENLDAP.ORG. I would not be able to use this or like > clients. [Paul Leach] Use of names and realms of this form was not the intention when the protocol was spec'd. The idea was that realms would be DNS names. You can legitimately gripe that the spec does not make this intention clear. Or that the client in question doesn't make clear its rules for transforming what the user types into what gets sent on the wire. Or both. From owner-ietf-sasl Fri Aug 13 10:04:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4x70038706; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DH4xhV038705; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4wC3038696 for ; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 10:04:58 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:57 -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); Fri, 13 Aug 2004 10:04:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 10:05:21 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7840BC@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBRzVqtmM1ELj0QeCvRNk/Qj702gAEDIDw From: "Paul Leach" To: "Jeffrey Hutzelman" , "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 17:04:08.0451 (UTC) FILETIME=[8C054530:01C48157] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DH4xC3038700 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 Jeffrey Hutzelman > Sent: Friday, August 13, 2004 7:52 AM > To: Kurt D. Zeilenga; Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > The reason for the SHOULD is that the server has indicated which realms it > is willing/able to accept, and it's expected that the server will usually > reject any other realms. [Paul Leach] The server may also accept names in the realm "fbi.gov", but may not want to advertise that fact. Clients that have out of band knowledge about the realms supported may attempt to authenticate using one of those realms. Hence it is not "expected" that another realm will fail. The inverse: it can not be expected that it will succeed without OOB info. From owner-ietf-sasl Fri Aug 13 10:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEJUC039813; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHEJfY039812; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEITp039805 for ; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D4338E0036; Fri, 13 Aug 2004 13:14:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> From: Sam Hartman Date: Fri, 13 Aug 2004 13:14:25 -0400 In-Reply-To: <20040813004713.GJ892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:47:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I figure the new SASL GSS mech document will say Nicolas> something about channel bindings, but perhaps rfc2222bis Nicolas> should also. I do hope the new GSSAPI draft discusses this issue. Nicolas> Specifically I think that rfc2222bis could use: Nicolas> a) Security Considerations text about use of mechanisms Nicolas> that don't support channel bindings in conjunction with Nicolas> TLS. This seems problematic given that all current mechanisms don't support channel bindings. I think the best we could do is security considerations text describing the multiple layers problem. Nicolas> Clients should be admonished to validate TLS server Nicolas> IDs to prevent MITM attacks when using SASL-over-TLS. Nicolas> Similarly with other variants of SASL-over-TLS. Agreed. Nicolas> b) Text recommending support for channel bindings in Nicolas> future mechanisms, where possible. Digest-MD5, for Nicolas> example, could easily support channel bindings. This sounds out of scope for the SASL working group. I believe our charter prohibits us from adding new features to SASL. I don't think it has similar prohibitions for the GSSAPI mechanism. I agree channel bindings are a good thing for SASL. I disagree that they are well specified enough for us to be adding text about them to the base sasl document for this revision. From owner-ietf-sasl Fri Aug 13 10:17:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH3KW040135; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHH3Hf040134; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH35F040125 for ; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 312331783C9; Fri, 13 Aug 2004 13:17:09 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> From: Sam Hartman Date: Fri, 13 Aug 2004 13:17:09 -0400 In-Reply-To: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 13 Aug 2004 09:34:04 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 have completed my review of Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor Kurt> editorial comments (which I have separately sent to the Kurt> Editor). This note discussions problems I found related to Kurt> identities and authorization. Kurt> The 'Authorization and authentication identities' section Kurt> (3.2) starts off by stating that 'SASL authentication deals Kurt> with two identities' but then describes the processing model Kurt> to involve three identities, two of which it simply refers Kurt> to as 'authorization' identities. I believe we either need Kurt> better distinguish these identities within the document, by Kurt> through qualification (proxy authorization identity Kurt> v. application authorization identity) or by use of Kurt> replacement terminology (proxied identity v. authorization Kurt> identity). I prefer the latter approach as the former Kurt> qualifications are themselves a bit confused and the latter Kurt> seems more in step with RFC 2828. Would you mind explaining the problem you had with this section in better detail? I thought it flowed fairly well and is a significant improvement on our previous attempts to describe this issue. However I might well miss problems because as someone who has been following SASL I'm familiar with the issue. I am not always good at reading a document as someone new to a technology. --Sam From owner-ietf-sasl Fri Aug 13 10:36:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHaIti042332; Fri, 13 Aug 2004 10:36:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHaIYY042331; Fri, 13 Aug 2004 10:36:18 -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.11/8.12.9) with ESMTP id i7DHaHjF042325 for ; Fri, 13 Aug 2004 10:36:17 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:40:21 +0100 Message-ID: <411CFC0A.3070405@isode.com> Date: Fri, 13 Aug 2004 18:36:10 +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: Paul Leach CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>-----Original Message----- >>From: owner-ietf-sasl@mail.imc.org >> >> >>On Behalf Of Kurt D. Zeilenga >>Sent: Friday, August 13, 2004 12:32 AM >>To: Alexey Melnikov >>Cc: SASL WG >>Subject: Re: DIGEST-MD5 interop issue >> >>Exactly, the client is making assumptions which prevent users from being >> >> >>able to use it with independently developed servers. A client which >>cannot >>handle the full range of identity and realm values is simply broken. For >> >> >>instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in >> >> >>the realm project@OPENLDAP.ORG. I would not be able to use this or like >> >> >>clients. >> >> > >[Paul Leach] Use of names and realms of this form was not the intention >when the protocol was spec'd. The idea was that realms would be DNS >names. > Although the former might be true, the latter is not, as RFC 2831 has the following example of a realm: registered_users@gotham.news.example.com. >You can legitimately gripe that the spec does not make this intention >clear. > Indeed. Text about realms has caused problems before, because it is so vague. > Or that the client in question doesn't make clear its rules for >transforming what the user types into what gets sent on the wire. Or >both. > > Yes (both). Alexey From owner-ietf-sasl Fri Aug 13 10:44:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHi9po043087; Fri, 13 Aug 2004 10:44:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHi98P043086; Fri, 13 Aug 2004 10:44: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.11/8.12.9) with ESMTP id i7DHi7H8043075 for ; Fri, 13 Aug 2004 10:44: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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:48:15 +0100 Message-ID: <411CFDE3.4030702@isode.com> Date: Fri, 13 Aug 2004 18:44:03 +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: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> In-Reply-To: <411BAC01.7040407@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: Alexey Melnikov wrote: > There is another issue here: the client has split > "foo@bar.example.com" into username and realm parts, instead of > sending the value as is in the username option. The same client was > also treating a username "BAR\foo" as username=foo and realm=BAR. To complete my description: the client is transforming entered username "foo" into username="foo", realm="" > Arguably this is UI issue, but the client is still broken, because the > client makes assumptions about how username should look like and there > is no easy way to enter username as expected by the server. From owner-ietf-sasl Fri Aug 13 11:02:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2QBs045044; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DI2Q14045043; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2PlQ045026 for ; Fri, 13 Aug 2004 11:02:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 11:01:22 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 11:01:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 11:02:24 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBXBWqGsSCY03uQeit5LDe2JnrQwAAqO2w From: "Paul Leach" To: "Alexey Melnikov" Cc: "Kurt D. Zeilenga" , "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 18:01:39.0802 (UTC) FILETIME=[952FA3A0:01C4815F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DI2PlQ045036 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Friday, August 13, 2004 10:36 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Paul Leach wrote: > > > > >[Paul Leach] Use of names and realms of this form was not > the intention > >when the protocol was spec'd. The idea was that realms would be DNS > >names. > > > Although the former might be true, the latter is not, as RFC > 2831 has the following example of a realm: > registered_users@gotham.news.example.com. > I sure don't recall that example.... I can only speak for my intentions as I remember them. The MSFT UI usually has two modes: one where there are two edit boxes for entering name and realm (respectively); and one with one edit box where special characters are understood as separating them. An update could suggest some scheme such as this. Or it could merely state a requirement on UIs that arbitrary user names and realm names have to be able to be entered, and that if they want to use special characters to separate them, then they have to be able to escape the special characters (and that they need to specify their escape rules). From owner-ietf-sasl Sat Aug 14 10:54:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EHshMf053757; Sat, 14 Aug 2004 10:54:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EHshFb053756; Sat, 14 Aug 2004 10:54:43 -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.11/8.12.9) with ESMTP id i7EHsf6Y053749 for ; Sat, 14 Aug 2004 10:54:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt101.lnd4.gbr.da.uu.net [213.116.50.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 14 Aug 2004 18:58:45 +0100 Message-ID: <411E51A3.9070705@isode.com> Date: Sat, 14 Aug 2004 18:53:39 +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: Paul Leach CC: SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>Paul Leach wrote: >> >> >>>[Paul Leach] Use of names and realms of this form was not the intention >>> >>> >>>when the protocol was spec'd. The idea was that realms would be DNS >>>names. >>> >>> >>Although the former might be true, the latter is not, as RFC >>2831 has the following example of a realm: >>registered_users@gotham.news.example.com. >> >> >I sure don't recall that example.... I can only speak for my intentions >as I remember them. > >The MSFT UI usually has two modes: one where there are two edit boxes >for entering name and realm (respectively); and one with one edit box >where special characters are understood as separating them. > >An update could suggest some scheme such as this. Or it could merely >state a requirement on UIs that arbitrary user names and realm names >have to be able to be entered, and that if they want to use special >characters to separate them, then they have to be able to escape the >special characters (and that they need to specify their escape rules). > I like that. Speaking of UI: the UI should also be able to display all realms advertised by the server (otherwise what is the point of advertising them anyway?), e.g. a listbox with advertised realms, but so that the client can type in a different realm. From owner-ietf-sasl Sat Aug 14 23:32:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F6Wcrs013726; Sat, 14 Aug 2004 23:32:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F6Wc0N013725; Sat, 14 Aug 2004 23:32:38 -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.11/8.12.9) with ESMTP id i7F6Wb51013700 for ; Sat, 14 Aug 2004 23:32:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7F6WUMw025334; Sun, 15 Aug 2004 06:32:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 15 Aug 2004 07:13:04 +0200 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20040813082412.081cbe20@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 07:17 PM 8/13/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> I have completed my review of > Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor > Kurt> editorial comments (which I have separately sent to the > Kurt> Editor). This note discussions problems I found related to > Kurt> identities and authorization. > > Kurt> The 'Authorization and authentication identities' section > Kurt> (3.2) starts off by stating that 'SASL authentication deals > Kurt> with two identities' but then describes the processing model > Kurt> to involve three identities, two of which it simply refers > Kurt> to as 'authorization' identities. I believe we either need > Kurt> better distinguish these identities within the document, by > Kurt> through qualification (proxy authorization identity > Kurt> v. application authorization identity) or by use of > Kurt> replacement terminology (proxied identity v. authorization > Kurt> identity). I prefer the latter approach as the former > Kurt> qualifications are themselves a bit confused and the latter > Kurt> seems more in step with RFC 2828. > > >Would you mind explaining the problem you had with this section in >better detail? I thought it flowed fairly well and is a significant >improvement on our previous attempts to describe this issue. However >I might well miss problems because as someone who has been following >SASL I'm familiar with the issue. I am not always good at reading a >document as someone new to a technology. Sure. The following 3.2 text: > The processing model is as follows. A server, upon completion of the > authentication mechanism, uses the results produced by the > authentication mechanism, the client-provided authorization identity > value (which may be the empty string), and local policy information > to derive an authorization identity. clearly shows the document is using the term 'authorization identity' to refer, at times, to the client-provided authorization identity and, at times, to a derived authorization identity. However, in other portions of the document, the term 'authorization identity' is mostly used unqualified. While qualification of the term would likely resolve this issue, that solution would likely be cumbersome. As the 'authorization identity' more properly refers to the identity directly used in authorization, it seems more appropriate to call the value referred to here as the 'client-provided authorization identity' as the 'proxied identity'. While I am working on a more complete replacement text, here is glimpse of the suggested clarification: Conceptually, the SASL framework deals with three identities: - the authentication identity, - the proxied identity, and - the authorization identity. The authentication identity is derived from client's authentication credentials. The proxied identity is optionally provided by the client seeking to assume the identity of another user (or entity). The authorization identity is the server-produced primary identity used for making access control and other policy decisions. These identities are managed as follows: The server uses the authentication identity established through the authentication exchange, the proxied identity (if provided), and possibly other information to produce the authorization identity. I've been trying to come with a new term to call the derived identity to allow us unambiguously use the term 'authorization identity' to refer to the client provided value, as the WG seems to have some attachment to this usage. The best I have come with here is 'subject identity' (the identity which is the subject in access control decisions). I do not recommend this approach myself as I believe it would be more proper to use the term 'authorization identity' to refer to the subject of access control decisions. However, I am far more concerned about ambiguous use of the term (using the term to refer to two different values) than I am about which of the two uses continues to this term. That is, I can live with calling the client provided value an 'authorization identity' if we don't also use that term to refer to the derived identity. Kurt From owner-ietf-sasl Wed Aug 18 11:43:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhdGE014932; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIhdPf014931; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhcsh014906 for ; Wed, 18 Aug 2004 11:43:38 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7IIhbUF014448 for ; Wed, 18 Aug 2004 14:43:37 -0400 Received: from [135.91.110.75] (thansen-n.mt.att.com[135.91.110.75](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818184354gw1002evofe> (Authid: tony); Wed, 18 Aug 2004 18:43:54 +0000 Message-ID: <4123A355.5000209@att.com> Date: Wed, 18 Aug 2004 14:43:33 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: md5 definitely broken? 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 saw a note in the openpgp mailing list about md5 definitely being cracked. Anyone know more? Tony Hansen tony@att.com From owner-ietf-sasl Wed Aug 18 12:01:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1mgk017793; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJ1mEx017792; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1iQR017772 for ; Wed, 18 Aug 2004 12:01:44 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BxVgt-0005Ps-00 for ; Wed, 18 Aug 2004 21:01:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: md5 definitely broken? Date: Wed, 18 Aug 2004 21:01:36 +0200 Lines: 16 Message-ID: References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:owG6sPrHdscmMpa7vt+m9PbTcO8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen writes: > I saw a note in the openpgp mailing list about md5 definitely being > cracked. Anyone know more? "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199/ Whether "collisions" imply "cracked", in the real world, probably depend on the details, and the application. It is not clear (to me, at least) how you would attack HMAC-MD5 based on the above result. (FWIW, I've verified all but the RIPEMD-128 collisions in the paper.) Regards, Simon From owner-ietf-sasl Wed Aug 18 12:15:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJFj9J020794; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJFjkX020793; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJFide020776 for ; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 23832 invoked by uid 0); 18 Aug 2004 19:15:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.240.240) by woodstock.binhost.com with SMTP; 18 Aug 2004 19:15:45 -0000 Message-Id: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 18 Aug 2004 15:16:28 -0400 To: Tony Hansen , ietf-sasl From: Russ Housley Subject: Re: md5 definitely broken? In-Reply-To: <4123A355.5000209@att.com> References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony: Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and three other hash functions. You can get it from: http://eprint.iacr.org/2004/199.pdf It does not provide the attacks, but it does allow one to confirm the discovery of collisions. The ramification of this news is pretty clear for digital signatures that make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 and HTTP Digest. Anything that has already been signed with MD5 is definitely safe. If one stops using MD5 today, nothing that has already been signed is at risk. However, it is getting risky to sign certificates with MD5, in my opinion. Russ At 02:43 PM 8/18/2004, Tony Hansen wrote: >I saw a note in the openpgp mailing list about md5 definitely being >cracked. Anyone know more? > > Tony Hansen > tony@att.com > From owner-ietf-sasl Wed Aug 18 13:06:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WWg029579; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IK6W4i029578; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WUw029556 for ; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from lgl@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6S1i024246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2004 13:06:29 -0700 (PDT) Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.212]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6PO2001831; Wed, 18 Aug 2004 13:06:26 -0700 (PDT) Message-Id: <6.0.0.10.2.20040818130258.047981d0@qcmail1.qualcomm.com> X-Sender: llundbla@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.10 (Beta) Date: Wed, 18 Aug 2004 13:06:24 -0700 To: Russ Housley , Tony Hansen , ietf-sasl From: Laurence Lundblade Subject: Re: md5 definitely broken? In-Reply-To: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> References: <4123A355.5000209@att.com> <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:16 PM 8/18/2004, Russ Housley wrote: >Tony: > >Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, >MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and >three other hash functions. You can get it from: > > http://eprint.iacr.org/2004/199.pdf > >It does not provide the attacks, but it does allow one to confirm the >discovery of collisions. > >The ramification of this news is pretty clear for digital signatures that >make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 >and HTTP Digest. > >Anything that has already been signed with MD5 is definitely safe. If one >stops using MD5 today, nothing that has already been signed is at risk. Except if you determine when something was signed by a signed timed stamp from time stamp authority that used MD5. You can't distinguish what was signed in the past from something that was made to look like it was signed in the past if you're using signed time stamps with MD5. You're OK if you have some *other* strong way to determine when it was signed. LL From owner-ietf-sasl Wed Aug 18 14:59:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxiI4048024; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILxiEe048023; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxema048012 for ; Wed, 18 Aug 2004 14:59:42 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id BAC1997 for ; Wed, 18 Aug 2004 15:59:43 -0600 (MDT) Message-ID: <4123D15A.4060509@computerking.ca> Date: Wed, 18 Aug 2004 15:59:54 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: plain and login not working 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: This is a thread i started in postfix users but think it would be on topic at this group too. The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. EHLO computerking.ca 250-mail1.computerking.ca 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-XVERP 250 8BITMIME > * RYAN vAN GINNEKEN [040818 01:49]: > > >> I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >> stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >> configured the my /user/local/lib/sasl2 dir to contain only >> Sendmail.conf liblogin.so libplain.a libplain.so.2 >> liblogin.a liblogin.so.2 libplain.so smptd.conf >> > > > OK. > > > >> and my smtpd.conf file has this configuration >> >> # This sets smtpd to authenticate using the saslauthd daemon. >> pwcheck_method:saslauthd >> # This allows only plain and login as the authentication mechanisms. >> mech_list: plain login >> > > > OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. > One never knows with SASL ... > > > I added a space stopped and started saslauthd using this command /usr/local/etc/rc.d/saslauthd.sh start /usr/local/etc/rc.d/saslauthd.sh start then stopped and started postfix using postfix stop postfix start still get the errors Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >> Seems simple enough however when i try to logon to my SMTP server i >> get the following errors. >> Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL PLAIN authentication failed >> Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL LOGIN authentication failed >> > > > OK. > > > >> Is there a log i can check for sasl errors somewhere or do i need to >> > > > SASL logs to auth.*, check your syslog configuration if it catches this. > > > I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow >> change my permissions on the passwd file any help would be >> appreciated. > > > Which passwd file? You have configured Postfix for client-side as well > as fpr server-side SMTP AUTH. Client-side introduces > /etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we > talking about /etc/passwd. If you mean /etc/passwd then you don't need > to change permissions. saslauthd is run started by root:root, so > permissions should be no problem. > > > Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. >> Here is a posconf -n output if that helps anyone help me thank you in >> advance. >> >> v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> broken_sasl_auth_clients = yes >> > > > OK. > > > >> command_directory = /usr/local/sbin >> config_directory = /usr/local/etc/postfix >> daemon_directory = /usr/local/libexec/postfix >> debug_peer_level = 2 >> home_mailbox = IMAPdir/INBOX/ >> inet_interfaces = all >> mail_owner = postfix >> mailq_path = /usr/local/bin/mailq >> manpage_directory = /usr/local/man >> mydestination = $myhostname, localhost.$mydomain $mydomain >> mydomain = computerking.ca >> myhostname = mail1.computerking.ca >> mynetworks_style = subnet >> myorigin = $mydomain >> newaliases_path = /usr/local/bin/newaliases >> queue_directory = /var/spool/postfix >> readme_directory = no >> relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >> sample_directory = /usr/local/etc/postfix >> sendmail_path = /usr/local/sbin/sendmail >> setgid_group = maildrop >> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >> > > > If you want to offer server-side SMTP AUTH, you don't need > smtp_sasl_password_maps; they are for the smtp daemon (client-side) > > > What ??? i will comment out this feature for now do not quite understand what this is used for >> smtp_tls_loglevel = 2 >> smtp_tls_note_starttls_offer = yes >> smtp_use_tls = yes >> smtpd_recipient_restrictions = permit_mx_backup > > > Turn off smtp_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> smtpd_sasl_auth_enable = yes >> > > > OK. > > > >> smtpd_sasl_local_domain = >> > > > OK. > > > >> smtpd_sasl_security_options = noanonymous >> > > > OK. > > > >> smtpd_sender_restrictions = permit_mx_backup >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> > > > OK. > > > >> smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >> smtpd_tls_auth_only = yes >> smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >> smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >> smtpd_tls_loglevel = 2 >> smtpd_tls_received_header = yes >> smtpd_tls_session_cache_timeout = 3600s >> smtpd_use_tls = yes >> > > > Turn off smtpd_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] >> soft_bounce = no >> tls_random_source = dev:/dev/urandom >> unknown_local_recipient_reject_code = 450 >> virtual_alias_domains = sculpturaldesign.ca >> virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >> > > > So far so good... > > How do you run saslauthd? > > using the saslauthd script in the rc.d dir /usr/local/etc/rc.d/saslauthd.sh start > Where does saslauthd put its socket? > > not sure how do i find out??? > What does 'saslauthd -a shadow -d' give as ouput? > > v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login yikes that seems like it might be a problem > Look for run_path. > what?? > Can postfix access this $run_path directory? > > what?? > What do you use as authentication backend i.e. the source of your > usernames and passwords? > > I what to use /etc/passwd > Can you authenticate without Postfix using 'testsaslauthd'? > > v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd su: testsaslauthd: command not found I also did a locate testsaslauthd and it did not find anything > p@rick > > > > From owner-ietf-sasl Wed Aug 18 15:10:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAJYj049591; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IMAJWh049590; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAGvU049569 for ; Wed, 18 Aug 2004 15:10:16 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 18 Aug 2004 15:10:54 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:04 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 18 Aug 2004 15:09:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: md5 definitely broken? Date: Wed, 18 Aug 2004 15:10:07 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: md5 definitely broken? thread-index: AcSFV9LqW81pSYYhQ72w4YiFay2arAAFrPMQ From: "Paul Leach" To: "Simon Josefsson" , X-OriginalArrivalTime: 18 Aug 2004 22:09:17.0750 (UTC) FILETIME=[01475560:01C48570] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IMAGvU049583 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 Simon Josefsson > Sent: Wednesday, August 18, 2004 12:02 PM > To: ietf-sasl@imc.org > Subject: Re: md5 definitely broken? > > > Tony Hansen writes: > > > I saw a note in the openpgp mailing list about md5 definitely being > > cracked. Anyone know more? > > "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" > http://eprint.iacr.org/2004/199/ > > Whether "collisions" imply "cracked", in the real world, > probably depend on the details, and the application. It is > not clear (to me, at least) how you would attack HMAC-MD5 > based on the above result. I've see mail from Hugo Krawczyk that says it does not place HMACs in jeopardy. Also, AFAIK, it has not been claimed that, given some arbitrary text, an attacker can find other text that hashes to the same value. However, at the current time, the existence of these collisions strongly implies that that is possible, and one must assume that in the not to distant future it will be done. Hence, it would be the conservative thing to do to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher suite. From owner-ietf-sasl Wed Aug 18 16:15:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFPRA060070; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INFP0A060069; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFORU060055 for ; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7INFOfb001739 for ; Wed, 18 Aug 2004 18:15:24 -0500 Received: from [135.210.8.81] (unknown[135.210.8.81](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818231541gw1002f0ioe> (Authid: tony); Wed, 18 Aug 2004 23:15:41 +0000 Message-ID: <4123E30B.7060908@att.com> Date: Wed, 18 Aug 2004 19:15:23 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: md5 definitely broken? References: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Which is why I brought it up on ietf-sasl. Should we be busy defining DIGEST-SHA256 and not DIGEST-MD5? Tony Hansen tony@att.com Paul Leach wrote: >>Tony Hansen writes: >> >>>I saw a note in the openpgp mailing list about md5 definitely being >>>cracked. Anyone know more? >> >>"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" >>http://eprint.iacr.org/2004/199/ >> >>Whether "collisions" imply "cracked", in the real world, >>probably depend on the details, and the application. It is >>not clear (to me, at least) how you would attack HMAC-MD5 >>based on the above result. > > I've see mail from Hugo Krawczyk that says it does not place HMACs in > jeopardy. > > Also, AFAIK, it has not been claimed that, given some arbitrary text, an > attacker can find other text that hashes to the same value. However, at > the current time, the existence of these collisions strongly implies > that that is possible, and one must assume that in the not to distant > future it will be done. Hence, it would be the conservative thing to do > to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher > suite. From owner-ietf-sasl Wed Aug 18 22:46:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J5kZ39018844; Wed, 18 Aug 2004 22:46:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J5kZiO018841; Wed, 18 Aug 2004 22:46: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.11/8.12.9) with ESMTP id i7J5kYIu018824 for ; Wed, 18 Aug 2004 22:46:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7J5kHMw053507; Thu, 19 Aug 2004 05:46:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040819074135.040bd4e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 19 Aug 2004 07:46:53 +0200 To: RYAN vAN GINNEKEN From: "Kurt D. Zeilenga" Subject: Re: plain and login not working Cc: ietf-sasl In-Reply-To: <4123D15A.4060509@computerking.ca> References: <4123D15A.4060509@computerking.ca> 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:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME > >>* RYAN vAN GINNEKEN [040818 01:49]: >> >> >>>I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >>>stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >>>configured the my /user/local/lib/sasl2 dir to contain only >>>Sendmail.conf liblogin.so libplain.a libplain.so.2 >>>liblogin.a liblogin.so.2 libplain.so smptd.conf >>> >> >> >>OK. >> >> >> >>>and my smtpd.conf file has this configuration >>> >>># This sets smtpd to authenticate using the saslauthd daemon. >>>pwcheck_method:saslauthd >>># This allows only plain and login as the authentication mechanisms. >>>mech_list: plain login >>> >> >> >>OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. >>One never knows with SASL ... >> >> >I added a space stopped and started saslauthd using this command >/usr/local/etc/rc.d/saslauthd.sh start >/usr/local/etc/rc.d/saslauthd.sh start >then stopped and started postfix using >postfix stop >postfix start >still get the errors > >Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed > > >>>Seems simple enough however when i try to logon to my SMTP server i get the following errors. >>>Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >>>Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >>> >> >> >>OK. >> >> >> >>>Is there a log i can check for sasl errors somewhere or do i need to >>> >> >> >>SASL logs to auth.*, check your syslog configuration if it catches this. >> >> >I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? > >Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow > >>>change my permissions on the passwd file any help would be >>>appreciated. >> >> >>Which passwd file? You have configured Postfix for client-side as well >>as fpr server-side SMTP AUTH. Client-side introduces >>/etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we >>talking about /etc/passwd. If you mean /etc/passwd then you don't need >>to change permissions. saslauthd is run started by root:root, so >>permissions should be no problem. >> >> >Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. > >>>Here is a posconf -n output if that helps anyone help me thank you in advance. >>> >>>v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >>>alias_database = hash:/etc/aliases >>>alias_maps = hash:/etc/aliases >>>broken_sasl_auth_clients = yes >>> >> >> >>OK. >> >> >> >>>command_directory = /usr/local/sbin >>>config_directory = /usr/local/etc/postfix >>>daemon_directory = /usr/local/libexec/postfix >>>debug_peer_level = 2 >>>home_mailbox = IMAPdir/INBOX/ >>>inet_interfaces = all >>>mail_owner = postfix >>>mailq_path = /usr/local/bin/mailq >>>manpage_directory = /usr/local/man >>>mydestination = $myhostname, localhost.$mydomain $mydomain >>>mydomain = computerking.ca >>>myhostname = mail1.computerking.ca >>>mynetworks_style = subnet >>>myorigin = $mydomain >>>newaliases_path = /usr/local/bin/newaliases >>>queue_directory = /var/spool/postfix >>>readme_directory = no >>>relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >>>sample_directory = /usr/local/etc/postfix >>>sendmail_path = /usr/local/sbin/sendmail >>>setgid_group = maildrop >>>smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>> >> >> >>If you want to offer server-side SMTP AUTH, you don't need >>smtp_sasl_password_maps; they are for the smtp daemon (client-side) >> >> >What ??? i will comment out this feature for now do not quite understand what this is used for > >>>smtp_tls_loglevel = 2 >>>smtp_tls_note_starttls_offer = yes >>>smtp_use_tls = yes >>>smtpd_recipient_restrictions = permit_mx_backup >> >> >>Turn off smtp_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off > >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>>smtpd_sasl_auth_enable = yes >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_local_domain = >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_security_options = noanonymous >>> >> >> >>OK. >> >> >> >>>smtpd_sender_restrictions = permit_mx_backup >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>> >> >> >>OK. >> >> >> >>>smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >>>smtpd_tls_auth_only = yes >>>smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >>>smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >>>smtpd_tls_loglevel = 2 >>>smtpd_tls_received_header = yes >>>smtpd_tls_session_cache_timeout = 3600s >>>smtpd_use_tls = yes >>> >> >> >>Turn off smtpd_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. >Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] > >>>soft_bounce = no >>>tls_random_source = dev:/dev/urandom >>>unknown_local_recipient_reject_code = 450 >>>virtual_alias_domains = sculpturaldesign.ca >>>virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >>> >> >> >>So far so good... >> >>How do you run saslauthd? >> >using the saslauthd script in the rc.d dir >/usr/local/etc/rc.d/saslauthd.sh start > >>Where does saslauthd put its socket? >> >not sure how do i find out??? > >>What does 'saslauthd -a shadow -d' give as ouput? >> >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d >saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d >saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d >saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login > >yikes that seems like it might be a problem > >>Look for run_path. >what?? > >>Can postfix access this $run_path directory? >> >what?? > >>What do you use as authentication backend i.e. the source of your >>usernames and passwords? >> >I what to use /etc/passwd > >>Can you authenticate without Postfix using 'testsaslauthd'? >> >v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd >su: testsaslauthd: command not found > >I also did a locate testsaslauthd and it did not find anything > >>p@rick >> >> >> From owner-ietf-sasl Thu Aug 19 08:24:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFO0fj012874; Thu, 19 Aug 2004 08:24:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFO09I012873; Thu, 19 Aug 2004 08:24:00 -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 ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFNxAZ012855 for ; Thu, 19 Aug 2004 08:23:59 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i7JFNdb7021625; Thu, 19 Aug 2004 11:23:39 -0400 (EDT) Message-ID: <4124C606.4000103@oceana.com> Date: Thu, 19 Aug 2004 11:23:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Scott Hollenbeck CC: Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , Alexey Melnikov , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Scott Hollenbeck wrote: > I sent a request to the apps discuss list a while back and didn't receive > any responses. OK, time for a more pointed request: would at least one of > you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 from an > applications perspective? It's in WGLC and the SASL WG chair is asking for > review help. I just spent an hour or so reviewing the -08 draft. I have a couple of comments and questions below. Other than these, I don't see anything which breaks any of the existing mechanisms, libraries, or applications that I'm familiar with. I have a few editorial nits which I'll send separately to Alexey. Section 4, requirement 2) - The draft says that "the protocol profile SHOULD also describe how an empty initial response is encoded." I believe that this should be required of the profile and therefore is a MUST, not a SHOULD. Section 4, requirement 3) - Should we explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded? Section 7, paragraph 3 - The draft says "The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity." Presumably, the client has *already* been authenticated by external means and we're just determining if the client can proxy. Unless I'm completely missing the meaning of the existing text, I'd suggest replacing "authenticate as" with "have the access privileges of". -- 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 Aug 19 15:23:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNcXT080979; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JMNcoi080978; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNbhb080963 for ; Thu, 19 Aug 2004 15:23:37 -0700 (PDT) (envelope-from jeffstep@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Aug 2004 15:23:27 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Aug 2004 15:23:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Aug 2004 15:23:26 -0700 Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 15:23:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: plain and login not working Date: Thu, 19 Aug 2004 15:23:21 -0700 Message-ID: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: plain and login not working Thread-Index: AcSFsevWKrePO/lOT5OErRZqKcnLnQAiKl5A From: "Jeff Stephenson" To: "RYAN vAN GINNEKEN" Cc: "ietf-sasl" X-OriginalArrivalTime: 19 Aug 2004 22:23:02.0733 (UTC) FILETIME=[176B7FD0:01C4863B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JMNbhb080969 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As Kurt says, this has nothing to do with this group. However, I'd point out that many servers will not advertise either PLAIN or LOGIN unless you're using a secure connection. Since the server obviously supports TLS, I'd suggest securing the connection with that, at which point you'll probably see the plaintext SASL mechanisms in response to an EHLO. -- jeff -----Original Message----- From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Wednesday, August 18, 2004 10:47 PM To: RYAN vAN GINNEKEN Cc: ietf-sasl Subject: Re: plain and login not working At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME From owner-ietf-sasl Fri Aug 20 02:02:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92qbE021370; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K92q4B021369; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92po3021335 for ; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id A2A0A9E for ; Fri, 20 Aug 2004 03:02:47 -0600 (MDT) Message-ID: <4125BE38.7060901@computerking.ca> Date: Fri, 20 Aug 2004 03:02:48 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: Re: plain and login not working References: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> In-Reply-To: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.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: Thanks and sorry for the off topic post Jeff Stephenson wrote: >As Kurt says, this has nothing to do with this group. However, I'd >point out that many servers will not advertise either PLAIN or LOGIN >unless you're using a secure connection. Since the server obviously >supports TLS, I'd suggest securing the connection with that, at which >point you'll probably see the plaintext SASL mechanisms in response to >an EHLO. > >-- jeff > >-----Original Message----- >From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] >On Behalf Of Kurt D. Zeilenga >Sent: Wednesday, August 18, 2004 10:47 PM >To: RYAN vAN GINNEKEN >Cc: ietf-sasl >Subject: Re: plain and login not working > > >At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: > > >>This is a thread i started in postfix users but think it would be on >> >> >topic at this group too. > >Not sure why you think this topic is appropriate for this list. >This list is for undertaking the work of the IETF SASL Working Group, a >work chartered to engineer SASL technical specifications. >So, unless you have a issue with a particular technical specification >which we are charged to engineer, the discussion should likely be held >on lists specific to SASL implementations you are experience problems >with. > >Regards, Kurt >IETF SASL WG co-chair > > > >>The output of my telnet session is like below and contains NO!!!!! >> >> >entry for PLAIN or LOGIN. Please keep reading this mail as i have >answered all of the questions asked by Paterick. > > >>EHLO computerking.ca >>250-mail1.computerking.ca >>250-PIPELINING >>250-SIZE 10240000 >>250-VRFY >>250-ETRN >>250-STARTTLS >>250-XVERP >>250 8BITMIME >> >> > > > From owner-ietf-sasl Mon Aug 23 03:18:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAIHjr003753; Mon, 23 Aug 2004 03:18:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAIHwJ003752; Mon, 23 Aug 2004 03:18:17 -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.11/8.12.9) with ESMTP id i7NAIGsn003744 for ; Mon, 23 Aug 2004 03:18:16 -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 (internal) with ESMTPA; Mon, 23 Aug 2004 11:22:48 +0100 Message-ID: <4129C44F.4010005@isode.com> Date: Mon, 23 Aug 2004 11:17:51 +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: Ken Murchison CC: Scott Hollenbeck , Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> <4124C606.4000103@oceana.com> In-Reply-To: <4124C606.4000103@oceana.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: Ken Murchison wrote: > Scott Hollenbeck wrote: > >> I sent a request to the apps discuss list a while back and didn't >> receive >> any responses. OK, time for a more pointed request: would at least >> one of >> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 >> from an >> applications perspective? It's in WGLC and the SASL WG chair is >> asking for >> review help. > > I just spent an hour or so reviewing the -08 draft. I have a couple > of comments and questions below. Other than these, I don't see > anything which breaks any of the existing mechanisms, libraries, or > applications that I'm familiar with. I have a few editorial nits > which I'll send separately to Alexey. > > Section 4, requirement 2) - The draft says that "the protocol > profile SHOULD also describe how an empty initial response is > encoded." I believe that this should be required of the profile and > therefore is a MUST, not a SHOULD. You are probably right. The initial response is a SHOULD feature of SASL, that is why, I think, SHOULD is used here. So basically the document should say: "if the initial response is supported by the protocol profile, the profile MUST specify how an empty response is encoded". > Section 4, requirement 3) - Should we explicitly state that the > profile also needs to describe how *empty* server challenges and > client responses as encoded? Not really, as empty challenge/response is a 0-length string, which all profiles should be able to handle already. But I am Ok with clarifying that all protocol profiles MUST be able to exchange 0-length challenges/responses. > Section 7, paragraph 3 - The draft says "The server uses > information, external to SASL, to determine whether the client is > permitted to authenticate as the authorization identity." Presumably, > the client has *already* been authenticated by external means and > we're just determining if the client can proxy. Unless I'm completely > missing the meaning of the existing text, I'd suggest replacing > "authenticate as" with "have the access privileges of". I agree, but I suggest to replace "to authenticate as" with "to act as". Alexey From owner-ietf-sasl Sun Aug 29 14:47:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlRYe010806; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TLlRBM010805; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlQa2010798 for ; Sun, 29 Aug 2004 14:47:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 33948168060; Sun, 29 Aug 2004 17:47:58 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes for IETf 60 meeting Message-Id: <20040829214758.33948168060@cz.mit.edu> Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Review and comment; these will be sent in mid next week] Simple Authentication and Security Layer WG (SASL) Tuesday, August 3 at 1300-1400 ============================== CHAIRS: Sam Hartman Kurt Zeilenga scribe: Wyllys Ingersoll Summary (Kurt): * Done with anonymous SASLPREP, working on base spec, in WG last call. * more attention to digest-md5, GSSAPI, cram-md5 * base spec needs more reviewers. Without review, document cannot progress. Alexey Melnikov: * not many comments in base spec WG last call. * clarification on how re-keying is done - needs new text for security considerations or recommendations section Digest-MD5 (Alexey) * not much work done yet. * open issues at end of doc * needs comments on CBC mode, Sam H. replied, discussion to follow on mailing list * testing of LDAP-aware client and server revealed an interop issue - digest server advertises realms that it supports, client SHOULD pick up realm from a list, but client is not obeying the "SHOULD" and chooses something else. Server assumes that the client MUST choose a listed realm. Is server broken or just interpreting the spec differently? (Kurt) - needs further revision and engineering tests before last call. (Alexey) - more than 1 revision needed. * CBC mode attack to be resolved at next meeting. (Kurt) - possible to get into WG last call by end of year? (Alexey) - "I will try". - no co-author needed (Kurt) - December will be earliest last-call. GSSAPI: * non-NULL channel bindings issue - original doc and new draft says you MUST provide NULL bindings. Simon wanted to be able to use channel bindings. It would be nice to use mechanisms like CCM or other mechanisms discussed at the KITTEN BOF. * Multiple GSS implementations of the krb5 mechanism already working together. * Suggestions - split draft and document GSS-KRB5 as existing, define new GSS draft to deal with new mechanisms, channel binding issue to be addressed in newer draft. * Sam H. issue - new GSSAPI mechanism should be designed to save round-trips, existing one requires 2 or more. * We could address this in a new draft if we think it is worth solving; discussion on list. * Nico issue - fix re-keying problems in new draft. * Sam H. - 2 comments from Jabber (Simon J) - The original motivation for wanting channel bindings was to avoid a per-message token from one context being used with another context. Strong desire to maintain compatibility with existing GSSAPI mechanisms. * Sam (not as chair) - WG must decide that current GSSAPI mech is adequate for future needs and wont be used as a reason for preferring to make SASL mechs instead of GSSAPI mechs - or - FIX IT. Compatiblity with existing KRB5 mech is requirement. * Currently, 1 SASL mech for each GSSAPI mech. In future, this may not be true. * Kurt - we WILL preserve existing SASL-GSS mechanisms. * Sam H - GSS-SPNEGO will likely need to be deprecated because of existing security problems. * Larry G - are there existing deployments of SASL-GSS mechs other than KRB5 and SPNEGO (eg. GSS-xxxxx)? - no * Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands) * Kurt - reluctant to take on new work for WG, encourage an individual draft. * Larry G - argues against lightweight, not much need for it yet. * Kurt - 2 proposals would be good for WG so there is choice. CRAM-MD5: * needs attention once the base spec is complete Misc: * Kurt and Sam to revamp the list of WG milestones and send to list. * Kurt - base spec needs to get done ASAP. Needs more comments and reviewers. * Nico - re-keying issue again. * Kurt - don't make assumptions about security layers that are available. * Sam H. - no requirement for bi-directional exchange once established, re-keying is not always going to be possible. * Nico - Still need an API for implementations that want to use it. * Sam H. - mech designer can't know whether or not bi-directional flow will be possible. * Nico - The mech needs a way to determine if re-key is even possible so it can make the decision on whether or not to do it. An API would make this possible. * Kurt - add new text to draft for security considerations? * Chris Newman - is anyone going to be negatively impacted by changing the generic SASL-GSSAPI spec at this time? Nico says he needs to check. Announcements: * Sam H - Liberty Alliance needs input on their document. * Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS End - 13:45PM From owner-ietf-sasl Tue Aug 3 09:58:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw68L078968; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Gw6Sa078967; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-129-194.ietf60.ietf.org [130.129.129.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw5Vm078961 for ; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id DD0EC160487; Tue, 3 Aug 2004 12:56:34 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> <4104263B.2000707@isode.com> From: Sam Hartman Date: Tue, 03 Aug 2004 12:56:34 -0400 In-Reply-To: <4104263B.2000707@isode.com> (Alexey Melnikov's message of "Sun, 25 Jul 2004 22:29:31 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I don't mind the changes you are proposing (at least I Alexey> agree with their motivation), however this suggestion is a Alexey> bit late and I would like to point out that there several Alexey> independent implementations of GSSAPI (Kerberos) mechanism Alexey> that interoperate well (at least better than DIGEST-MD5). We cannot make these changes for the SASL mechanism called GSSAPI; that seems clear. From owner-ietf-sasl Wed Aug 4 14:36:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaVRs019191; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74LaVHD019190; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-130-188.ietf60.ietf.org [130.129.130.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaUWO019184 for ; Wed, 4 Aug 2004 14:36:30 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 762741608F7; Wed, 4 Aug 2004 17:35:06 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: SASL working group summary for IETF 60 From: Sam Hartman Date: Wed, 04 Aug 2004 17:35:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: The SASL working group met for one hour. The SASL base spec (draft-ietf-sasl-rfc2222bis) is in last call. We need more review of this document; without this review the chairs will be unable to recommend the document for publication. Nicolas Williams will provide security considerations text for rekeying to be considered by the group. Not much progress has been made on digest-md5 since the last IETF. The explicit IV issues for CBC have been discussed but are still open. The character set conversion issues are still open although there is still a possibility we will be able to move exclusively to UTF8. At least two more revisions of the draft are expected. There was discussion of the GSSAPI mechanism. everyone agrees we need to maintain compatibility with the widely deployed Kerberos 5 mechanism. Sam Hartman proposed significant changes to other GSSAPI SASL mechanisms for improved efficiency. One reason we may want this change is HTTP SASL. Discussion will continue on the list. From owner-ietf-sasl Wed Aug 4 15:07:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7eqR021631; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74M7eVU021630; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7cdp021624 for ; Wed, 4 Aug 2004 15:07:39 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BsTvD-0005VW-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASL working group summary for IETF 60 Date: Thu, 05 Aug 2004 00:07:38 +0200 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:1UGFIBfleUZDGUKIZYN4HerfHRM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > There was discussion of the GSSAPI mechanism. everyone agrees we need > to maintain compatibility with the widely deployed Kerberos 5 > mechanism. Sam Hartman proposed significant changes to other GSSAPI > SASL mechanisms for improved efficiency. One reason we may want this > change is HTTP SASL. Discussion will continue on the list. How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" document, and one document for the generic "GSS-*" mechanism set? If the protocol for "GSS-*" will be different from the "GSSAPI" protocol, perhaps it doesn't make sense to describe both in the same document. It might also help focus on making the "GSS-*" protocol better, without having to pay attention to Kerberos 5 specific issues. Regards, Simon From owner-ietf-sasl Fri Aug 6 17:11:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i770BjYF077525; Fri, 6 Aug 2004 17:11:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i770BjAV077524; Fri, 6 Aug 2004 17:11:45 -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.11/8.12.9) with ESMTP id i770BjZj077514 for ; Fri, 6 Aug 2004 17:11:45 -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 i770BkJ6007146 for ; Fri, 6 Aug 2004 17:11:46 -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 i770BjDi008488 for ; Fri, 6 Aug 2004 18:11:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7709DTP005761 for ; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7709DCZ005760 for ietf-sasl@imc.org; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Date: Fri, 6 Aug 2004 19:09:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Text on re-keying for rfc2222bis Message-ID: <20040807000913.GZ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Diffs for section 6.3: --- /tmp/sasl-6.3-orig Fri Aug 6 19:08:10 2004 +++ /tmp/sasl-6.3 Fri Aug 6 19:08:00 2004 @@ -1,5 +1,6 @@ + 6.3. Multiple authentications Unless otherwise stated by the protocol's profile, only one successful SASL negotiation may occur in a protocol session. In this case, once an authentication protocol exchange has successfully @@ -8,18 +9,22 @@ If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. 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 remains in effect. + second security layer replaces the first; this can be used as a form + of re-keying, where SASL mechanisms that provide security layers fail + to provide for re-keying, provided that the authenticated identities + remain the same. If a security layer is in effect and a subsequent + SASL negotiation selects no security layer, the original security + layer remains in effect. Where a protocol profile permits multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. + New text for the security considerations section: The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. The use of cryptographic keys and the passage of time after the initial use of a cryptographic key weakens said keys by increasing the amount of ciphertext, other cryptographic material, and/or time that is available to cryptanalysts in any effort to attack the security layers. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. SASL does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers SHOULD provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should re-authenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Sorry for the delay. Nico -- From owner-ietf-sasl Wed Aug 11 07:07:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BE7Y7a046659; Wed, 11 Aug 2004 07:07:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BE7YEN046658; Wed, 11 Aug 2004 07:07:34 -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.11/8.12.9) with ESMTP id i7BE7SP8046560 for ; Wed, 11 Aug 2004 07:07:29 -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 (internal) with ESMTPA; Wed, 11 Aug 2004 15:11:11 +0100 Message-ID: <411A280D.5080404@isode.com> Date: Wed, 11 Aug 2004 15:07:09 +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: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: SASL working group summary for IETF 60 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: Simon Josefsson wrote: >Sam Hartman writes: > > >>There was discussion of the GSSAPI mechanism. everyone agrees we need >>to maintain compatibility with the widely deployed Kerberos 5 >>mechanism. Sam Hartman proposed significant changes to other GSSAPI >>SASL mechanisms for improved efficiency. One reason we may want this >>change is HTTP SASL. Discussion will continue on the list. >> >> > >How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" >document, and one document for the generic "GSS-*" mechanism set? If >the protocol for "GSS-*" will be different from the "GSSAPI" protocol, >perhaps it doesn't make sense to describe both in the same document. >It might also help focus on making the "GSS-*" protocol better, >without having to pay attention to Kerberos 5 specific issues. > This is pretty much what I've suggested. From owner-ietf-sasl Wed Aug 11 12:17:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH8d0079107; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BJH8GM079106; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH7Cu079100 for ; Wed, 11 Aug 2004 12:17:07 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D2CEB1602F7; Wed, 11 Aug 2004 15:17:07 -0400 (EDT) To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2222bis.txt Message-Id: <20040811191707.D2CEB1602F7@cz.mit.edu> Date: Wed, 11 Aug 2004 15:17:07 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2, the draft claims that the layer does not generally hide the details of mechanisms from protocols. I actually believe the statement we want to be making is that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. In particular, I consider it a requirement to be able to specify a SASL binding to a protocol without thinking about mechanism details. I believe this requirement is met by the base spec. However actually implementing this protocol spec for a particular mechanism requires the server and client to be aware of the mechanism details. I would not in general consider it acceptable for mechanism specifications to place requirements on protocol specifications. Besides this concern and some editorial issues I've sent to the editor, I have read this document and believe it is of high quality. As a chair however, I believe we still have not received sufficient review to publish the document. --Sam From owner-ietf-sasl Wed Aug 11 14:27:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRT6N092382; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLRTXh092381; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRSTI092373 for ; Wed, 11 Aug 2004 14:27:28 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 93ED5E003D; Wed, 11 Aug 2004 17:27:32 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis References: <20040807000913.GZ892@binky.central.sun.com> From: Sam Hartman Date: Wed, 11 Aug 2004 17:27:32 -0400 In-Reply-To: <20040807000913.GZ892@binky.central.sun.com> (Nicolas Williams's message of "Fri, 6 Aug 2004 19:09:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: I'm a bit uncomfortable saying that SASL mechanisms should support rekeying. I'm not sure that the community understands what this would mean well enough that mechanisms would converge on solutions with similar properties. Also, do we want to point out that for interop reasons SASL mechanisms may want to provide advisory notice that rekeying is necessary rather than invalidating security contexts. I'm particularly concerned about the transferring large file case. From owner-ietf-sasl Thu Aug 12 01:30:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C8U078098182; Thu, 12 Aug 2004 01:30:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C8U0Fj098181; Thu, 12 Aug 2004 01:30:00 -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.11/8.12.9) with ESMTP id i7C8U0kg098169 for ; Thu, 12 Aug 2004 01:30:00 -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 i7C8Tt0R016834 for ; Thu, 12 Aug 2004 01:29:55 -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 i7C8TtUT027964 for ; Thu, 12 Aug 2004 02:29:55 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C8RHfS007662; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C8RHdh007661; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Date: Thu, 12 Aug 2004 03:27:17 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis Message-ID: <20040812082717.GO892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040807000913.GZ892@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.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Aug 11, 2004 at 05:27:32PM -0400, Sam Hartman wrote: > > I'm a bit uncomfortable saying that SASL mechanisms should support > rekeying. I'm not sure that the community understands what this would > mean well enough that mechanisms would converge on solutions with > similar properties. Ok, how about this: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. > > Also, do we want to point out that for interop reasons SASL mechanisms > may want to provide advisory notice that rekeying is necessary rather > than invalidating security contexts. I'm particularly concerned about > the transferring large file case. I sympathize. I don't mind seeing text in rfc2222bis about advisory vs. mandatory security layer expiration. But I think that text about this that is specific to the GSS mechanisms seems well beyond the scope of rfc2222bis. Suggestions? Nico -- From owner-ietf-sasl Thu Aug 12 10:42:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHgXrr005758; Thu, 12 Aug 2004 10:42:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHgXhe005757; Thu, 12 Aug 2004 10:42:33 -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.11/8.12.9) with ESMTP id i7CHgWgo005748 for ; Thu, 12 Aug 2004 10:42:32 -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 (internal) with ESMTPA; Thu, 12 Aug 2004 18:46:33 +0100 Message-ID: <411BAC01.7040407@isode.com> Date: Thu, 12 Aug 2004 18:42:25 +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: DIGEST-MD5 interop issue 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: Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as "username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): >realm > >The realm containing the user's account, encoded according to the >value of the "charset" directive. This directive is required >if the server provided any realms in the "digest-challenge", in which case it >may appear exactly once and its value SHOULD be one of those realms. If the >directive is missing, "realm-value" will set to the empty string when >computing A1 (see below for details). So, the client has violated SHOULD and the server is treating SHOULD as MUST. So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. I have a reason to believe that the client is using a library implementing DIGEST-MD5, which is widely deployed. Alexey From owner-ietf-sasl Thu Aug 12 12:15:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFUeT017060; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJFULP017059; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SEVENTY-SIX.MIT.EDU [18.187.6.221]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFTWw017053 for ; Thu, 12 Aug 2004 12:15:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 627641602F9; Thu, 12 Aug 2004 15:15:37 -0400 (EDT) To: ietf-sasl@imc.org Subject: rfc2222bis: confidentiality and integrity Message-Id: <20040812191537.627641602F9@cz.mit.edu> Date: Thu, 12 Aug 2004 15:15:37 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. There's another change I thought would be editorial but apparently is not. The document currently says in section 1 that confidentiality protection usually implies integrity protection. This seems less than ideal from a security standpoint. I believe that applications need to be able to depend on the fact that confidentiality protection comes along with integrity protection. I propose to drop the word usually. From owner-ietf-sasl Thu Aug 12 17:44:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0imt5053291; Thu, 12 Aug 2004 17:44:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0im52053290; Thu, 12 Aug 2004 17:44:48 -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.11/8.12.9) with ESMTP id i7D0imac053281 for ; Thu, 12 Aug 2004 17:44:48 -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 i7D0inJ6008666 for ; Thu, 12 Aug 2004 17:44:49 -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 i7D0imUT019792 for ; Thu, 12 Aug 2004 18:44:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0gALO018314; Thu, 12 Aug 2004 19:42:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0g93e018313; Thu, 12 Aug 2004 19:42:09 -0500 (CDT) Date: Thu, 12 Aug 2004 19:42:09 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity Message-ID: <20040813004209.GI892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040812191537.627641602F9@cz.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 12, 2004 at 03:15:37PM -0400, Sam Hartman wrote: > > > Hi. There's another change I thought would be editorial but > apparently is not. The document currently says in section 1 that > confidentiality protection usually implies integrity protection. > > This seems less than ideal from a security standpoint. I believe that > applications need to be able to depend on the fact that > confidentiality protection comes along with integrity protection. If there are any mechanisms that provide confidentiality protection without providing integrity protection then I propose: a) that rfc2222bis identify such mechanisms, b) say new mechs MUST NOT do such Bad Things. > I propose to drop the word usually. Yes. Nico -- From owner-ietf-sasl Thu Aug 12 17:49:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0npBt053683; Thu, 12 Aug 2004 17:49:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0npT5053682; Thu, 12 Aug 2004 17:49: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-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0nplN053675 for ; Thu, 12 Aug 2004 17:49:51 -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 i7D0nqJ6010211 for ; Thu, 12 Aug 2004 17:49:52 -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 i7D0npUT021379 for ; Thu, 12 Aug 2004 18:49:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0lDXP018321 for ; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0lDFv018320 for ietf-sasl@imc.org; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Date: Thu, 12 Aug 2004 19:47:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Does rfc2222bis need text on channel bindings? Message-ID: <20040813004713.GJ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I figure the new SASL GSS mech document will say something about channel bindings, but perhaps rfc2222bis should also. Specifically I think that rfc2222bis could use: a) Security Considerations text about use of mechanisms that don't support channel bindings in conjunction with TLS. Clients should be admonished to validate TLS server IDs to prevent MITM attacks when using SASL-over-TLS. Similarly with other variants of SASL-over-TLS. SACRED is an example of an application where such text could be useful. b) Text recommending support for channel bindings in future mechanisms, where possible. Digest-MD5, for example, could easily support channel bindings. Comments? Shall I just send proposed text to the list? Nico -- From owner-ietf-sasl Thu Aug 12 19:14:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2Ehe9061126; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D2Ehdf061125; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-5.MIT.EDU [18.101.1.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2EgfO061117 for ; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id BAF13E0036; Thu, 12 Aug 2004 22:14:51 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity References: <20040812191537.627641602F9@cz.mit.edu> <20040813004209.GI892@binky.central.sun.com> From: Sam Hartman Date: Thu, 12 Aug 2004 22:14:51 -0400 In-Reply-To: <20040813004209.GI892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:42:09 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> If there are any mechanisms that provide confidentiality Nicolas> protection without providing integrity protection then I Nicolas> propose: a) that rfc2222bis identify such mechanisms, b) Nicolas> say new mechs MUST NOT do such Bad Things. I know of no such mechanisms. From owner-ietf-sasl Fri Aug 13 03:21:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALBSH028402; Fri, 13 Aug 2004 03:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALBcn028401; Fri, 13 Aug 2004 03:21:11 -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.11/8.12.9) with ESMTP id i7DAL9rM028377 for ; Fri, 13 Aug 2004 03:21:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN0014781; Fri, 13 Aug 2004 10:21:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:32:05 +0200 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: DIGEST-MD5 interop issue Cc: SASL WG In-Reply-To: <411BAC01.7040407@isode.com> References: <411BAC01.7040407@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 07:42 PM 8/12/2004, Alexey Melnikov wrote: >Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: > >While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. >I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as >"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). > >At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): > >>realm >>The realm containing the user's account, encoded according to the value of the "charset" directive. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and its value SHOULD be one of those realms. If the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details). > > >So, the client has violated SHOULD and the server is treating SHOULD as MUST. No, the server is treating the client provided realm as invalid and hence the exchange fails. The server behavior is proper. >So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. > >There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, This is real issue. >instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. Exactly, the client is making assumptions which prevent users from being able to use it with independently developed servers. A client which cannot handle the full range of identity and realm values is simply broken. For instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in the realm project@OPENLDAP.ORG. I would not be able to use this or like clients. Kurt From owner-ietf-sasl Fri Aug 13 03:21:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALHvb028425; Fri, 13 Aug 2004 03:21:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALHWb028424; Fri, 13 Aug 2004 03:21:17 -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.11/8.12.9) with ESMTP id i7DALGMF028418 for ; Fri, 13 Aug 2004 03:21:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN2014781 for ; Fri, 13 Aug 2004 10:21:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:34:04 +0200 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: 2222bis: identities and authorization 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 have completed my review of draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor editorial comments (which I have separately sent to the Editor). This note discussions problems I found related to identities and authorization. The 'Authorization and authentication identities' section (3.2) starts off by stating that 'SASL authentication deals with two identities' but then describes the processing model to involve three identities, two of which it simply refers to as 'authorization' identities. I believe we either need better distinguish these identities within the document, by through qualification (proxy authorization identity v. application authorization identity) or by use of replacement terminology (proxied identity v. authorization identity). I prefer the latter approach as the former qualifications are themselves a bit confused and the latter seems more in step with RFC 2828. I am willing to prepare replacement text for consideration. Kurt From owner-ietf-sasl Fri Aug 13 03:27:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DARuZp030020; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DARuBh030019; Fri, 13 Aug 2004 03:27:56 -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.11/8.12.9) with ESMTP id i7DARu9n030009 for ; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DARpMw014819; Fri, 13 Aug 2004 10:27:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813122737.085d65d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 12:28:27 +0200 To: hartmans@mit.edu (Sam Hartman) From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: confidentiality and integrity Cc: ietf-sasl@imc.org In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> References: <20040812191537.627641602F9@cz.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: I support this suggestion. The subsequent sentence is sufficent to suggest other kinds (including poorly designed :-) layers may be supported. At 09:15 PM 8/12/2004, Sam Hartman wrote: >Hi. There's another change I thought would be editorial but >apparently is not. The document currently says in section 1 that >confidentiality protection usually implies integrity protection. > >This seems less than ideal from a security standpoint. I believe that >applications need to be able to depend on the fact that >confidentiality protection comes along with integrity protection. > >I propose to drop the word usually. From owner-ietf-sasl Fri Aug 13 07:52:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DEqArs017759; Fri, 13 Aug 2004 07:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DEqA5r017758; Fri, 13 Aug 2004 07:52:10 -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.11/8.12.9) with SMTP id i7DEq9pO017732 for ; Fri, 13 Aug 2004 07:52:09 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30845; 13 Aug 2004 10:51 EDT Date: Fri, 13 Aug 2004 10:51:31 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: SASL WG Subject: Re: DIGEST-MD5 interop issue Message-ID: <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@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 Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" wrote: >> So, the client has violated SHOULD and the server is treating SHOULD as >> MUST. > > No, the server is treating the client provided realm as invalid and hence > the exchange fails. The server behavior is proper. Put another way... The server is not rejecting the exchange because it thinks the client has violated the protocol. It's doing so based on policy -- the client provided a name in bar.example.com, and the server is only willing to deal with clients in test.example.com. The reason for the SHOULD is that the server has indicated which realms it is willing/able to accept, and it's expected that the server will usually reject any other realms. From owner-ietf-sasl Fri Aug 13 08:15:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFFKjk025988; Fri, 13 Aug 2004 08:15:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFFKt2025987; Fri, 13 Aug 2004 08:15:20 -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.11/8.12.9) with ESMTP id i7DFFJiI025981 for ; Fri, 13 Aug 2004 08:15: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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:19:10 +0100 Message-ID: <411CDAF2.4070804@isode.com> Date: Fri, 13 Aug 2004 16:14:58 +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 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.edu> MIME-version: 1.0 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: > On Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" > wrote: > >>> So, the client has violated SHOULD and the server is treating SHOULD as >>> MUST. >> >> No, the server is treating the client provided realm as invalid and >> hence >> the exchange fails. The server behavior is proper. > > Put another way... > > The server is not rejecting the exchange because it thinks the client > has violated the protocol. It's doing so based on policy -- the > client provided a name in bar.example.com, and the server is only > willing to deal with clients in test.example.com. This make sense. But in case of CMU SASL the realm value doesn't matter, it is only used for constructing the authentication verifier. Alexey From owner-ietf-sasl Fri Aug 13 08:12:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFCwc8025731; Fri, 13 Aug 2004 08:12:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFCwc2025730; Fri, 13 Aug 2004 08:12:58 -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.11/8.12.9) with ESMTP id i7DFCubb025717 for ; Fri, 13 Aug 2004 08:12:57 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:16:45 +0100 Message-ID: <411CDA64.6080408@isode.com> Date: Fri, 13 Aug 2004 16:12: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: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.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: Jeffrey Hutzelman wrote: > The reason for the SHOULD is that the server has indicated which > realms it is willing/able to accept, and it's expected that the server > will usually reject any other realms. One problem with the DIGEST-MD5 spec I can see is that there is no way for the server to tell whether it only accepts certain realms or whether it will accept any realms. There are servers that implement either policy. Servers that implement the latter policy can accept authentication for any realm and will try to proxy authenticate if possible. Alexey From owner-ietf-sasl Fri Aug 13 08:52:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFqkhk030227; Fri, 13 Aug 2004 08:52:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFqkdi030226; Fri, 13 Aug 2004 08:52:46 -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.11/8.12.9) with ESMTP id i7DFqjpO030219 for ; Fri, 13 Aug 2004 08:52:46 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:56:55 +0100 Message-ID: <411CE3CE.1000905@isode.com> Date: Fri, 13 Aug 2004 16:52:46 +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: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> In-Reply-To: <20040813004713.GJ892@binky.central.sun.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: Nicolas Williams wrote: >I figure the new SASL GSS mech document will say something about channel >bindings, but perhaps rfc2222bis should also. > >Specifically I think that rfc2222bis could use: > >a) Security Considerations text about use of mechanisms that don't > support channel bindings in conjunction with TLS. > > Clients should be admonished to validate TLS server IDs to prevent > MITM attacks when using SASL-over-TLS. Similarly with other variants > of SASL-over-TLS. > I suspect you mean "SASL-over-". > SACRED is an example of an application where such text could be > useful. > >b) Text recommending support for channel bindings in future mechanisms, > where possible. Digest-MD5, for example, could easily support > channel bindings. > If you mean that it can be easily extended, then I agree. >Comments? Shall I just send proposed text to the list? > Please do. Alexey From owner-ietf-sasl Fri Aug 13 09:57:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvE3Q036998; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGvEu2036997; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvDc5036899 for ; Fri, 13 Aug 2004 09:57:13 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 09:57:13 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:56:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:57:08 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 09:56:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 09:57:32 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBIQCJAp+5L9SWQf2IEz1lwX0AyQANRB4w From: "Paul Leach" To: "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 16:56:21.0608 (UTC) FILETIME=[75C2AE80:01C48156] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DGvDc5036965 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 Kurt D. Zeilenga > Sent: Friday, August 13, 2004 12:32 AM > To: Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Exactly, the client is making assumptions which prevent users from being > able to use it with independently developed servers. A client which > cannot > handle the full range of identity and realm values is simply broken. For > instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in > the realm project@OPENLDAP.ORG. I would not be able to use this or like > clients. [Paul Leach] Use of names and realms of this form was not the intention when the protocol was spec'd. The idea was that realms would be DNS names. You can legitimately gripe that the spec does not make this intention clear. Or that the client in question doesn't make clear its rules for transforming what the user types into what gets sent on the wire. Or both. From owner-ietf-sasl Fri Aug 13 10:04:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4x70038706; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DH4xhV038705; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4wC3038696 for ; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 10:04:58 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:57 -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); Fri, 13 Aug 2004 10:04:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 10:05:21 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7840BC@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBRzVqtmM1ELj0QeCvRNk/Qj702gAEDIDw From: "Paul Leach" To: "Jeffrey Hutzelman" , "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 17:04:08.0451 (UTC) FILETIME=[8C054530:01C48157] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DH4xC3038700 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 Jeffrey Hutzelman > Sent: Friday, August 13, 2004 7:52 AM > To: Kurt D. Zeilenga; Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > The reason for the SHOULD is that the server has indicated which realms it > is willing/able to accept, and it's expected that the server will usually > reject any other realms. [Paul Leach] The server may also accept names in the realm "fbi.gov", but may not want to advertise that fact. Clients that have out of band knowledge about the realms supported may attempt to authenticate using one of those realms. Hence it is not "expected" that another realm will fail. The inverse: it can not be expected that it will succeed without OOB info. From owner-ietf-sasl Fri Aug 13 10:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEJUC039813; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHEJfY039812; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEITp039805 for ; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D4338E0036; Fri, 13 Aug 2004 13:14:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> From: Sam Hartman Date: Fri, 13 Aug 2004 13:14:25 -0400 In-Reply-To: <20040813004713.GJ892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:47:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I figure the new SASL GSS mech document will say Nicolas> something about channel bindings, but perhaps rfc2222bis Nicolas> should also. I do hope the new GSSAPI draft discusses this issue. Nicolas> Specifically I think that rfc2222bis could use: Nicolas> a) Security Considerations text about use of mechanisms Nicolas> that don't support channel bindings in conjunction with Nicolas> TLS. This seems problematic given that all current mechanisms don't support channel bindings. I think the best we could do is security considerations text describing the multiple layers problem. Nicolas> Clients should be admonished to validate TLS server Nicolas> IDs to prevent MITM attacks when using SASL-over-TLS. Nicolas> Similarly with other variants of SASL-over-TLS. Agreed. Nicolas> b) Text recommending support for channel bindings in Nicolas> future mechanisms, where possible. Digest-MD5, for Nicolas> example, could easily support channel bindings. This sounds out of scope for the SASL working group. I believe our charter prohibits us from adding new features to SASL. I don't think it has similar prohibitions for the GSSAPI mechanism. I agree channel bindings are a good thing for SASL. I disagree that they are well specified enough for us to be adding text about them to the base sasl document for this revision. From owner-ietf-sasl Fri Aug 13 10:17:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH3KW040135; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHH3Hf040134; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH35F040125 for ; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 312331783C9; Fri, 13 Aug 2004 13:17:09 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> From: Sam Hartman Date: Fri, 13 Aug 2004 13:17:09 -0400 In-Reply-To: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 13 Aug 2004 09:34:04 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 have completed my review of Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor Kurt> editorial comments (which I have separately sent to the Kurt> Editor). This note discussions problems I found related to Kurt> identities and authorization. Kurt> The 'Authorization and authentication identities' section Kurt> (3.2) starts off by stating that 'SASL authentication deals Kurt> with two identities' but then describes the processing model Kurt> to involve three identities, two of which it simply refers Kurt> to as 'authorization' identities. I believe we either need Kurt> better distinguish these identities within the document, by Kurt> through qualification (proxy authorization identity Kurt> v. application authorization identity) or by use of Kurt> replacement terminology (proxied identity v. authorization Kurt> identity). I prefer the latter approach as the former Kurt> qualifications are themselves a bit confused and the latter Kurt> seems more in step with RFC 2828. Would you mind explaining the problem you had with this section in better detail? I thought it flowed fairly well and is a significant improvement on our previous attempts to describe this issue. However I might well miss problems because as someone who has been following SASL I'm familiar with the issue. I am not always good at reading a document as someone new to a technology. --Sam From owner-ietf-sasl Fri Aug 13 10:36:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHaIti042332; Fri, 13 Aug 2004 10:36:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHaIYY042331; Fri, 13 Aug 2004 10:36:18 -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.11/8.12.9) with ESMTP id i7DHaHjF042325 for ; Fri, 13 Aug 2004 10:36:17 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:40:21 +0100 Message-ID: <411CFC0A.3070405@isode.com> Date: Fri, 13 Aug 2004 18:36:10 +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: Paul Leach CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>-----Original Message----- >>From: owner-ietf-sasl@mail.imc.org >> >> >>On Behalf Of Kurt D. Zeilenga >>Sent: Friday, August 13, 2004 12:32 AM >>To: Alexey Melnikov >>Cc: SASL WG >>Subject: Re: DIGEST-MD5 interop issue >> >>Exactly, the client is making assumptions which prevent users from being >> >> >>able to use it with independently developed servers. A client which >>cannot >>handle the full range of identity and realm values is simply broken. For >> >> >>instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in >> >> >>the realm project@OPENLDAP.ORG. I would not be able to use this or like >> >> >>clients. >> >> > >[Paul Leach] Use of names and realms of this form was not the intention >when the protocol was spec'd. The idea was that realms would be DNS >names. > Although the former might be true, the latter is not, as RFC 2831 has the following example of a realm: registered_users@gotham.news.example.com. >You can legitimately gripe that the spec does not make this intention >clear. > Indeed. Text about realms has caused problems before, because it is so vague. > Or that the client in question doesn't make clear its rules for >transforming what the user types into what gets sent on the wire. Or >both. > > Yes (both). Alexey From owner-ietf-sasl Fri Aug 13 10:44:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHi9po043087; Fri, 13 Aug 2004 10:44:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHi98P043086; Fri, 13 Aug 2004 10:44: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.11/8.12.9) with ESMTP id i7DHi7H8043075 for ; Fri, 13 Aug 2004 10:44: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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:48:15 +0100 Message-ID: <411CFDE3.4030702@isode.com> Date: Fri, 13 Aug 2004 18:44:03 +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: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> In-Reply-To: <411BAC01.7040407@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: Alexey Melnikov wrote: > There is another issue here: the client has split > "foo@bar.example.com" into username and realm parts, instead of > sending the value as is in the username option. The same client was > also treating a username "BAR\foo" as username=foo and realm=BAR. To complete my description: the client is transforming entered username "foo" into username="foo", realm="" > Arguably this is UI issue, but the client is still broken, because the > client makes assumptions about how username should look like and there > is no easy way to enter username as expected by the server. From owner-ietf-sasl Fri Aug 13 11:02:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2QBs045044; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DI2Q14045043; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2PlQ045026 for ; Fri, 13 Aug 2004 11:02:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 11:01:22 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 11:01:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 11:02:24 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBXBWqGsSCY03uQeit5LDe2JnrQwAAqO2w From: "Paul Leach" To: "Alexey Melnikov" Cc: "Kurt D. Zeilenga" , "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 18:01:39.0802 (UTC) FILETIME=[952FA3A0:01C4815F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DI2PlQ045036 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Friday, August 13, 2004 10:36 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Paul Leach wrote: > > > > >[Paul Leach] Use of names and realms of this form was not > the intention > >when the protocol was spec'd. The idea was that realms would be DNS > >names. > > > Although the former might be true, the latter is not, as RFC > 2831 has the following example of a realm: > registered_users@gotham.news.example.com. > I sure don't recall that example.... I can only speak for my intentions as I remember them. The MSFT UI usually has two modes: one where there are two edit boxes for entering name and realm (respectively); and one with one edit box where special characters are understood as separating them. An update could suggest some scheme such as this. Or it could merely state a requirement on UIs that arbitrary user names and realm names have to be able to be entered, and that if they want to use special characters to separate them, then they have to be able to escape the special characters (and that they need to specify their escape rules). From owner-ietf-sasl Sat Aug 14 10:54:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EHshMf053757; Sat, 14 Aug 2004 10:54:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EHshFb053756; Sat, 14 Aug 2004 10:54:43 -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.11/8.12.9) with ESMTP id i7EHsf6Y053749 for ; Sat, 14 Aug 2004 10:54:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt101.lnd4.gbr.da.uu.net [213.116.50.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 14 Aug 2004 18:58:45 +0100 Message-ID: <411E51A3.9070705@isode.com> Date: Sat, 14 Aug 2004 18:53:39 +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: Paul Leach CC: SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>Paul Leach wrote: >> >> >>>[Paul Leach] Use of names and realms of this form was not the intention >>> >>> >>>when the protocol was spec'd. The idea was that realms would be DNS >>>names. >>> >>> >>Although the former might be true, the latter is not, as RFC >>2831 has the following example of a realm: >>registered_users@gotham.news.example.com. >> >> >I sure don't recall that example.... I can only speak for my intentions >as I remember them. > >The MSFT UI usually has two modes: one where there are two edit boxes >for entering name and realm (respectively); and one with one edit box >where special characters are understood as separating them. > >An update could suggest some scheme such as this. Or it could merely >state a requirement on UIs that arbitrary user names and realm names >have to be able to be entered, and that if they want to use special >characters to separate them, then they have to be able to escape the >special characters (and that they need to specify their escape rules). > I like that. Speaking of UI: the UI should also be able to display all realms advertised by the server (otherwise what is the point of advertising them anyway?), e.g. a listbox with advertised realms, but so that the client can type in a different realm. From owner-ietf-sasl Sat Aug 14 23:32:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F6Wcrs013726; Sat, 14 Aug 2004 23:32:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F6Wc0N013725; Sat, 14 Aug 2004 23:32:38 -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.11/8.12.9) with ESMTP id i7F6Wb51013700 for ; Sat, 14 Aug 2004 23:32:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7F6WUMw025334; Sun, 15 Aug 2004 06:32:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 15 Aug 2004 07:13:04 +0200 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20040813082412.081cbe20@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 07:17 PM 8/13/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> I have completed my review of > Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor > Kurt> editorial comments (which I have separately sent to the > Kurt> Editor). This note discussions problems I found related to > Kurt> identities and authorization. > > Kurt> The 'Authorization and authentication identities' section > Kurt> (3.2) starts off by stating that 'SASL authentication deals > Kurt> with two identities' but then describes the processing model > Kurt> to involve three identities, two of which it simply refers > Kurt> to as 'authorization' identities. I believe we either need > Kurt> better distinguish these identities within the document, by > Kurt> through qualification (proxy authorization identity > Kurt> v. application authorization identity) or by use of > Kurt> replacement terminology (proxied identity v. authorization > Kurt> identity). I prefer the latter approach as the former > Kurt> qualifications are themselves a bit confused and the latter > Kurt> seems more in step with RFC 2828. > > >Would you mind explaining the problem you had with this section in >better detail? I thought it flowed fairly well and is a significant >improvement on our previous attempts to describe this issue. However >I might well miss problems because as someone who has been following >SASL I'm familiar with the issue. I am not always good at reading a >document as someone new to a technology. Sure. The following 3.2 text: > The processing model is as follows. A server, upon completion of the > authentication mechanism, uses the results produced by the > authentication mechanism, the client-provided authorization identity > value (which may be the empty string), and local policy information > to derive an authorization identity. clearly shows the document is using the term 'authorization identity' to refer, at times, to the client-provided authorization identity and, at times, to a derived authorization identity. However, in other portions of the document, the term 'authorization identity' is mostly used unqualified. While qualification of the term would likely resolve this issue, that solution would likely be cumbersome. As the 'authorization identity' more properly refers to the identity directly used in authorization, it seems more appropriate to call the value referred to here as the 'client-provided authorization identity' as the 'proxied identity'. While I am working on a more complete replacement text, here is glimpse of the suggested clarification: Conceptually, the SASL framework deals with three identities: - the authentication identity, - the proxied identity, and - the authorization identity. The authentication identity is derived from client's authentication credentials. The proxied identity is optionally provided by the client seeking to assume the identity of another user (or entity). The authorization identity is the server-produced primary identity used for making access control and other policy decisions. These identities are managed as follows: The server uses the authentication identity established through the authentication exchange, the proxied identity (if provided), and possibly other information to produce the authorization identity. I've been trying to come with a new term to call the derived identity to allow us unambiguously use the term 'authorization identity' to refer to the client provided value, as the WG seems to have some attachment to this usage. The best I have come with here is 'subject identity' (the identity which is the subject in access control decisions). I do not recommend this approach myself as I believe it would be more proper to use the term 'authorization identity' to refer to the subject of access control decisions. However, I am far more concerned about ambiguous use of the term (using the term to refer to two different values) than I am about which of the two uses continues to this term. That is, I can live with calling the client provided value an 'authorization identity' if we don't also use that term to refer to the derived identity. Kurt From owner-ietf-sasl Wed Aug 18 11:43:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhdGE014932; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIhdPf014931; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhcsh014906 for ; Wed, 18 Aug 2004 11:43:38 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7IIhbUF014448 for ; Wed, 18 Aug 2004 14:43:37 -0400 Received: from [135.91.110.75] (thansen-n.mt.att.com[135.91.110.75](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818184354gw1002evofe> (Authid: tony); Wed, 18 Aug 2004 18:43:54 +0000 Message-ID: <4123A355.5000209@att.com> Date: Wed, 18 Aug 2004 14:43:33 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: md5 definitely broken? 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 saw a note in the openpgp mailing list about md5 definitely being cracked. Anyone know more? Tony Hansen tony@att.com From owner-ietf-sasl Wed Aug 18 12:01:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1mgk017793; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJ1mEx017792; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1iQR017772 for ; Wed, 18 Aug 2004 12:01:44 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BxVgt-0005Ps-00 for ; Wed, 18 Aug 2004 21:01:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: md5 definitely broken? Date: Wed, 18 Aug 2004 21:01:36 +0200 Lines: 16 Message-ID: References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:owG6sPrHdscmMpa7vt+m9PbTcO8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen writes: > I saw a note in the openpgp mailing list about md5 definitely being > cracked. Anyone know more? "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199/ Whether "collisions" imply "cracked", in the real world, probably depend on the details, and the application. It is not clear (to me, at least) how you would attack HMAC-MD5 based on the above result. (FWIW, I've verified all but the RIPEMD-128 collisions in the paper.) Regards, Simon From owner-ietf-sasl Wed Aug 18 12:15:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJFj9J020794; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJFjkX020793; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJFide020776 for ; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 23832 invoked by uid 0); 18 Aug 2004 19:15:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.240.240) by woodstock.binhost.com with SMTP; 18 Aug 2004 19:15:45 -0000 Message-Id: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 18 Aug 2004 15:16:28 -0400 To: Tony Hansen , ietf-sasl From: Russ Housley Subject: Re: md5 definitely broken? In-Reply-To: <4123A355.5000209@att.com> References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony: Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and three other hash functions. You can get it from: http://eprint.iacr.org/2004/199.pdf It does not provide the attacks, but it does allow one to confirm the discovery of collisions. The ramification of this news is pretty clear for digital signatures that make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 and HTTP Digest. Anything that has already been signed with MD5 is definitely safe. If one stops using MD5 today, nothing that has already been signed is at risk. However, it is getting risky to sign certificates with MD5, in my opinion. Russ At 02:43 PM 8/18/2004, Tony Hansen wrote: >I saw a note in the openpgp mailing list about md5 definitely being >cracked. Anyone know more? > > Tony Hansen > tony@att.com > From owner-ietf-sasl Wed Aug 18 13:06:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WWg029579; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IK6W4i029578; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WUw029556 for ; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from lgl@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6S1i024246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2004 13:06:29 -0700 (PDT) Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.212]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6PO2001831; Wed, 18 Aug 2004 13:06:26 -0700 (PDT) Message-Id: <6.0.0.10.2.20040818130258.047981d0@qcmail1.qualcomm.com> X-Sender: llundbla@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.10 (Beta) Date: Wed, 18 Aug 2004 13:06:24 -0700 To: Russ Housley , Tony Hansen , ietf-sasl From: Laurence Lundblade Subject: Re: md5 definitely broken? In-Reply-To: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> References: <4123A355.5000209@att.com> <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:16 PM 8/18/2004, Russ Housley wrote: >Tony: > >Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, >MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and >three other hash functions. You can get it from: > > http://eprint.iacr.org/2004/199.pdf > >It does not provide the attacks, but it does allow one to confirm the >discovery of collisions. > >The ramification of this news is pretty clear for digital signatures that >make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 >and HTTP Digest. > >Anything that has already been signed with MD5 is definitely safe. If one >stops using MD5 today, nothing that has already been signed is at risk. Except if you determine when something was signed by a signed timed stamp from time stamp authority that used MD5. You can't distinguish what was signed in the past from something that was made to look like it was signed in the past if you're using signed time stamps with MD5. You're OK if you have some *other* strong way to determine when it was signed. LL From owner-ietf-sasl Wed Aug 18 14:59:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxiI4048024; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILxiEe048023; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxema048012 for ; Wed, 18 Aug 2004 14:59:42 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id BAC1997 for ; Wed, 18 Aug 2004 15:59:43 -0600 (MDT) Message-ID: <4123D15A.4060509@computerking.ca> Date: Wed, 18 Aug 2004 15:59:54 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: plain and login not working 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: This is a thread i started in postfix users but think it would be on topic at this group too. The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. EHLO computerking.ca 250-mail1.computerking.ca 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-XVERP 250 8BITMIME > * RYAN vAN GINNEKEN [040818 01:49]: > > >> I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >> stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >> configured the my /user/local/lib/sasl2 dir to contain only >> Sendmail.conf liblogin.so libplain.a libplain.so.2 >> liblogin.a liblogin.so.2 libplain.so smptd.conf >> > > > OK. > > > >> and my smtpd.conf file has this configuration >> >> # This sets smtpd to authenticate using the saslauthd daemon. >> pwcheck_method:saslauthd >> # This allows only plain and login as the authentication mechanisms. >> mech_list: plain login >> > > > OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. > One never knows with SASL ... > > > I added a space stopped and started saslauthd using this command /usr/local/etc/rc.d/saslauthd.sh start /usr/local/etc/rc.d/saslauthd.sh start then stopped and started postfix using postfix stop postfix start still get the errors Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >> Seems simple enough however when i try to logon to my SMTP server i >> get the following errors. >> Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL PLAIN authentication failed >> Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL LOGIN authentication failed >> > > > OK. > > > >> Is there a log i can check for sasl errors somewhere or do i need to >> > > > SASL logs to auth.*, check your syslog configuration if it catches this. > > > I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow >> change my permissions on the passwd file any help would be >> appreciated. > > > Which passwd file? You have configured Postfix for client-side as well > as fpr server-side SMTP AUTH. Client-side introduces > /etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we > talking about /etc/passwd. If you mean /etc/passwd then you don't need > to change permissions. saslauthd is run started by root:root, so > permissions should be no problem. > > > Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. >> Here is a posconf -n output if that helps anyone help me thank you in >> advance. >> >> v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> broken_sasl_auth_clients = yes >> > > > OK. > > > >> command_directory = /usr/local/sbin >> config_directory = /usr/local/etc/postfix >> daemon_directory = /usr/local/libexec/postfix >> debug_peer_level = 2 >> home_mailbox = IMAPdir/INBOX/ >> inet_interfaces = all >> mail_owner = postfix >> mailq_path = /usr/local/bin/mailq >> manpage_directory = /usr/local/man >> mydestination = $myhostname, localhost.$mydomain $mydomain >> mydomain = computerking.ca >> myhostname = mail1.computerking.ca >> mynetworks_style = subnet >> myorigin = $mydomain >> newaliases_path = /usr/local/bin/newaliases >> queue_directory = /var/spool/postfix >> readme_directory = no >> relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >> sample_directory = /usr/local/etc/postfix >> sendmail_path = /usr/local/sbin/sendmail >> setgid_group = maildrop >> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >> > > > If you want to offer server-side SMTP AUTH, you don't need > smtp_sasl_password_maps; they are for the smtp daemon (client-side) > > > What ??? i will comment out this feature for now do not quite understand what this is used for >> smtp_tls_loglevel = 2 >> smtp_tls_note_starttls_offer = yes >> smtp_use_tls = yes >> smtpd_recipient_restrictions = permit_mx_backup > > > Turn off smtp_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> smtpd_sasl_auth_enable = yes >> > > > OK. > > > >> smtpd_sasl_local_domain = >> > > > OK. > > > >> smtpd_sasl_security_options = noanonymous >> > > > OK. > > > >> smtpd_sender_restrictions = permit_mx_backup >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> > > > OK. > > > >> smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >> smtpd_tls_auth_only = yes >> smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >> smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >> smtpd_tls_loglevel = 2 >> smtpd_tls_received_header = yes >> smtpd_tls_session_cache_timeout = 3600s >> smtpd_use_tls = yes >> > > > Turn off smtpd_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] >> soft_bounce = no >> tls_random_source = dev:/dev/urandom >> unknown_local_recipient_reject_code = 450 >> virtual_alias_domains = sculpturaldesign.ca >> virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >> > > > So far so good... > > How do you run saslauthd? > > using the saslauthd script in the rc.d dir /usr/local/etc/rc.d/saslauthd.sh start > Where does saslauthd put its socket? > > not sure how do i find out??? > What does 'saslauthd -a shadow -d' give as ouput? > > v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login yikes that seems like it might be a problem > Look for run_path. > what?? > Can postfix access this $run_path directory? > > what?? > What do you use as authentication backend i.e. the source of your > usernames and passwords? > > I what to use /etc/passwd > Can you authenticate without Postfix using 'testsaslauthd'? > > v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd su: testsaslauthd: command not found I also did a locate testsaslauthd and it did not find anything > p@rick > > > > From owner-ietf-sasl Wed Aug 18 15:10:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAJYj049591; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IMAJWh049590; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAGvU049569 for ; Wed, 18 Aug 2004 15:10:16 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 18 Aug 2004 15:10:54 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:04 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 18 Aug 2004 15:09:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: md5 definitely broken? Date: Wed, 18 Aug 2004 15:10:07 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: md5 definitely broken? thread-index: AcSFV9LqW81pSYYhQ72w4YiFay2arAAFrPMQ From: "Paul Leach" To: "Simon Josefsson" , X-OriginalArrivalTime: 18 Aug 2004 22:09:17.0750 (UTC) FILETIME=[01475560:01C48570] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IMAGvU049583 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 Simon Josefsson > Sent: Wednesday, August 18, 2004 12:02 PM > To: ietf-sasl@imc.org > Subject: Re: md5 definitely broken? > > > Tony Hansen writes: > > > I saw a note in the openpgp mailing list about md5 definitely being > > cracked. Anyone know more? > > "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" > http://eprint.iacr.org/2004/199/ > > Whether "collisions" imply "cracked", in the real world, > probably depend on the details, and the application. It is > not clear (to me, at least) how you would attack HMAC-MD5 > based on the above result. I've see mail from Hugo Krawczyk that says it does not place HMACs in jeopardy. Also, AFAIK, it has not been claimed that, given some arbitrary text, an attacker can find other text that hashes to the same value. However, at the current time, the existence of these collisions strongly implies that that is possible, and one must assume that in the not to distant future it will be done. Hence, it would be the conservative thing to do to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher suite. From owner-ietf-sasl Wed Aug 18 16:15:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFPRA060070; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INFP0A060069; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFORU060055 for ; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7INFOfb001739 for ; Wed, 18 Aug 2004 18:15:24 -0500 Received: from [135.210.8.81] (unknown[135.210.8.81](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818231541gw1002f0ioe> (Authid: tony); Wed, 18 Aug 2004 23:15:41 +0000 Message-ID: <4123E30B.7060908@att.com> Date: Wed, 18 Aug 2004 19:15:23 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: md5 definitely broken? References: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Which is why I brought it up on ietf-sasl. Should we be busy defining DIGEST-SHA256 and not DIGEST-MD5? Tony Hansen tony@att.com Paul Leach wrote: >>Tony Hansen writes: >> >>>I saw a note in the openpgp mailing list about md5 definitely being >>>cracked. Anyone know more? >> >>"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" >>http://eprint.iacr.org/2004/199/ >> >>Whether "collisions" imply "cracked", in the real world, >>probably depend on the details, and the application. It is >>not clear (to me, at least) how you would attack HMAC-MD5 >>based on the above result. > > I've see mail from Hugo Krawczyk that says it does not place HMACs in > jeopardy. > > Also, AFAIK, it has not been claimed that, given some arbitrary text, an > attacker can find other text that hashes to the same value. However, at > the current time, the existence of these collisions strongly implies > that that is possible, and one must assume that in the not to distant > future it will be done. Hence, it would be the conservative thing to do > to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher > suite. From owner-ietf-sasl Wed Aug 18 22:46:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J5kZ39018844; Wed, 18 Aug 2004 22:46:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J5kZiO018841; Wed, 18 Aug 2004 22:46: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.11/8.12.9) with ESMTP id i7J5kYIu018824 for ; Wed, 18 Aug 2004 22:46:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7J5kHMw053507; Thu, 19 Aug 2004 05:46:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040819074135.040bd4e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 19 Aug 2004 07:46:53 +0200 To: RYAN vAN GINNEKEN From: "Kurt D. Zeilenga" Subject: Re: plain and login not working Cc: ietf-sasl In-Reply-To: <4123D15A.4060509@computerking.ca> References: <4123D15A.4060509@computerking.ca> 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:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME > >>* RYAN vAN GINNEKEN [040818 01:49]: >> >> >>>I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >>>stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >>>configured the my /user/local/lib/sasl2 dir to contain only >>>Sendmail.conf liblogin.so libplain.a libplain.so.2 >>>liblogin.a liblogin.so.2 libplain.so smptd.conf >>> >> >> >>OK. >> >> >> >>>and my smtpd.conf file has this configuration >>> >>># This sets smtpd to authenticate using the saslauthd daemon. >>>pwcheck_method:saslauthd >>># This allows only plain and login as the authentication mechanisms. >>>mech_list: plain login >>> >> >> >>OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. >>One never knows with SASL ... >> >> >I added a space stopped and started saslauthd using this command >/usr/local/etc/rc.d/saslauthd.sh start >/usr/local/etc/rc.d/saslauthd.sh start >then stopped and started postfix using >postfix stop >postfix start >still get the errors > >Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed > > >>>Seems simple enough however when i try to logon to my SMTP server i get the following errors. >>>Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >>>Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >>> >> >> >>OK. >> >> >> >>>Is there a log i can check for sasl errors somewhere or do i need to >>> >> >> >>SASL logs to auth.*, check your syslog configuration if it catches this. >> >> >I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? > >Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow > >>>change my permissions on the passwd file any help would be >>>appreciated. >> >> >>Which passwd file? You have configured Postfix for client-side as well >>as fpr server-side SMTP AUTH. Client-side introduces >>/etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we >>talking about /etc/passwd. If you mean /etc/passwd then you don't need >>to change permissions. saslauthd is run started by root:root, so >>permissions should be no problem. >> >> >Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. > >>>Here is a posconf -n output if that helps anyone help me thank you in advance. >>> >>>v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >>>alias_database = hash:/etc/aliases >>>alias_maps = hash:/etc/aliases >>>broken_sasl_auth_clients = yes >>> >> >> >>OK. >> >> >> >>>command_directory = /usr/local/sbin >>>config_directory = /usr/local/etc/postfix >>>daemon_directory = /usr/local/libexec/postfix >>>debug_peer_level = 2 >>>home_mailbox = IMAPdir/INBOX/ >>>inet_interfaces = all >>>mail_owner = postfix >>>mailq_path = /usr/local/bin/mailq >>>manpage_directory = /usr/local/man >>>mydestination = $myhostname, localhost.$mydomain $mydomain >>>mydomain = computerking.ca >>>myhostname = mail1.computerking.ca >>>mynetworks_style = subnet >>>myorigin = $mydomain >>>newaliases_path = /usr/local/bin/newaliases >>>queue_directory = /var/spool/postfix >>>readme_directory = no >>>relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >>>sample_directory = /usr/local/etc/postfix >>>sendmail_path = /usr/local/sbin/sendmail >>>setgid_group = maildrop >>>smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>> >> >> >>If you want to offer server-side SMTP AUTH, you don't need >>smtp_sasl_password_maps; they are for the smtp daemon (client-side) >> >> >What ??? i will comment out this feature for now do not quite understand what this is used for > >>>smtp_tls_loglevel = 2 >>>smtp_tls_note_starttls_offer = yes >>>smtp_use_tls = yes >>>smtpd_recipient_restrictions = permit_mx_backup >> >> >>Turn off smtp_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off > >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>>smtpd_sasl_auth_enable = yes >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_local_domain = >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_security_options = noanonymous >>> >> >> >>OK. >> >> >> >>>smtpd_sender_restrictions = permit_mx_backup >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>> >> >> >>OK. >> >> >> >>>smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >>>smtpd_tls_auth_only = yes >>>smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >>>smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >>>smtpd_tls_loglevel = 2 >>>smtpd_tls_received_header = yes >>>smtpd_tls_session_cache_timeout = 3600s >>>smtpd_use_tls = yes >>> >> >> >>Turn off smtpd_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. >Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] > >>>soft_bounce = no >>>tls_random_source = dev:/dev/urandom >>>unknown_local_recipient_reject_code = 450 >>>virtual_alias_domains = sculpturaldesign.ca >>>virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >>> >> >> >>So far so good... >> >>How do you run saslauthd? >> >using the saslauthd script in the rc.d dir >/usr/local/etc/rc.d/saslauthd.sh start > >>Where does saslauthd put its socket? >> >not sure how do i find out??? > >>What does 'saslauthd -a shadow -d' give as ouput? >> >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d >saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d >saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d >saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login > >yikes that seems like it might be a problem > >>Look for run_path. >what?? > >>Can postfix access this $run_path directory? >> >what?? > >>What do you use as authentication backend i.e. the source of your >>usernames and passwords? >> >I what to use /etc/passwd > >>Can you authenticate without Postfix using 'testsaslauthd'? >> >v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd >su: testsaslauthd: command not found > >I also did a locate testsaslauthd and it did not find anything > >>p@rick >> >> >> From owner-ietf-sasl Thu Aug 19 08:24:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFO0fj012874; Thu, 19 Aug 2004 08:24:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFO09I012873; Thu, 19 Aug 2004 08:24:00 -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 ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFNxAZ012855 for ; Thu, 19 Aug 2004 08:23:59 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i7JFNdb7021625; Thu, 19 Aug 2004 11:23:39 -0400 (EDT) Message-ID: <4124C606.4000103@oceana.com> Date: Thu, 19 Aug 2004 11:23:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Scott Hollenbeck CC: Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , Alexey Melnikov , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Scott Hollenbeck wrote: > I sent a request to the apps discuss list a while back and didn't receive > any responses. OK, time for a more pointed request: would at least one of > you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 from an > applications perspective? It's in WGLC and the SASL WG chair is asking for > review help. I just spent an hour or so reviewing the -08 draft. I have a couple of comments and questions below. Other than these, I don't see anything which breaks any of the existing mechanisms, libraries, or applications that I'm familiar with. I have a few editorial nits which I'll send separately to Alexey. Section 4, requirement 2) - The draft says that "the protocol profile SHOULD also describe how an empty initial response is encoded." I believe that this should be required of the profile and therefore is a MUST, not a SHOULD. Section 4, requirement 3) - Should we explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded? Section 7, paragraph 3 - The draft says "The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity." Presumably, the client has *already* been authenticated by external means and we're just determining if the client can proxy. Unless I'm completely missing the meaning of the existing text, I'd suggest replacing "authenticate as" with "have the access privileges of". -- 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 Aug 19 15:23:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNcXT080979; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JMNcoi080978; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNbhb080963 for ; Thu, 19 Aug 2004 15:23:37 -0700 (PDT) (envelope-from jeffstep@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Aug 2004 15:23:27 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Aug 2004 15:23:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Aug 2004 15:23:26 -0700 Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 15:23:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: plain and login not working Date: Thu, 19 Aug 2004 15:23:21 -0700 Message-ID: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: plain and login not working Thread-Index: AcSFsevWKrePO/lOT5OErRZqKcnLnQAiKl5A From: "Jeff Stephenson" To: "RYAN vAN GINNEKEN" Cc: "ietf-sasl" X-OriginalArrivalTime: 19 Aug 2004 22:23:02.0733 (UTC) FILETIME=[176B7FD0:01C4863B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JMNbhb080969 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As Kurt says, this has nothing to do with this group. However, I'd point out that many servers will not advertise either PLAIN or LOGIN unless you're using a secure connection. Since the server obviously supports TLS, I'd suggest securing the connection with that, at which point you'll probably see the plaintext SASL mechanisms in response to an EHLO. -- jeff -----Original Message----- From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Wednesday, August 18, 2004 10:47 PM To: RYAN vAN GINNEKEN Cc: ietf-sasl Subject: Re: plain and login not working At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME From owner-ietf-sasl Fri Aug 20 02:02:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92qbE021370; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K92q4B021369; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92po3021335 for ; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id A2A0A9E for ; Fri, 20 Aug 2004 03:02:47 -0600 (MDT) Message-ID: <4125BE38.7060901@computerking.ca> Date: Fri, 20 Aug 2004 03:02:48 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: Re: plain and login not working References: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> In-Reply-To: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.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: Thanks and sorry for the off topic post Jeff Stephenson wrote: >As Kurt says, this has nothing to do with this group. However, I'd >point out that many servers will not advertise either PLAIN or LOGIN >unless you're using a secure connection. Since the server obviously >supports TLS, I'd suggest securing the connection with that, at which >point you'll probably see the plaintext SASL mechanisms in response to >an EHLO. > >-- jeff > >-----Original Message----- >From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] >On Behalf Of Kurt D. Zeilenga >Sent: Wednesday, August 18, 2004 10:47 PM >To: RYAN vAN GINNEKEN >Cc: ietf-sasl >Subject: Re: plain and login not working > > >At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: > > >>This is a thread i started in postfix users but think it would be on >> >> >topic at this group too. > >Not sure why you think this topic is appropriate for this list. >This list is for undertaking the work of the IETF SASL Working Group, a >work chartered to engineer SASL technical specifications. >So, unless you have a issue with a particular technical specification >which we are charged to engineer, the discussion should likely be held >on lists specific to SASL implementations you are experience problems >with. > >Regards, Kurt >IETF SASL WG co-chair > > > >>The output of my telnet session is like below and contains NO!!!!! >> >> >entry for PLAIN or LOGIN. Please keep reading this mail as i have >answered all of the questions asked by Paterick. > > >>EHLO computerking.ca >>250-mail1.computerking.ca >>250-PIPELINING >>250-SIZE 10240000 >>250-VRFY >>250-ETRN >>250-STARTTLS >>250-XVERP >>250 8BITMIME >> >> > > > From owner-ietf-sasl Mon Aug 23 03:18:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAIHjr003753; Mon, 23 Aug 2004 03:18:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAIHwJ003752; Mon, 23 Aug 2004 03:18:17 -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.11/8.12.9) with ESMTP id i7NAIGsn003744 for ; Mon, 23 Aug 2004 03:18:16 -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 (internal) with ESMTPA; Mon, 23 Aug 2004 11:22:48 +0100 Message-ID: <4129C44F.4010005@isode.com> Date: Mon, 23 Aug 2004 11:17:51 +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: Ken Murchison CC: Scott Hollenbeck , Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> <4124C606.4000103@oceana.com> In-Reply-To: <4124C606.4000103@oceana.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: Ken Murchison wrote: > Scott Hollenbeck wrote: > >> I sent a request to the apps discuss list a while back and didn't >> receive >> any responses. OK, time for a more pointed request: would at least >> one of >> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 >> from an >> applications perspective? It's in WGLC and the SASL WG chair is >> asking for >> review help. > > I just spent an hour or so reviewing the -08 draft. I have a couple > of comments and questions below. Other than these, I don't see > anything which breaks any of the existing mechanisms, libraries, or > applications that I'm familiar with. I have a few editorial nits > which I'll send separately to Alexey. > > Section 4, requirement 2) - The draft says that "the protocol > profile SHOULD also describe how an empty initial response is > encoded." I believe that this should be required of the profile and > therefore is a MUST, not a SHOULD. You are probably right. The initial response is a SHOULD feature of SASL, that is why, I think, SHOULD is used here. So basically the document should say: "if the initial response is supported by the protocol profile, the profile MUST specify how an empty response is encoded". > Section 4, requirement 3) - Should we explicitly state that the > profile also needs to describe how *empty* server challenges and > client responses as encoded? Not really, as empty challenge/response is a 0-length string, which all profiles should be able to handle already. But I am Ok with clarifying that all protocol profiles MUST be able to exchange 0-length challenges/responses. > Section 7, paragraph 3 - The draft says "The server uses > information, external to SASL, to determine whether the client is > permitted to authenticate as the authorization identity." Presumably, > the client has *already* been authenticated by external means and > we're just determining if the client can proxy. Unless I'm completely > missing the meaning of the existing text, I'd suggest replacing > "authenticate as" with "have the access privileges of". I agree, but I suggest to replace "to authenticate as" with "to act as". Alexey From owner-ietf-sasl Sun Aug 29 14:47:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlRYe010806; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TLlRBM010805; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlQa2010798 for ; Sun, 29 Aug 2004 14:47:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 33948168060; Sun, 29 Aug 2004 17:47:58 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes for IETf 60 meeting Message-Id: <20040829214758.33948168060@cz.mit.edu> Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Review and comment; these will be sent in mid next week] Simple Authentication and Security Layer WG (SASL) Tuesday, August 3 at 1300-1400 ============================== CHAIRS: Sam Hartman Kurt Zeilenga scribe: Wyllys Ingersoll Summary (Kurt): * Done with anonymous SASLPREP, working on base spec, in WG last call. * more attention to digest-md5, GSSAPI, cram-md5 * base spec needs more reviewers. Without review, document cannot progress. Alexey Melnikov: * not many comments in base spec WG last call. * clarification on how re-keying is done - needs new text for security considerations or recommendations section Digest-MD5 (Alexey) * not much work done yet. * open issues at end of doc * needs comments on CBC mode, Sam H. replied, discussion to follow on mailing list * testing of LDAP-aware client and server revealed an interop issue - digest server advertises realms that it supports, client SHOULD pick up realm from a list, but client is not obeying the "SHOULD" and chooses something else. Server assumes that the client MUST choose a listed realm. Is server broken or just interpreting the spec differently? (Kurt) - needs further revision and engineering tests before last call. (Alexey) - more than 1 revision needed. * CBC mode attack to be resolved at next meeting. (Kurt) - possible to get into WG last call by end of year? (Alexey) - "I will try". - no co-author needed (Kurt) - December will be earliest last-call. GSSAPI: * non-NULL channel bindings issue - original doc and new draft says you MUST provide NULL bindings. Simon wanted to be able to use channel bindings. It would be nice to use mechanisms like CCM or other mechanisms discussed at the KITTEN BOF. * Multiple GSS implementations of the krb5 mechanism already working together. * Suggestions - split draft and document GSS-KRB5 as existing, define new GSS draft to deal with new mechanisms, channel binding issue to be addressed in newer draft. * Sam H. issue - new GSSAPI mechanism should be designed to save round-trips, existing one requires 2 or more. * We could address this in a new draft if we think it is worth solving; discussion on list. * Nico issue - fix re-keying problems in new draft. * Sam H. - 2 comments from Jabber (Simon J) - The original motivation for wanting channel bindings was to avoid a per-message token from one context being used with another context. Strong desire to maintain compatibility with existing GSSAPI mechanisms. * Sam (not as chair) - WG must decide that current GSSAPI mech is adequate for future needs and wont be used as a reason for preferring to make SASL mechs instead of GSSAPI mechs - or - FIX IT. Compatiblity with existing KRB5 mech is requirement. * Currently, 1 SASL mech for each GSSAPI mech. In future, this may not be true. * Kurt - we WILL preserve existing SASL-GSS mechanisms. * Sam H - GSS-SPNEGO will likely need to be deprecated because of existing security problems. * Larry G - are there existing deployments of SASL-GSS mechs other than KRB5 and SPNEGO (eg. GSS-xxxxx)? - no * Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands) * Kurt - reluctant to take on new work for WG, encourage an individual draft. * Larry G - argues against lightweight, not much need for it yet. * Kurt - 2 proposals would be good for WG so there is choice. CRAM-MD5: * needs attention once the base spec is complete Misc: * Kurt and Sam to revamp the list of WG milestones and send to list. * Kurt - base spec needs to get done ASAP. Needs more comments and reviewers. * Nico - re-keying issue again. * Kurt - don't make assumptions about security layers that are available. * Sam H. - no requirement for bi-directional exchange once established, re-keying is not always going to be possible. * Nico - Still need an API for implementations that want to use it. * Sam H. - mech designer can't know whether or not bi-directional flow will be possible. * Nico - The mech needs a way to determine if re-key is even possible so it can make the decision on whether or not to do it. An API would make this possible. * Kurt - add new text to draft for security considerations? * Chris Newman - is anyone going to be negatively impacted by changing the generic SASL-GSSAPI spec at this time? Nico says he needs to check. Announcements: * Sam H - Liberty Alliance needs input on their document. * Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS End - 13:45PM Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlRYe010806; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TLlRBM010805; Sun, 29 Aug 2004 14:47:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLlQa2010798 for ; Sun, 29 Aug 2004 14:47:26 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 33948168060; Sun, 29 Aug 2004 17:47:58 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes for IETf 60 meeting Message-Id: <20040829214758.33948168060@cz.mit.edu> Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Review and comment; these will be sent in mid next week] Simple Authentication and Security Layer WG (SASL) Tuesday, August 3 at 1300-1400 ============================== CHAIRS: Sam Hartman Kurt Zeilenga scribe: Wyllys Ingersoll Summary (Kurt): * Done with anonymous SASLPREP, working on base spec, in WG last call. * more attention to digest-md5, GSSAPI, cram-md5 * base spec needs more reviewers. Without review, document cannot progress. Alexey Melnikov: * not many comments in base spec WG last call. * clarification on how re-keying is done - needs new text for security considerations or recommendations section Digest-MD5 (Alexey) * not much work done yet. * open issues at end of doc * needs comments on CBC mode, Sam H. replied, discussion to follow on mailing list * testing of LDAP-aware client and server revealed an interop issue - digest server advertises realms that it supports, client SHOULD pick up realm from a list, but client is not obeying the "SHOULD" and chooses something else. Server assumes that the client MUST choose a listed realm. Is server broken or just interpreting the spec differently? (Kurt) - needs further revision and engineering tests before last call. (Alexey) - more than 1 revision needed. * CBC mode attack to be resolved at next meeting. (Kurt) - possible to get into WG last call by end of year? (Alexey) - "I will try". - no co-author needed (Kurt) - December will be earliest last-call. GSSAPI: * non-NULL channel bindings issue - original doc and new draft says you MUST provide NULL bindings. Simon wanted to be able to use channel bindings. It would be nice to use mechanisms like CCM or other mechanisms discussed at the KITTEN BOF. * Multiple GSS implementations of the krb5 mechanism already working together. * Suggestions - split draft and document GSS-KRB5 as existing, define new GSS draft to deal with new mechanisms, channel binding issue to be addressed in newer draft. * Sam H. issue - new GSSAPI mechanism should be designed to save round-trips, existing one requires 2 or more. * We could address this in a new draft if we think it is worth solving; discussion on list. * Nico issue - fix re-keying problems in new draft. * Sam H. - 2 comments from Jabber (Simon J) - The original motivation for wanting channel bindings was to avoid a per-message token from one context being used with another context. Strong desire to maintain compatibility with existing GSSAPI mechanisms. * Sam (not as chair) - WG must decide that current GSSAPI mech is adequate for future needs and wont be used as a reason for preferring to make SASL mechs instead of GSSAPI mechs - or - FIX IT. Compatiblity with existing KRB5 mech is requirement. * Currently, 1 SASL mech for each GSSAPI mech. In future, this may not be true. * Kurt - we WILL preserve existing SASL-GSS mechanisms. * Sam H - GSS-SPNEGO will likely need to be deprecated because of existing security problems. * Larry G - are there existing deployments of SASL-GSS mechs other than KRB5 and SPNEGO (eg. GSS-xxxxx)? - no * Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands) * Kurt - reluctant to take on new work for WG, encourage an individual draft. * Larry G - argues against lightweight, not much need for it yet. * Kurt - 2 proposals would be good for WG so there is choice. CRAM-MD5: * needs attention once the base spec is complete Misc: * Kurt and Sam to revamp the list of WG milestones and send to list. * Kurt - base spec needs to get done ASAP. Needs more comments and reviewers. * Nico - re-keying issue again. * Kurt - don't make assumptions about security layers that are available. * Sam H. - no requirement for bi-directional exchange once established, re-keying is not always going to be possible. * Nico - Still need an API for implementations that want to use it. * Sam H. - mech designer can't know whether or not bi-directional flow will be possible. * Nico - The mech needs a way to determine if re-key is even possible so it can make the decision on whether or not to do it. An API would make this possible. * Kurt - add new text to draft for security considerations? * Chris Newman - is anyone going to be negatively impacted by changing the generic SASL-GSSAPI spec at this time? Nico says he needs to check. Announcements: * Sam H - Liberty Alliance needs input on their document. * Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS End - 13:45PM Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAIHjr003753; Mon, 23 Aug 2004 03:18:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAIHwJ003752; Mon, 23 Aug 2004 03:18:17 -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.11/8.12.9) with ESMTP id i7NAIGsn003744 for ; Mon, 23 Aug 2004 03:18:16 -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 (internal) with ESMTPA; Mon, 23 Aug 2004 11:22:48 +0100 Message-ID: <4129C44F.4010005@isode.com> Date: Mon, 23 Aug 2004 11:17:51 +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: Ken Murchison CC: Scott Hollenbeck , Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> <4124C606.4000103@oceana.com> In-Reply-To: <4124C606.4000103@oceana.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: Ken Murchison wrote: > Scott Hollenbeck wrote: > >> I sent a request to the apps discuss list a while back and didn't >> receive >> any responses. OK, time for a more pointed request: would at least >> one of >> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 >> from an >> applications perspective? It's in WGLC and the SASL WG chair is >> asking for >> review help. > > I just spent an hour or so reviewing the -08 draft. I have a couple > of comments and questions below. Other than these, I don't see > anything which breaks any of the existing mechanisms, libraries, or > applications that I'm familiar with. I have a few editorial nits > which I'll send separately to Alexey. > > Section 4, requirement 2) - The draft says that "the protocol > profile SHOULD also describe how an empty initial response is > encoded." I believe that this should be required of the profile and > therefore is a MUST, not a SHOULD. You are probably right. The initial response is a SHOULD feature of SASL, that is why, I think, SHOULD is used here. So basically the document should say: "if the initial response is supported by the protocol profile, the profile MUST specify how an empty response is encoded". > Section 4, requirement 3) - Should we explicitly state that the > profile also needs to describe how *empty* server challenges and > client responses as encoded? Not really, as empty challenge/response is a 0-length string, which all profiles should be able to handle already. But I am Ok with clarifying that all protocol profiles MUST be able to exchange 0-length challenges/responses. > Section 7, paragraph 3 - The draft says "The server uses > information, external to SASL, to determine whether the client is > permitted to authenticate as the authorization identity." Presumably, > the client has *already* been authenticated by external means and > we're just determining if the client can proxy. Unless I'm completely > missing the meaning of the existing text, I'd suggest replacing > "authenticate as" with "have the access privileges of". I agree, but I suggest to replace "to authenticate as" with "to act as". Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92qbE021370; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K92q4B021369; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K92po3021335 for ; Fri, 20 Aug 2004 02:02:52 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id A2A0A9E for ; Fri, 20 Aug 2004 03:02:47 -0600 (MDT) Message-ID: <4125BE38.7060901@computerking.ca> Date: Fri, 20 Aug 2004 03:02:48 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: Re: plain and login not working References: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> In-Reply-To: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.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: Thanks and sorry for the off topic post Jeff Stephenson wrote: >As Kurt says, this has nothing to do with this group. However, I'd >point out that many servers will not advertise either PLAIN or LOGIN >unless you're using a secure connection. Since the server obviously >supports TLS, I'd suggest securing the connection with that, at which >point you'll probably see the plaintext SASL mechanisms in response to >an EHLO. > >-- jeff > >-----Original Message----- >From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] >On Behalf Of Kurt D. Zeilenga >Sent: Wednesday, August 18, 2004 10:47 PM >To: RYAN vAN GINNEKEN >Cc: ietf-sasl >Subject: Re: plain and login not working > > >At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: > > >>This is a thread i started in postfix users but think it would be on >> >> >topic at this group too. > >Not sure why you think this topic is appropriate for this list. >This list is for undertaking the work of the IETF SASL Working Group, a >work chartered to engineer SASL technical specifications. >So, unless you have a issue with a particular technical specification >which we are charged to engineer, the discussion should likely be held >on lists specific to SASL implementations you are experience problems >with. > >Regards, Kurt >IETF SASL WG co-chair > > > >>The output of my telnet session is like below and contains NO!!!!! >> >> >entry for PLAIN or LOGIN. Please keep reading this mail as i have >answered all of the questions asked by Paterick. > > >>EHLO computerking.ca >>250-mail1.computerking.ca >>250-PIPELINING >>250-SIZE 10240000 >>250-VRFY >>250-ETRN >>250-STARTTLS >>250-XVERP >>250 8BITMIME >> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNcXT080979; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JMNcoi080978; Thu, 19 Aug 2004 15:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMNbhb080963 for ; Thu, 19 Aug 2004 15:23:37 -0700 (PDT) (envelope-from jeffstep@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Aug 2004 15:23:27 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Aug 2004 15:23:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Aug 2004 15:23:26 -0700 Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 15:23:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: plain and login not working Date: Thu, 19 Aug 2004 15:23:21 -0700 Message-ID: <23AA05B1B7171647BC38C5D761900EA47FAF6B@DF-SEADOG-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: plain and login not working Thread-Index: AcSFsevWKrePO/lOT5OErRZqKcnLnQAiKl5A From: "Jeff Stephenson" To: "RYAN vAN GINNEKEN" Cc: "ietf-sasl" X-OriginalArrivalTime: 19 Aug 2004 22:23:02.0733 (UTC) FILETIME=[176B7FD0:01C4863B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JMNbhb080969 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As Kurt says, this has nothing to do with this group. However, I'd point out that many servers will not advertise either PLAIN or LOGIN unless you're using a secure connection. Since the server obviously supports TLS, I'd suggest securing the connection with that, at which point you'll probably see the plaintext SASL mechanisms in response to an EHLO. -- jeff -----Original Message----- From: owner-ietf-sasl@mail.imc.org [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Wednesday, August 18, 2004 10:47 PM To: RYAN vAN GINNEKEN Cc: ietf-sasl Subject: Re: plain and login not working At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFO0fj012874; Thu, 19 Aug 2004 08:24:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFO09I012873; Thu, 19 Aug 2004 08:24:00 -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 ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFNxAZ012855 for ; Thu, 19 Aug 2004 08:23:59 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id i7JFNdb7021625; Thu, 19 Aug 2004 11:23:39 -0400 (EDT) Message-ID: <4124C606.4000103@oceana.com> Date: Thu, 19 Aug 2004 11:23:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Scott Hollenbeck CC: Chris.Newman@Sun.COM, rjs3@andrew.cmu.edu, MRC@CAC.Washington.EDU, rlmorgan@washington.edu, Kurt@OpenLDAP.org, "'Ted Hardie'" , Alexey Melnikov , SASL mailing list Subject: Re: FW: SASL base spec WGLC References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F7EB@vsvapostal8.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Scott Hollenbeck wrote: > I sent a request to the apps discuss list a while back and didn't receive > any responses. OK, time for a more pointed request: would at least one of > you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 from an > applications perspective? It's in WGLC and the SASL WG chair is asking for > review help. I just spent an hour or so reviewing the -08 draft. I have a couple of comments and questions below. Other than these, I don't see anything which breaks any of the existing mechanisms, libraries, or applications that I'm familiar with. I have a few editorial nits which I'll send separately to Alexey. Section 4, requirement 2) - The draft says that "the protocol profile SHOULD also describe how an empty initial response is encoded." I believe that this should be required of the profile and therefore is a MUST, not a SHOULD. Section 4, requirement 3) - Should we explicitly state that the profile also needs to describe how *empty* server challenges and client responses as encoded? Section 7, paragraph 3 - The draft says "The server uses information, external to SASL, to determine whether the client is permitted to authenticate as the authorization identity." Presumably, the client has *already* been authenticated by external means and we're just determining if the client can proxy. Unless I'm completely missing the meaning of the existing text, I'd suggest replacing "authenticate as" with "have the access privileges of". -- 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.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J5kZ39018844; Wed, 18 Aug 2004 22:46:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J5kZiO018841; Wed, 18 Aug 2004 22:46: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.11/8.12.9) with ESMTP id i7J5kYIu018824 for ; Wed, 18 Aug 2004 22:46:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7J5kHMw053507; Thu, 19 Aug 2004 05:46:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040819074135.040bd4e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 19 Aug 2004 07:46:53 +0200 To: RYAN vAN GINNEKEN From: "Kurt D. Zeilenga" Subject: Re: plain and login not working Cc: ietf-sasl In-Reply-To: <4123D15A.4060509@computerking.ca> References: <4123D15A.4060509@computerking.ca> 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:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote: >This is a thread i started in postfix users but think it would be on topic at this group too. Not sure why you think this topic is appropriate for this list. This list is for undertaking the work of the IETF SASL Working Group, a work chartered to engineer SASL technical specifications. So, unless you have a issue with a particular technical specification which we are charged to engineer, the discussion should likely be held on lists specific to SASL implementations you are experience problems with. Regards, Kurt IETF SASL WG co-chair >The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. >EHLO computerking.ca >250-mail1.computerking.ca >250-PIPELINING >250-SIZE 10240000 >250-VRFY >250-ETRN >250-STARTTLS >250-XVERP >250 8BITMIME > >>* RYAN vAN GINNEKEN [040818 01:49]: >> >> >>>I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >>>stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >>>configured the my /user/local/lib/sasl2 dir to contain only >>>Sendmail.conf liblogin.so libplain.a libplain.so.2 >>>liblogin.a liblogin.so.2 libplain.so smptd.conf >>> >> >> >>OK. >> >> >> >>>and my smtpd.conf file has this configuration >>> >>># This sets smtpd to authenticate using the saslauthd daemon. >>>pwcheck_method:saslauthd >>># This allows only plain and login as the authentication mechanisms. >>>mech_list: plain login >>> >> >> >>OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. >>One never knows with SASL ... >> >> >I added a space stopped and started saslauthd using this command >/usr/local/etc/rc.d/saslauthd.sh start >/usr/local/etc/rc.d/saslauthd.sh start >then stopped and started postfix using >postfix stop >postfix start >still get the errors > >Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed > > >>>Seems simple enough however when i try to logon to my SMTP server i get the following errors. >>>Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed >>>Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >>> >> >> >>OK. >> >> >> >>>Is there a log i can check for sasl errors somewhere or do i need to >>> >> >> >>SASL logs to auth.*, check your syslog configuration if it catches this. >> >> >I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? > >Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow > >>>change my permissions on the passwd file any help would be >>>appreciated. >> >> >>Which passwd file? You have configured Postfix for client-side as well >>as fpr server-side SMTP AUTH. Client-side introduces >>/etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we >>talking about /etc/passwd. If you mean /etc/passwd then you don't need >>to change permissions. saslauthd is run started by root:root, so >>permissions should be no problem. >> >> >Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. > >>>Here is a posconf -n output if that helps anyone help me thank you in advance. >>> >>>v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >>>alias_database = hash:/etc/aliases >>>alias_maps = hash:/etc/aliases >>>broken_sasl_auth_clients = yes >>> >> >> >>OK. >> >> >> >>>command_directory = /usr/local/sbin >>>config_directory = /usr/local/etc/postfix >>>daemon_directory = /usr/local/libexec/postfix >>>debug_peer_level = 2 >>>home_mailbox = IMAPdir/INBOX/ >>>inet_interfaces = all >>>mail_owner = postfix >>>mailq_path = /usr/local/bin/mailq >>>manpage_directory = /usr/local/man >>>mydestination = $myhostname, localhost.$mydomain $mydomain >>>mydomain = computerking.ca >>>myhostname = mail1.computerking.ca >>>mynetworks_style = subnet >>>myorigin = $mydomain >>>newaliases_path = /usr/local/bin/newaliases >>>queue_directory = /var/spool/postfix >>>readme_directory = no >>>relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >>>sample_directory = /usr/local/etc/postfix >>>sendmail_path = /usr/local/sbin/sendmail >>>setgid_group = maildrop >>>smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>> >> >> >>If you want to offer server-side SMTP AUTH, you don't need >>smtp_sasl_password_maps; they are for the smtp daemon (client-side) >> >> >What ??? i will comment out this feature for now do not quite understand what this is used for > >>>smtp_tls_loglevel = 2 >>>smtp_tls_note_starttls_offer = yes >>>smtp_use_tls = yes >>>smtpd_recipient_restrictions = permit_mx_backup >> >> >>Turn off smtp_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off > >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>>smtpd_sasl_auth_enable = yes >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_local_domain = >>> >> >> >>OK. >> >> >> >>>smtpd_sasl_security_options = noanonymous >>> >> >> >>OK. >> >> >> >>>smtpd_sender_restrictions = permit_mx_backup >>>permit_sasl_authenticated, permit_mynetworks, >>>reject_unauth_destination >>> >> >> >>OK. >> >> >> >>>smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >>>smtpd_tls_auth_only = yes >>>smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >>>smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >>>smtpd_tls_loglevel = 2 >>>smtpd_tls_received_header = yes >>>smtpd_tls_session_cache_timeout = 3600s >>>smtpd_use_tls = yes >>> >> >> >>Turn off smtpd_use_tls while you test SASL; TLS settings can influence >>the behaviour of SASL. >> >> >I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. >Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] >Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] > >>>soft_bounce = no >>>tls_random_source = dev:/dev/urandom >>>unknown_local_recipient_reject_code = 450 >>>virtual_alias_domains = sculpturaldesign.ca >>>virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >>> >> >> >>So far so good... >> >>How do you run saslauthd? >> >using the saslauthd script in the rc.d dir >/usr/local/etc/rc.d/saslauthd.sh start > >>Where does saslauthd put its socket? >> >not sure how do i find out??? > >>What does 'saslauthd -a shadow -d' give as ouput? >> >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d >saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d >saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain >v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d >saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login > >yikes that seems like it might be a problem > >>Look for run_path. >what?? > >>Can postfix access this $run_path directory? >> >what?? > >>What do you use as authentication backend i.e. the source of your >>usernames and passwords? >> >I what to use /etc/passwd > >>Can you authenticate without Postfix using 'testsaslauthd'? >> >v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd >su: testsaslauthd: command not found > >I also did a locate testsaslauthd and it did not find anything > >>p@rick >> >> >> Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFPRA060070; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INFP0A060069; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INFORU060055 for ; Wed, 18 Aug 2004 16:15:25 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7INFOfb001739 for ; Wed, 18 Aug 2004 18:15:24 -0500 Received: from [135.210.8.81] (unknown[135.210.8.81](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818231541gw1002f0ioe> (Authid: tony); Wed, 18 Aug 2004 23:15:41 +0000 Message-ID: <4123E30B.7060908@att.com> Date: Wed, 18 Aug 2004 19:15:23 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: md5 definitely broken? References: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Which is why I brought it up on ietf-sasl. Should we be busy defining DIGEST-SHA256 and not DIGEST-MD5? Tony Hansen tony@att.com Paul Leach wrote: >>Tony Hansen writes: >> >>>I saw a note in the openpgp mailing list about md5 definitely being >>>cracked. Anyone know more? >> >>"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" >>http://eprint.iacr.org/2004/199/ >> >>Whether "collisions" imply "cracked", in the real world, >>probably depend on the details, and the application. It is >>not clear (to me, at least) how you would attack HMAC-MD5 >>based on the above result. > > I've see mail from Hugo Krawczyk that says it does not place HMACs in > jeopardy. > > Also, AFAIK, it has not been claimed that, given some arbitrary text, an > attacker can find other text that hashes to the same value. However, at > the current time, the existence of these collisions strongly implies > that that is possible, and one must assume that in the not to distant > future it will be done. Hence, it would be the conservative thing to do > to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher > suite. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAJYj049591; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IMAJWh049590; Wed, 18 Aug 2004 15:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMAGvU049569 for ; Wed, 18 Aug 2004 15:10:16 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 18 Aug 2004 15:10:54 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:04 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:10:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 18 Aug 2004 15:09:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: md5 definitely broken? Date: Wed, 18 Aug 2004 15:10:07 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A870870@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: md5 definitely broken? thread-index: AcSFV9LqW81pSYYhQ72w4YiFay2arAAFrPMQ From: "Paul Leach" To: "Simon Josefsson" , X-OriginalArrivalTime: 18 Aug 2004 22:09:17.0750 (UTC) FILETIME=[01475560:01C48570] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IMAGvU049583 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 Simon Josefsson > Sent: Wednesday, August 18, 2004 12:02 PM > To: ietf-sasl@imc.org > Subject: Re: md5 definitely broken? > > > Tony Hansen writes: > > > I saw a note in the openpgp mailing list about md5 definitely being > > cracked. Anyone know more? > > "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" > http://eprint.iacr.org/2004/199/ > > Whether "collisions" imply "cracked", in the real world, > probably depend on the details, and the application. It is > not clear (to me, at least) how you would attack HMAC-MD5 > based on the above result. I've see mail from Hugo Krawczyk that says it does not place HMACs in jeopardy. Also, AFAIK, it has not been claimed that, given some arbitrary text, an attacker can find other text that hashes to the same value. However, at the current time, the existence of these collisions strongly implies that that is possible, and one must assume that in the not to distant future it will be done. Hence, it would be the conservative thing to do to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher suite. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxiI4048024; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILxiEe048023; Wed, 18 Aug 2004 14:59:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.computerking.ca (computerking.ca [209.115.173.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILxema048012 for ; Wed, 18 Aug 2004 14:59:42 -0700 (PDT) (envelope-from maillist@computerking.ca) Received: from computerking.ca (v22001.computerking.ca [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.computerking.ca (Postfix) with ESMTP id BAC1997 for ; Wed, 18 Aug 2004 15:59:43 -0600 (MDT) Message-ID: <4123D15A.4060509@computerking.ca> Date: Wed, 18 Aug 2004 15:59:54 -0600 From: RYAN vAN GINNEKEN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: plain and login not working 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: This is a thread i started in postfix users but think it would be on topic at this group too. The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick. EHLO computerking.ca 250-mail1.computerking.ca 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-XVERP 250 8BITMIME > * RYAN vAN GINNEKEN [040818 01:49]: > > >> I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd >> stable 4.9 using cyrus-sasl/saslauthd version 2.1.1.19 have >> configured the my /user/local/lib/sasl2 dir to contain only >> Sendmail.conf liblogin.so libplain.a libplain.so.2 >> liblogin.a liblogin.so.2 libplain.so smptd.conf >> > > > OK. > > > >> and my smtpd.conf file has this configuration >> >> # This sets smtpd to authenticate using the saslauthd daemon. >> pwcheck_method:saslauthd >> # This allows only plain and login as the authentication mechanisms. >> mech_list: plain login >> > > > OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd. > One never knows with SASL ... > > > I added a space stopped and started saslauthd using this command /usr/local/etc/rc.d/saslauthd.sh start /usr/local/etc/rc.d/saslauthd.sh start then stopped and started postfix using postfix stop postfix start still get the errors Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed >> Seems simple enough however when i try to logon to my SMTP server i >> get the following errors. >> Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL PLAIN authentication failed >> Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: >> unknown[209.115.173.22]: SASL LOGIN authentication failed >> > > > OK. > > > >> Is there a log i can check for sasl errors somewhere or do i need to >> > > > SASL logs to auth.*, check your syslog configuration if it catches this. > > > I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working? Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech : unknown authentication mechanism: shadow >> change my permissions on the passwd file any help would be >> appreciated. > > > Which passwd file? You have configured Postfix for client-side as well > as fpr server-side SMTP AUTH. Client-side introduces > /etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we > talking about /etc/passwd. If you mean /etc/passwd then you don't need > to change permissions. saslauthd is run started by root:root, so > permissions should be no problem. > > > Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for. I just need to be able to authenticate to postfix remotely and from within my internal network. >> Here is a posconf -n output if that helps anyone help me thank you in >> advance. >> >> v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> broken_sasl_auth_clients = yes >> > > > OK. > > > >> command_directory = /usr/local/sbin >> config_directory = /usr/local/etc/postfix >> daemon_directory = /usr/local/libexec/postfix >> debug_peer_level = 2 >> home_mailbox = IMAPdir/INBOX/ >> inet_interfaces = all >> mail_owner = postfix >> mailq_path = /usr/local/bin/mailq >> manpage_directory = /usr/local/man >> mydestination = $myhostname, localhost.$mydomain $mydomain >> mydomain = computerking.ca >> myhostname = mail1.computerking.ca >> mynetworks_style = subnet >> myorigin = $mydomain >> newaliases_path = /usr/local/bin/newaliases >> queue_directory = /var/spool/postfix >> readme_directory = no >> relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca >> sample_directory = /usr/local/etc/postfix >> sendmail_path = /usr/local/sbin/sendmail >> setgid_group = maildrop >> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >> > > > If you want to offer server-side SMTP AUTH, you don't need > smtp_sasl_password_maps; they are for the smtp daemon (client-side) > > > What ??? i will comment out this feature for now do not quite understand what this is used for >> smtp_tls_loglevel = 2 >> smtp_tls_note_starttls_offer = yes >> smtp_use_tls = yes >> smtpd_recipient_restrictions = permit_mx_backup > > > Turn off smtp_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> smtpd_sasl_auth_enable = yes >> > > > OK. > > > >> smtpd_sasl_local_domain = >> > > > OK. > > > >> smtpd_sasl_security_options = noanonymous >> > > > OK. > > > >> smtpd_sender_restrictions = permit_mx_backup >> permit_sasl_authenticated, permit_mynetworks, >> reject_unauth_destination >> > > > OK. > > > >> smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem >> smtpd_tls_auth_only = yes >> smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem >> smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem >> smtpd_tls_loglevel = 2 >> smtpd_tls_received_header = yes >> smtpd_tls_session_cache_timeout = 3600s >> smtpd_use_tls = yes >> > > > Turn off smtpd_use_tls while you test SASL; TLS settings can influence > the behaviour of SASL. > > > I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server. Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1] Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1] >> soft_bounce = no >> tls_random_source = dev:/dev/urandom >> unknown_local_recipient_reject_code = 450 >> virtual_alias_domains = sculpturaldesign.ca >> virtual_alias_maps = hash:/usr/local/etc/postfix/virtual >> > > > So far so good... > > How do you run saslauthd? > > using the saslauthd script in the rc.d dir /usr/local/etc/rc.d/saslauthd.sh start > Where does saslauthd put its socket? > > not sure how do i find out??? > What does 'saslauthd -a shadow -d' give as ouput? > > v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d saslauthd[33214] :set_auth_mech : unknown authentication mechanism: shadow v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d saslauthd[33215] :set_auth_mech : unknown authentication mechanism: plain v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d saslauthd[33228] :set_auth_mech : unknown authentication mechanism: login yikes that seems like it might be a problem > Look for run_path. > what?? > Can postfix access this $run_path directory? > > what?? > What do you use as authentication backend i.e. the source of your > usernames and passwords? > > I what to use /etc/passwd > Can you authenticate without Postfix using 'testsaslauthd'? > > v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd su: testsaslauthd: command not found I also did a locate testsaslauthd and it did not find anything > p@rick > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WWg029579; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IK6W4i029578; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IK6WUw029556 for ; Wed, 18 Aug 2004 13:06:32 -0700 (PDT) (envelope-from lgl@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6S1i024246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2004 13:06:29 -0700 (PDT) Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.212]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7IK6PO2001831; Wed, 18 Aug 2004 13:06:26 -0700 (PDT) Message-Id: <6.0.0.10.2.20040818130258.047981d0@qcmail1.qualcomm.com> X-Sender: llundbla@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.10 (Beta) Date: Wed, 18 Aug 2004 13:06:24 -0700 To: Russ Housley , Tony Hansen , ietf-sasl From: Laurence Lundblade Subject: Re: md5 definitely broken? In-Reply-To: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> References: <4123A355.5000209@att.com> <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:16 PM 8/18/2004, Russ Housley wrote: >Tony: > >Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, >MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and >three other hash functions. You can get it from: > > http://eprint.iacr.org/2004/199.pdf > >It does not provide the attacks, but it does allow one to confirm the >discovery of collisions. > >The ramification of this news is pretty clear for digital signatures that >make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 >and HTTP Digest. > >Anything that has already been signed with MD5 is definitely safe. If one >stops using MD5 today, nothing that has already been signed is at risk. Except if you determine when something was signed by a signed timed stamp from time stamp authority that used MD5. You can't distinguish what was signed in the past from something that was made to look like it was signed in the past if you're using signed time stamps with MD5. You're OK if you have some *other* strong way to determine when it was signed. LL Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJFj9J020794; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJFjkX020793; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJFide020776 for ; Wed, 18 Aug 2004 12:15:45 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 23832 invoked by uid 0); 18 Aug 2004 19:15:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.240.240) by woodstock.binhost.com with SMTP; 18 Aug 2004 19:15:45 -0000 Message-Id: <6.1.1.1.2.20040818150853.09d4f568@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 18 Aug 2004 15:16:28 -0400 To: Tony Hansen , ietf-sasl From: Russ Housley Subject: Re: md5 definitely broken? In-Reply-To: <4123A355.5000209@att.com> References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony: Yes, MD5 has been broken. A paper, "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and three other hash functions. You can get it from: http://eprint.iacr.org/2004/199.pdf It does not provide the attacks, but it does allow one to confirm the discovery of collisions. The ramification of this news is pretty clear for digital signatures that make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 and HTTP Digest. Anything that has already been signed with MD5 is definitely safe. If one stops using MD5 today, nothing that has already been signed is at risk. However, it is getting risky to sign certificates with MD5, in my opinion. Russ At 02:43 PM 8/18/2004, Tony Hansen wrote: >I saw a note in the openpgp mailing list about md5 definitely being >cracked. Anyone know more? > > Tony Hansen > tony@att.com > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1mgk017793; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJ1mEx017792; Wed, 18 Aug 2004 12:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJ1iQR017772 for ; Wed, 18 Aug 2004 12:01:44 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BxVgt-0005Ps-00 for ; Wed, 18 Aug 2004 21:01:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Aug 2004 21:01:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: md5 definitely broken? Date: Wed, 18 Aug 2004 21:01:36 +0200 Lines: 16 Message-ID: References: <4123A355.5000209@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:owG6sPrHdscmMpa7vt+m9PbTcO8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen writes: > I saw a note in the openpgp mailing list about md5 definitely being > cracked. Anyone know more? "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199/ Whether "collisions" imply "cracked", in the real world, probably depend on the details, and the application. It is not clear (to me, at least) how you would attack HMAC-MD5 based on the above result. (FWIW, I've verified all but the RIPEMD-128 collisions in the paper.) Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhdGE014932; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIhdPf014931; Wed, 18 Aug 2004 11:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIhcsh014906 for ; Wed, 18 Aug 2004 11:43:38 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7IIhbUF014448 for ; Wed, 18 Aug 2004 14:43:37 -0400 Received: from [135.91.110.75] (thansen-n.mt.att.com[135.91.110.75](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040818184354gw1002evofe> (Authid: tony); Wed, 18 Aug 2004 18:43:54 +0000 Message-ID: <4123A355.5000209@att.com> Date: Wed, 18 Aug 2004 14:43:33 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl Subject: md5 definitely broken? 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 saw a note in the openpgp mailing list about md5 definitely being cracked. Anyone know more? Tony Hansen tony@att.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F6Wcrs013726; Sat, 14 Aug 2004 23:32:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F6Wc0N013725; Sat, 14 Aug 2004 23:32:38 -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.11/8.12.9) with ESMTP id i7F6Wb51013700 for ; Sat, 14 Aug 2004 23:32:37 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7F6WUMw025334; Sun, 15 Aug 2004 06:32:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040814130844.02cb1890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 15 Aug 2004 07:13:04 +0200 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: 2222bis: identities and authorization Cc: ietf-sasl@imc.org In-Reply-To: References: <6.1.2.0.0.20040813082412.081cbe20@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 07:17 PM 8/13/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> I have completed my review of > Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor > Kurt> editorial comments (which I have separately sent to the > Kurt> Editor). This note discussions problems I found related to > Kurt> identities and authorization. > > Kurt> The 'Authorization and authentication identities' section > Kurt> (3.2) starts off by stating that 'SASL authentication deals > Kurt> with two identities' but then describes the processing model > Kurt> to involve three identities, two of which it simply refers > Kurt> to as 'authorization' identities. I believe we either need > Kurt> better distinguish these identities within the document, by > Kurt> through qualification (proxy authorization identity > Kurt> v. application authorization identity) or by use of > Kurt> replacement terminology (proxied identity v. authorization > Kurt> identity). I prefer the latter approach as the former > Kurt> qualifications are themselves a bit confused and the latter > Kurt> seems more in step with RFC 2828. > > >Would you mind explaining the problem you had with this section in >better detail? I thought it flowed fairly well and is a significant >improvement on our previous attempts to describe this issue. However >I might well miss problems because as someone who has been following >SASL I'm familiar with the issue. I am not always good at reading a >document as someone new to a technology. Sure. The following 3.2 text: > The processing model is as follows. A server, upon completion of the > authentication mechanism, uses the results produced by the > authentication mechanism, the client-provided authorization identity > value (which may be the empty string), and local policy information > to derive an authorization identity. clearly shows the document is using the term 'authorization identity' to refer, at times, to the client-provided authorization identity and, at times, to a derived authorization identity. However, in other portions of the document, the term 'authorization identity' is mostly used unqualified. While qualification of the term would likely resolve this issue, that solution would likely be cumbersome. As the 'authorization identity' more properly refers to the identity directly used in authorization, it seems more appropriate to call the value referred to here as the 'client-provided authorization identity' as the 'proxied identity'. While I am working on a more complete replacement text, here is glimpse of the suggested clarification: Conceptually, the SASL framework deals with three identities: - the authentication identity, - the proxied identity, and - the authorization identity. The authentication identity is derived from client's authentication credentials. The proxied identity is optionally provided by the client seeking to assume the identity of another user (or entity). The authorization identity is the server-produced primary identity used for making access control and other policy decisions. These identities are managed as follows: The server uses the authentication identity established through the authentication exchange, the proxied identity (if provided), and possibly other information to produce the authorization identity. I've been trying to come with a new term to call the derived identity to allow us unambiguously use the term 'authorization identity' to refer to the client provided value, as the WG seems to have some attachment to this usage. The best I have come with here is 'subject identity' (the identity which is the subject in access control decisions). I do not recommend this approach myself as I believe it would be more proper to use the term 'authorization identity' to refer to the subject of access control decisions. However, I am far more concerned about ambiguous use of the term (using the term to refer to two different values) than I am about which of the two uses continues to this term. That is, I can live with calling the client provided value an 'authorization identity' if we don't also use that term to refer to the derived identity. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EHshMf053757; Sat, 14 Aug 2004 10:54:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EHshFb053756; Sat, 14 Aug 2004 10:54:43 -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.11/8.12.9) with ESMTP id i7EHsf6Y053749 for ; Sat, 14 Aug 2004 10:54:42 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust157.tnt101.lnd4.gbr.da.uu.net [213.116.50.157]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 14 Aug 2004 18:58:45 +0100 Message-ID: <411E51A3.9070705@isode.com> Date: Sat, 14 Aug 2004 18:53:39 +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: Paul Leach CC: SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>Paul Leach wrote: >> >> >>>[Paul Leach] Use of names and realms of this form was not the intention >>> >>> >>>when the protocol was spec'd. The idea was that realms would be DNS >>>names. >>> >>> >>Although the former might be true, the latter is not, as RFC >>2831 has the following example of a realm: >>registered_users@gotham.news.example.com. >> >> >I sure don't recall that example.... I can only speak for my intentions >as I remember them. > >The MSFT UI usually has two modes: one where there are two edit boxes >for entering name and realm (respectively); and one with one edit box >where special characters are understood as separating them. > >An update could suggest some scheme such as this. Or it could merely >state a requirement on UIs that arbitrary user names and realm names >have to be able to be entered, and that if they want to use special >characters to separate them, then they have to be able to escape the >special characters (and that they need to specify their escape rules). > I like that. Speaking of UI: the UI should also be able to display all realms advertised by the server (otherwise what is the point of advertising them anyway?), e.g. a listbox with advertised realms, but so that the client can type in a different realm. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2QBs045044; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DI2Q14045043; Fri, 13 Aug 2004 11:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DI2PlQ045026 for ; Fri, 13 Aug 2004 11:02:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 11:01:22 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:02:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 11:01:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 11:02:24 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7841E4@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBXBWqGsSCY03uQeit5LDe2JnrQwAAqO2w From: "Paul Leach" To: "Alexey Melnikov" Cc: "Kurt D. Zeilenga" , "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 18:01:39.0802 (UTC) FILETIME=[952FA3A0:01C4815F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DI2PlQ045036 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Alexey Melnikov [mailto:Alexey.Melnikov@isode.com] > Sent: Friday, August 13, 2004 10:36 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Paul Leach wrote: > > > > >[Paul Leach] Use of names and realms of this form was not > the intention > >when the protocol was spec'd. The idea was that realms would be DNS > >names. > > > Although the former might be true, the latter is not, as RFC > 2831 has the following example of a realm: > registered_users@gotham.news.example.com. > I sure don't recall that example.... I can only speak for my intentions as I remember them. The MSFT UI usually has two modes: one where there are two edit boxes for entering name and realm (respectively); and one with one edit box where special characters are understood as separating them. An update could suggest some scheme such as this. Or it could merely state a requirement on UIs that arbitrary user names and realm names have to be able to be entered, and that if they want to use special characters to separate them, then they have to be able to escape the special characters (and that they need to specify their escape rules). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHi9po043087; Fri, 13 Aug 2004 10:44:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHi98P043086; Fri, 13 Aug 2004 10:44: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.11/8.12.9) with ESMTP id i7DHi7H8043075 for ; Fri, 13 Aug 2004 10:44: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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:48:15 +0100 Message-ID: <411CFDE3.4030702@isode.com> Date: Fri, 13 Aug 2004 18:44:03 +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: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> In-Reply-To: <411BAC01.7040407@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: Alexey Melnikov wrote: > There is another issue here: the client has split > "foo@bar.example.com" into username and realm parts, instead of > sending the value as is in the username option. The same client was > also treating a username "BAR\foo" as username=foo and realm=BAR. To complete my description: the client is transforming entered username "foo" into username="foo", realm="" > Arguably this is UI issue, but the client is still broken, because the > client makes assumptions about how username should look like and there > is no easy way to enter username as expected by the server. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHaIti042332; Fri, 13 Aug 2004 10:36:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHaIYY042331; Fri, 13 Aug 2004 10:36:18 -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.11/8.12.9) with ESMTP id i7DHaHjF042325 for ; Fri, 13 Aug 2004 10:36:17 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 18:40:21 +0100 Message-ID: <411CFC0A.3070405@isode.com> Date: Fri, 13 Aug 2004 18:36:10 +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: Paul Leach CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.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: Paul Leach wrote: >>-----Original Message----- >>From: owner-ietf-sasl@mail.imc.org >> >> >>On Behalf Of Kurt D. Zeilenga >>Sent: Friday, August 13, 2004 12:32 AM >>To: Alexey Melnikov >>Cc: SASL WG >>Subject: Re: DIGEST-MD5 interop issue >> >>Exactly, the client is making assumptions which prevent users from being >> >> >>able to use it with independently developed servers. A client which >>cannot >>handle the full range of identity and realm values is simply broken. For >> >> >>instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in >> >> >>the realm project@OPENLDAP.ORG. I would not be able to use this or like >> >> >>clients. >> >> > >[Paul Leach] Use of names and realms of this form was not the intention >when the protocol was spec'd. The idea was that realms would be DNS >names. > Although the former might be true, the latter is not, as RFC 2831 has the following example of a realm: registered_users@gotham.news.example.com. >You can legitimately gripe that the spec does not make this intention >clear. > Indeed. Text about realms has caused problems before, because it is so vague. > Or that the client in question doesn't make clear its rules for >transforming what the user types into what gets sent on the wire. Or >both. > > Yes (both). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH3KW040135; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHH3Hf040134; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHH35F040125 for ; Fri, 13 Aug 2004 10:17:03 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 312331783C9; Fri, 13 Aug 2004 13:17:09 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: 2222bis: identities and authorization References: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> From: Sam Hartman Date: Fri, 13 Aug 2004 13:17:09 -0400 In-Reply-To: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> (Kurt D. Zeilenga's message of "Fri, 13 Aug 2004 09:34:04 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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 have completed my review of Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor Kurt> editorial comments (which I have separately sent to the Kurt> Editor). This note discussions problems I found related to Kurt> identities and authorization. Kurt> The 'Authorization and authentication identities' section Kurt> (3.2) starts off by stating that 'SASL authentication deals Kurt> with two identities' but then describes the processing model Kurt> to involve three identities, two of which it simply refers Kurt> to as 'authorization' identities. I believe we either need Kurt> better distinguish these identities within the document, by Kurt> through qualification (proxy authorization identity Kurt> v. application authorization identity) or by use of Kurt> replacement terminology (proxied identity v. authorization Kurt> identity). I prefer the latter approach as the former Kurt> qualifications are themselves a bit confused and the latter Kurt> seems more in step with RFC 2828. Would you mind explaining the problem you had with this section in better detail? I thought it flowed fairly well and is a significant improvement on our previous attempts to describe this issue. However I might well miss problems because as someone who has been following SASL I'm familiar with the issue. I am not always good at reading a document as someone new to a technology. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEJUC039813; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHEJfY039812; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEITp039805 for ; Fri, 13 Aug 2004 10:14:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D4338E0036; Fri, 13 Aug 2004 13:14:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> From: Sam Hartman Date: Fri, 13 Aug 2004 13:14:25 -0400 In-Reply-To: <20040813004713.GJ892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:47:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I figure the new SASL GSS mech document will say Nicolas> something about channel bindings, but perhaps rfc2222bis Nicolas> should also. I do hope the new GSSAPI draft discusses this issue. Nicolas> Specifically I think that rfc2222bis could use: Nicolas> a) Security Considerations text about use of mechanisms Nicolas> that don't support channel bindings in conjunction with Nicolas> TLS. This seems problematic given that all current mechanisms don't support channel bindings. I think the best we could do is security considerations text describing the multiple layers problem. Nicolas> Clients should be admonished to validate TLS server Nicolas> IDs to prevent MITM attacks when using SASL-over-TLS. Nicolas> Similarly with other variants of SASL-over-TLS. Agreed. Nicolas> b) Text recommending support for channel bindings in Nicolas> future mechanisms, where possible. Digest-MD5, for Nicolas> example, could easily support channel bindings. This sounds out of scope for the SASL working group. I believe our charter prohibits us from adding new features to SASL. I don't think it has similar prohibitions for the GSSAPI mechanism. I agree channel bindings are a good thing for SASL. I disagree that they are well specified enough for us to be adding text about them to the base sasl document for this revision. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4x70038706; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DH4xhV038705; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH4wC3038696 for ; Fri, 13 Aug 2004 10:04:59 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 10:04:58 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:04:57 -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); Fri, 13 Aug 2004 10:04:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 10:05:21 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A7840BC@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBRzVqtmM1ELj0QeCvRNk/Qj702gAEDIDw From: "Paul Leach" To: "Jeffrey Hutzelman" , "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 17:04:08.0451 (UTC) FILETIME=[8C054530:01C48157] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DH4xC3038700 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 Jeffrey Hutzelman > Sent: Friday, August 13, 2004 7:52 AM > To: Kurt D. Zeilenga; Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > The reason for the SHOULD is that the server has indicated which realms it > is willing/able to accept, and it's expected that the server will usually > reject any other realms. [Paul Leach] The server may also accept names in the realm "fbi.gov", but may not want to advertise that fact. Clients that have out of band knowledge about the realms supported may attempt to authenticate using one of those realms. Hence it is not "expected" that another realm will fail. The inverse: it can not be expected that it will succeed without OOB info. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvE3Q036998; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGvEu2036997; Fri, 13 Aug 2004 09:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGvDc5036899 for ; Fri, 13 Aug 2004 09:57:13 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 09:57:13 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:56:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:57:08 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 09:56:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DIGEST-MD5 interop issue Date: Fri, 13 Aug 2004 09:57:32 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460A78409E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIGEST-MD5 interop issue thread-index: AcSBIQCJAp+5L9SWQf2IEz1lwX0AyQANRB4w From: "Paul Leach" To: "Kurt D. Zeilenga" , "Alexey Melnikov" Cc: "SASL WG" X-OriginalArrivalTime: 13 Aug 2004 16:56:21.0608 (UTC) FILETIME=[75C2AE80:01C48156] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DGvDc5036965 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 Kurt D. Zeilenga > Sent: Friday, August 13, 2004 12:32 AM > To: Alexey Melnikov > Cc: SASL WG > Subject: Re: DIGEST-MD5 interop issue > > Exactly, the client is making assumptions which prevent users from being > able to use it with independently developed servers. A client which > cannot > handle the full range of identity and realm values is simply broken. For > instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in > the realm project@OPENLDAP.ORG. I would not be able to use this or like > clients. [Paul Leach] Use of names and realms of this form was not the intention when the protocol was spec'd. The idea was that realms would be DNS names. You can legitimately gripe that the spec does not make this intention clear. Or that the client in question doesn't make clear its rules for transforming what the user types into what gets sent on the wire. Or both. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFqkhk030227; Fri, 13 Aug 2004 08:52:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFqkdi030226; Fri, 13 Aug 2004 08:52:46 -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.11/8.12.9) with ESMTP id i7DFqjpO030219 for ; Fri, 13 Aug 2004 08:52:46 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:56:55 +0100 Message-ID: <411CE3CE.1000905@isode.com> Date: Fri, 13 Aug 2004 16:52:46 +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: Nicolas Williams CC: ietf-sasl@imc.org Subject: Re: Does rfc2222bis need text on channel bindings? References: <20040813004713.GJ892@binky.central.sun.com> In-Reply-To: <20040813004713.GJ892@binky.central.sun.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: Nicolas Williams wrote: >I figure the new SASL GSS mech document will say something about channel >bindings, but perhaps rfc2222bis should also. > >Specifically I think that rfc2222bis could use: > >a) Security Considerations text about use of mechanisms that don't > support channel bindings in conjunction with TLS. > > Clients should be admonished to validate TLS server IDs to prevent > MITM attacks when using SASL-over-TLS. Similarly with other variants > of SASL-over-TLS. > I suspect you mean "SASL-over-". > SACRED is an example of an application where such text could be > useful. > >b) Text recommending support for channel bindings in future mechanisms, > where possible. Digest-MD5, for example, could easily support > channel bindings. > If you mean that it can be easily extended, then I agree. >Comments? Shall I just send proposed text to the list? > Please do. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFFKjk025988; Fri, 13 Aug 2004 08:15:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFFKt2025987; Fri, 13 Aug 2004 08:15:20 -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.11/8.12.9) with ESMTP id i7DFFJiI025981 for ; Fri, 13 Aug 2004 08:15: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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:19:10 +0100 Message-ID: <411CDAF2.4070804@isode.com> Date: Fri, 13 Aug 2004 16:14:58 +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 To: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.edu> MIME-version: 1.0 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: > On Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" > wrote: > >>> So, the client has violated SHOULD and the server is treating SHOULD as >>> MUST. >> >> No, the server is treating the client provided realm as invalid and >> hence >> the exchange fails. The server behavior is proper. > > Put another way... > > The server is not rejecting the exchange because it thinks the client > has violated the protocol. It's doing so based on policy -- the > client provided a name in bar.example.com, and the server is only > willing to deal with clients in test.example.com. This make sense. But in case of CMU SASL the realm value doesn't matter, it is only used for constructing the authentication verifier. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFCwc8025731; Fri, 13 Aug 2004 08:12:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFCwc2025730; Fri, 13 Aug 2004 08:12:58 -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.11/8.12.9) with ESMTP id i7DFCubb025717 for ; Fri, 13 Aug 2004 08:12:57 -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 (internal) with ESMTPA; Fri, 13 Aug 2004 16:16:45 +0100 Message-ID: <411CDA64.6080408@isode.com> Date: Fri, 13 Aug 2004 16:12: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: Jeffrey Hutzelman CC: "Kurt D. Zeilenga" , SASL WG Subject: Re: DIGEST-MD5 interop issue References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <1307320000.1092408691@minbar.fac.cs.cmu.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: Jeffrey Hutzelman wrote: > The reason for the SHOULD is that the server has indicated which > realms it is willing/able to accept, and it's expected that the server > will usually reject any other realms. One problem with the DIGEST-MD5 spec I can see is that there is no way for the server to tell whether it only accepts certain realms or whether it will accept any realms. There are servers that implement either policy. Servers that implement the latter policy can accept authentication for any realm and will try to proxy authenticate if possible. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DEqArs017759; Fri, 13 Aug 2004 07:52:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DEqA5r017758; Fri, 13 Aug 2004 07:52:10 -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.11/8.12.9) with SMTP id i7DEq9pO017732 for ; Fri, 13 Aug 2004 07:52:09 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30845; 13 Aug 2004 10:51 EDT Date: Fri, 13 Aug 2004 10:51:31 -0400 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Alexey Melnikov cc: SASL WG Subject: Re: DIGEST-MD5 interop issue Message-ID: <1307320000.1092408691@minbar.fac.cs.cmu.edu> In-Reply-To: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> References: <411BAC01.7040407@isode.com> <6.1.2.0.0.20040812221801.07e9b3c8@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 Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" wrote: >> So, the client has violated SHOULD and the server is treating SHOULD as >> MUST. > > No, the server is treating the client provided realm as invalid and hence > the exchange fails. The server behavior is proper. Put another way... The server is not rejecting the exchange because it thinks the client has violated the protocol. It's doing so based on policy -- the client provided a name in bar.example.com, and the server is only willing to deal with clients in test.example.com. The reason for the SHOULD is that the server has indicated which realms it is willing/able to accept, and it's expected that the server will usually reject any other realms. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DARuZp030020; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DARuBh030019; Fri, 13 Aug 2004 03:27:56 -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.11/8.12.9) with ESMTP id i7DARu9n030009 for ; Fri, 13 Aug 2004 03:27:56 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DARpMw014819; Fri, 13 Aug 2004 10:27:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813122737.085d65d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 12:28:27 +0200 To: hartmans@mit.edu (Sam Hartman) From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: confidentiality and integrity Cc: ietf-sasl@imc.org In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> References: <20040812191537.627641602F9@cz.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: I support this suggestion. The subsequent sentence is sufficent to suggest other kinds (including poorly designed :-) layers may be supported. At 09:15 PM 8/12/2004, Sam Hartman wrote: >Hi. There's another change I thought would be editorial but >apparently is not. The document currently says in section 1 that >confidentiality protection usually implies integrity protection. > >This seems less than ideal from a security standpoint. I believe that >applications need to be able to depend on the fact that >confidentiality protection comes along with integrity protection. > >I propose to drop the word usually. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALHvb028425; Fri, 13 Aug 2004 03:21:17 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALHWb028424; Fri, 13 Aug 2004 03:21:17 -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.11/8.12.9) with ESMTP id i7DALGMF028418 for ; Fri, 13 Aug 2004 03:21:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN2014781 for ; Fri, 13 Aug 2004 10:21:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040813082412.081cbe20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:34:04 +0200 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: 2222bis: identities and authorization 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 have completed my review of draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor editorial comments (which I have separately sent to the Editor). This note discussions problems I found related to identities and authorization. The 'Authorization and authentication identities' section (3.2) starts off by stating that 'SASL authentication deals with two identities' but then describes the processing model to involve three identities, two of which it simply refers to as 'authorization' identities. I believe we either need better distinguish these identities within the document, by through qualification (proxy authorization identity v. application authorization identity) or by use of replacement terminology (proxied identity v. authorization identity). I prefer the latter approach as the former qualifications are themselves a bit confused and the latter seems more in step with RFC 2828. I am willing to prepare replacement text for consideration. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DALBSH028402; Fri, 13 Aug 2004 03:21:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DALBcn028401; Fri, 13 Aug 2004 03:21:11 -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.11/8.12.9) with ESMTP id i7DAL9rM028377 for ; Fri, 13 Aug 2004 03:21:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7DAKnN0014781; Fri, 13 Aug 2004 10:21:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040812221801.07e9b3c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 13 Aug 2004 09:32:05 +0200 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: DIGEST-MD5 interop issue Cc: SASL WG In-Reply-To: <411BAC01.7040407@isode.com> References: <411BAC01.7040407@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 07:42 PM 8/12/2004, Alexey Melnikov wrote: >Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: > >While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. >I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as >"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). > >At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): > >>realm >>The realm containing the user's account, encoded according to the value of the "charset" directive. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and its value SHOULD be one of those realms. If the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details). > > >So, the client has violated SHOULD and the server is treating SHOULD as MUST. No, the server is treating the client provided realm as invalid and hence the exchange fails. The server behavior is proper. >So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. > >There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, This is real issue. >instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. Exactly, the client is making assumptions which prevent users from being able to use it with independently developed servers. A client which cannot handle the full range of identity and realm values is simply broken. For instance, my DIGEST-MD5 authentication identity is kurt@openldap.org in the realm project@OPENLDAP.ORG. I would not be able to use this or like clients. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2Ehe9061126; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D2Ehdf061125; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (HOTASS-5.MIT.EDU [18.101.1.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2EgfO061117 for ; Thu, 12 Aug 2004 19:14:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id BAF13E0036; Thu, 12 Aug 2004 22:14:51 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity References: <20040812191537.627641602F9@cz.mit.edu> <20040813004209.GI892@binky.central.sun.com> From: Sam Hartman Date: Thu, 12 Aug 2004 22:14:51 -0400 In-Reply-To: <20040813004209.GI892@binky.central.sun.com> (Nicolas Williams's message of "Thu, 12 Aug 2004 19:42:09 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> If there are any mechanisms that provide confidentiality Nicolas> protection without providing integrity protection then I Nicolas> propose: a) that rfc2222bis identify such mechanisms, b) Nicolas> say new mechs MUST NOT do such Bad Things. I know of no such mechanisms. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0npBt053683; Thu, 12 Aug 2004 17:49:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0npT5053682; Thu, 12 Aug 2004 17:49: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-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0nplN053675 for ; Thu, 12 Aug 2004 17:49:51 -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 i7D0nqJ6010211 for ; Thu, 12 Aug 2004 17:49:52 -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 i7D0npUT021379 for ; Thu, 12 Aug 2004 18:49:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0lDXP018321 for ; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0lDFv018320 for ietf-sasl@imc.org; Thu, 12 Aug 2004 19:47:13 -0500 (CDT) Date: Thu, 12 Aug 2004 19:47:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Does rfc2222bis need text on channel bindings? Message-ID: <20040813004713.GJ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I figure the new SASL GSS mech document will say something about channel bindings, but perhaps rfc2222bis should also. Specifically I think that rfc2222bis could use: a) Security Considerations text about use of mechanisms that don't support channel bindings in conjunction with TLS. Clients should be admonished to validate TLS server IDs to prevent MITM attacks when using SASL-over-TLS. Similarly with other variants of SASL-over-TLS. SACRED is an example of an application where such text could be useful. b) Text recommending support for channel bindings in future mechanisms, where possible. Digest-MD5, for example, could easily support channel bindings. Comments? Shall I just send proposed text to the list? Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0imt5053291; Thu, 12 Aug 2004 17:44:48 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0im52053290; Thu, 12 Aug 2004 17:44:48 -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.11/8.12.9) with ESMTP id i7D0imac053281 for ; Thu, 12 Aug 2004 17:44:48 -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 i7D0inJ6008666 for ; Thu, 12 Aug 2004 17:44:49 -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 i7D0imUT019792 for ; Thu, 12 Aug 2004 18:44:48 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7D0gALO018314; Thu, 12 Aug 2004 19:42:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7D0g93e018313; Thu, 12 Aug 2004 19:42:09 -0500 (CDT) Date: Thu, 12 Aug 2004 19:42:09 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: rfc2222bis: confidentiality and integrity Message-ID: <20040813004209.GI892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040812191537.627641602F9@cz.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812191537.627641602F9@cz.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 12, 2004 at 03:15:37PM -0400, Sam Hartman wrote: > > > Hi. There's another change I thought would be editorial but > apparently is not. The document currently says in section 1 that > confidentiality protection usually implies integrity protection. > > This seems less than ideal from a security standpoint. I believe that > applications need to be able to depend on the fact that > confidentiality protection comes along with integrity protection. If there are any mechanisms that provide confidentiality protection without providing integrity protection then I propose: a) that rfc2222bis identify such mechanisms, b) say new mechs MUST NOT do such Bad Things. > I propose to drop the word usually. Yes. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFUeT017060; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJFULP017059; Thu, 12 Aug 2004 12:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (STRATTON-FOUR-SEVENTY-SIX.MIT.EDU [18.187.6.221]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFTWw017053 for ; Thu, 12 Aug 2004 12:15:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 627641602F9; Thu, 12 Aug 2004 15:15:37 -0400 (EDT) To: ietf-sasl@imc.org Subject: rfc2222bis: confidentiality and integrity Message-Id: <20040812191537.627641602F9@cz.mit.edu> Date: Thu, 12 Aug 2004 15:15:37 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. There's another change I thought would be editorial but apparently is not. The document currently says in section 1 that confidentiality protection usually implies integrity protection. This seems less than ideal from a security standpoint. I believe that applications need to be able to depend on the fact that confidentiality protection comes along with integrity protection. I propose to drop the word usually. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHgXrr005758; Thu, 12 Aug 2004 10:42:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHgXhe005757; Thu, 12 Aug 2004 10:42:33 -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.11/8.12.9) with ESMTP id i7CHgWgo005748 for ; Thu, 12 Aug 2004 10:42:32 -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 (internal) with ESMTPA; Thu, 12 Aug 2004 18:46:33 +0100 Message-ID: <411BAC01.7040407@isode.com> Date: Thu, 12 Aug 2004 18:42:25 +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: DIGEST-MD5 interop issue 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: Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs: While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com. I've entered a username "foo@bar.example.com" in the client and the client has sent this to the server as "username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com"). At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server): >realm > >The realm containing the user's account, encoded according to the >value of the "charset" directive. This directive is required >if the server provided any realms in the "digest-challenge", in which case it >may appear exactly once and its value SHOULD be one of those realms. If the >directive is missing, "realm-value" will set to the empty string when >computing A1 (see below for details). So, the client has violated SHOULD and the server is treating SHOULD as MUST. So arguably this is a server problem, although the client shouldn't assume that it knows better about which realms are supported by the server. There is another issue here: the client has split "foo@bar.example.com" into username and realm parts, instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server. I have a reason to believe that the client is using a library implementing DIGEST-MD5, which is widely deployed. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C8U078098182; Thu, 12 Aug 2004 01:30:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C8U0Fj098181; Thu, 12 Aug 2004 01:30:00 -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.11/8.12.9) with ESMTP id i7C8U0kg098169 for ; Thu, 12 Aug 2004 01:30:00 -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 i7C8Tt0R016834 for ; Thu, 12 Aug 2004 01:29:55 -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 i7C8TtUT027964 for ; Thu, 12 Aug 2004 02:29:55 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C8RHfS007662; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C8RHdh007661; Thu, 12 Aug 2004 03:27:17 -0500 (CDT) Date: Thu, 12 Aug 2004 03:27:17 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis Message-ID: <20040812082717.GO892@binky.central.sun.com> Mail-Followup-To: Sam Hartman , ietf-sasl@imc.org References: <20040807000913.GZ892@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.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Aug 11, 2004 at 05:27:32PM -0400, Sam Hartman wrote: > > I'm a bit uncomfortable saying that SASL mechanisms should support > rekeying. I'm not sure that the community understands what this would > mean well enough that mechanisms would converge on solutions with > similar properties. Ok, how about this: SASL mechanisms that support re-keying SHOULD: - indicate that re-keying is or will be needed immediately; - provide re-keying messages or transparently include re-keying messages in the security layers; the latter can happen without application involvement, but only as long as the application is engaged in timely bidirectional exchanges with its peer. > > Also, do we want to point out that for interop reasons SASL mechanisms > may want to provide advisory notice that rekeying is necessary rather > than invalidating security contexts. I'm particularly concerned about > the transferring large file case. I sympathize. I don't mind seeing text in rfc2222bis about advisory vs. mandatory security layer expiration. But I think that text about this that is specific to the GSS mechanisms seems well beyond the scope of rfc2222bis. Suggestions? Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRT6N092382; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLRTXh092381; Wed, 11 Aug 2004 14:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRSTI092373 for ; Wed, 11 Aug 2004 14:27:28 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 93ED5E003D; Wed, 11 Aug 2004 17:27:32 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Text on re-keying for rfc2222bis References: <20040807000913.GZ892@binky.central.sun.com> From: Sam Hartman Date: Wed, 11 Aug 2004 17:27:32 -0400 In-Reply-To: <20040807000913.GZ892@binky.central.sun.com> (Nicolas Williams's message of "Fri, 6 Aug 2004 19:09:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: I'm a bit uncomfortable saying that SASL mechanisms should support rekeying. I'm not sure that the community understands what this would mean well enough that mechanisms would converge on solutions with similar properties. Also, do we want to point out that for interop reasons SASL mechanisms may want to provide advisory notice that rekeying is necessary rather than invalidating security contexts. I'm particularly concerned about the transferring large file case. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH8d0079107; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BJH8GM079106; Wed, 11 Aug 2004 12:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJH7Cu079100 for ; Wed, 11 Aug 2004 12:17:07 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id D2CEB1602F7; Wed, 11 Aug 2004 15:17:07 -0400 (EDT) To: ietf-sasl@imc.org Subject: Comments on draft-ietf-sasl-rfc2222bis.txt Message-Id: <20040811191707.D2CEB1602F7@cz.mit.edu> Date: Wed, 11 Aug 2004 15:17:07 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2, the draft claims that the layer does not generally hide the details of mechanisms from protocols. I actually believe the statement we want to be making is that while the layer hides the details of protocols from mechanisms and the details of mechanisms from protocols, it does not hide the details of mechanisms from protocol implementations. In particular, I consider it a requirement to be able to specify a SASL binding to a protocol without thinking about mechanism details. I believe this requirement is met by the base spec. However actually implementing this protocol spec for a particular mechanism requires the server and client to be aware of the mechanism details. I would not in general consider it acceptable for mechanism specifications to place requirements on protocol specifications. Besides this concern and some editorial issues I've sent to the editor, I have read this document and believe it is of high quality. As a chair however, I believe we still have not received sufficient review to publish the document. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BE7Y7a046659; Wed, 11 Aug 2004 07:07:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BE7YEN046658; Wed, 11 Aug 2004 07:07:34 -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.11/8.12.9) with ESMTP id i7BE7SP8046560 for ; Wed, 11 Aug 2004 07:07:29 -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 (internal) with ESMTPA; Wed, 11 Aug 2004 15:11:11 +0100 Message-ID: <411A280D.5080404@isode.com> Date: Wed, 11 Aug 2004 15:07:09 +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: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: SASL working group summary for IETF 60 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: Simon Josefsson wrote: >Sam Hartman writes: > > >>There was discussion of the GSSAPI mechanism. everyone agrees we need >>to maintain compatibility with the widely deployed Kerberos 5 >>mechanism. Sam Hartman proposed significant changes to other GSSAPI >>SASL mechanisms for improved efficiency. One reason we may want this >>change is HTTP SASL. Discussion will continue on the list. >> >> > >How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" >document, and one document for the generic "GSS-*" mechanism set? If >the protocol for "GSS-*" will be different from the "GSSAPI" protocol, >perhaps it doesn't make sense to describe both in the same document. >It might also help focus on making the "GSS-*" protocol better, >without having to pay attention to Kerberos 5 specific issues. > This is pretty much what I've suggested. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i770BjYF077525; Fri, 6 Aug 2004 17:11:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i770BjAV077524; Fri, 6 Aug 2004 17:11:45 -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.11/8.12.9) with ESMTP id i770BjZj077514 for ; Fri, 6 Aug 2004 17:11:45 -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 i770BkJ6007146 for ; Fri, 6 Aug 2004 17:11:46 -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 i770BjDi008488 for ; Fri, 6 Aug 2004 18:11:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7709DTP005761 for ; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7709DCZ005760 for ietf-sasl@imc.org; Fri, 6 Aug 2004 19:09:13 -0500 (CDT) Date: Fri, 6 Aug 2004 19:09:13 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: Text on re-keying for rfc2222bis Message-ID: <20040807000913.GZ892@binky.central.sun.com> Mail-Followup-To: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Diffs for section 6.3: --- /tmp/sasl-6.3-orig Fri Aug 6 19:08:10 2004 +++ /tmp/sasl-6.3 Fri Aug 6 19:08:00 2004 @@ -1,5 +1,6 @@ + 6.3. Multiple authentications Unless otherwise stated by the protocol's profile, only one successful SASL negotiation may occur in a protocol session. In this case, once an authentication protocol exchange has successfully @@ -8,18 +9,22 @@ If a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. 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 remains in effect. + second security layer replaces the first; this can be used as a form + of re-keying, where SASL mechanisms that provide security layers fail + to provide for re-keying, provided that the authenticated identities + remain the same. If a security layer is in effect and a subsequent + SASL negotiation selects no security layer, the original security + layer remains in effect. Where a protocol profile permits multiple successful SASL negotiations, the profile MUST detail the effect of a failed SASL negotiation upon the previously established authentication state. In particular, it MUST state whether the previously established authenticated state remain in force or whether the connection is to revert to an non-authenticated state. Regardless of the specified effect upon authentication state, the previously negotiated security layer remains in effect. + New text for the security considerations section: The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. The use of cryptographic keys and the passage of time after the initial use of a cryptographic key weakens said keys by increasing the amount of ciphertext, other cryptographic material, and/or time that is available to cryptanalysts in any effort to attack the security layers. Administrative limits on security layers lifetime may take the form of time limits expressed in x.509 certificates, Kerberos V tickets, or in directories, and are often desired. In practice one likely effect of administrative security layers lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. SASL does not provide for re-keying. SASL mechanisms may; all future SASL mechanisms that provide security layers SHOULD provide for re-keying. Applications that wish to re-key SASL security layers where the mechanism does not provide for re-keying should re-authenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for re-keying in the application protocols. See section 6.3. Sorry for the delay. Nico -- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7eqR021631; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74M7eVU021630; Wed, 4 Aug 2004 15:07:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M7cdp021624 for ; Wed, 4 Aug 2004 15:07:39 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BsTvD-0005VW-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 00:07:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASL working group summary for IETF 60 Date: Thu, 05 Aug 2004 00:07:38 +0200 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:1UGFIBfleUZDGUKIZYN4HerfHRM= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > There was discussion of the GSSAPI mechanism. everyone agrees we need > to maintain compatibility with the widely deployed Kerberos 5 > mechanism. Sam Hartman proposed significant changes to other GSSAPI > SASL mechanisms for improved efficiency. One reason we may want this > change is HTTP SASL. Discussion will continue on the list. How about forking the GSSAPI document into one Kerberos 5 "GSSAPI" document, and one document for the generic "GSS-*" mechanism set? If the protocol for "GSS-*" will be different from the "GSSAPI" protocol, perhaps it doesn't make sense to describe both in the same document. It might also help focus on making the "GSS-*" protocol better, without having to pay attention to Kerberos 5 specific issues. Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaVRs019191; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74LaVHD019190; Wed, 4 Aug 2004 14:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-130-188.ietf60.ietf.org [130.129.130.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LaUWO019184 for ; Wed, 4 Aug 2004 14:36:30 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id 762741608F7; Wed, 4 Aug 2004 17:35:06 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: SASL working group summary for IETF 60 From: Sam Hartman Date: Wed, 04 Aug 2004 17:35:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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: The SASL working group met for one hour. The SASL base spec (draft-ietf-sasl-rfc2222bis) is in last call. We need more review of this document; without this review the chairs will be unable to recommend the document for publication. Nicolas Williams will provide security considerations text for rekeying to be considered by the group. Not much progress has been made on digest-md5 since the last IETF. The explicit IV issues for CBC have been discussed but are still open. The character set conversion issues are still open although there is still a possibility we will be able to move exclusively to UTF8. At least two more revisions of the draft are expected. There was discussion of the GSSAPI mechanism. everyone agrees we need to maintain compatibility with the widely deployed Kerberos 5 mechanism. Sam Hartman proposed significant changes to other GSSAPI SASL mechanisms for improved efficiency. One reason we may want this change is HTTP SASL. Discussion will continue on the list. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw68L078968; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Gw6Sa078967; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from cz.mit.edu (opene-130-129-129-194.ietf60.ietf.org [130.129.129.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gw5Vm078961 for ; Tue, 3 Aug 2004 09:58:06 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by cz.mit.edu (Postfix, from userid 8042) id DD0EC160487; Tue, 3 Aug 2004 12:56:34 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: GSSAPI direction References: <20040721163835.96C90E0052@cz.mit.edu> <4104263B.2000707@isode.com> From: Sam Hartman Date: Tue, 03 Aug 2004 12:56:34 -0400 In-Reply-To: <4104263B.2000707@isode.com> (Alexey Melnikov's message of "Sun, 25 Jul 2004 22:29:31 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (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> I don't mind the changes you are proposing (at least I Alexey> agree with their motivation), however this suggestion is a Alexey> bit late and I would like to point out that there several Alexey> independent implementations of GSSAPI (Kerberos) mechanism Alexey> that interoperate well (at least better than DIGEST-MD5). We cannot make these changes for the SASL mechanism called GSSAPI; that seems clear.