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 j9SMUGGZ045698; Fri, 28 Oct 2005 15:30:16 -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 j9SMUGDC045697; Fri, 28 Oct 2005 15:30:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9SMUF1Y045691 for ; Fri, 28 Oct 2005 15:30:16 -0700 (PDT) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j9SMUDP0029136 for ; Fri, 28 Oct 2005 18:30:14 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j9SMUA6P009984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2005 18:30:11 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j9SMUAwa005649; Fri, 28 Oct 2005 18:30:10 -0400 (EDT) To: ietf-sasl@imc.org Subject: IETF64 SASL draft agenda From: Tom Yu Date: Fri, 28 Oct 2005 18:30:10 -0400 Message-ID: Lines: 6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've uploaded a draft agenda. Please let me know if you have any comments or suggestions about it. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 ---Tom 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 j9RL602l068846; Thu, 27 Oct 2005 14:06: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 j9RL60MN068845; Thu, 27 Oct 2005 14:06:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RL5xcH068838 for ; Thu, 27 Oct 2005 14:05:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j9RL5wXj054162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Oct 2005 21:05:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051027135926.08eef248@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 27 Oct 2005 14:05:31 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In this revision, a few minor changes were made to improve clarify of specification. Please review and comment. For any issue you raise, please offer specific suggestions (e.g., replacement text) as to how to address the issue for WG consideration. Thanks, Kurt At 03:50 PM 10/26/2005, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) > Author(s) : A. Melnikov, K. Zeilenga > Filename : draft-ietf-sasl-rfc2222bis-12.txt > Pages : 29 > Date : 2005-10-26 > >The Simple Authentication and Security Layer (SASL) is a framework for > providing authentication and data security services in > connection-oriented protocols via replaceable mechanisms. It provides > a structured interface between protocols and mechanisms. The > resulting framework allows new protocols to reuse existing mechanisms > and allows old protocols to make use of new mechanisms. The framework > also provides a protocol for securing subsequent protocol exchanges > within a data security layer. > > This document describes how a SASL mechanism is structured, describes > how protocols include support for SASL, and defines the protocol for > carrying a data security layer over a connection. Additionally, this > document defines one SASL mechanism, the EXTERNAL mechanism. > > This document obsoletes RFC 2222. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-rfc2222bis-12.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2005-10-26172249.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt > > > 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 j9RJo4rW056968; Thu, 27 Oct 2005 12:50:04 -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 j9RJo4Rm056967; Thu, 27 Oct 2005 12:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJo3JN056959 for ; Thu, 27 Oct 2005 12:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlC-0006PF-Fy; Thu, 27 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-07.txt Message-Id: Date: Thu, 27 Oct 2005 15:50:02 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, et al. Filename : draft-ietf-sasl-rfc2831bis-07.txt Pages : 45 Date : 2005-10-27 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27105905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27105905.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 j9R0sPIH037902; Wed, 26 Oct 2005 17:54: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 j9R0sPxt037901; Wed, 26 Oct 2005 17:54:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9R0sOwO037895 for ; Wed, 26 Oct 2005 17:54:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j9R0sNcm048430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 00:54:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051026175037.067d83e0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 26 Oct 2005 17:53:57 -0700 To: pet@itbridge.net From: "Kurt D. Zeilenga" Subject: Re: SASL with user name as email address Cc: ietf-sasl@imc.org In-Reply-To: <435E54F6.5080007@itbridge.net> References: <435E54F6.5080007@itbridge.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:53 AM 10/25/2005, Burdík Petr wrote: >I use saslauthd to autentication smtpauth, cyrus-imap. Backend is LDAP. I have problem with autentication of cyrus-imap, because I use virtualdomains users name as mail address. My username is such as user1@domain.tld. When I test it with testsaslauthd , its ok. When I test it with connect across cyrus-imap server, cyrus-imap server sends it as user=user1 & realm=domain.tld to saslauthd. It don't find user1. Exist some way to force cyrus-imap server don't partition username to user & realm? Please note that this list is for discussing the standardization of SASL, not the particulars of any given SASL implementation. Hence, it appears your message would be more appropriately directed to a list about Cyrus SASL, such as . More information about the Cyrus SASL list can be found at: . Kurt, IETF SASL WG co-chair 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 j9QMo390025351; Wed, 26 Oct 2005 15:50: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 j9QMo2iu025350; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QMo2SX025341 for ; Wed, 26 Oct 2005 15:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5q-0005b6-6Q; Wed, 26 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt Message-Id: Date: Wed, 26 Oct 2005 18:50:02 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov, K. Zeilenga Filename : draft-ietf-sasl-rfc2222bis-12.txt Pages : 29 Date : 2005-10-26 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. Additionally, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26172249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26172249.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 j9PFrjH9018008; Tue, 25 Oct 2005 08:53: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 j9PFrjPB018007; Tue, 25 Oct 2005 08:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pgw.itbridge.net (unreal.adam.cz [81.0.224.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PFried017993 for ; Tue, 25 Oct 2005 08:53:45 -0700 (PDT) (envelope-from pet@itbridge.net) Received: from [10.1.1.200] (unknown [10.1.1.200]) by pgw.itbridge.net (Postfix) with ESMTP id 9A45C7318 for ; Tue, 25 Oct 2005 19:46:23 +0200 (CEST) Message-ID: <435E54F6.5080007@itbridge.net> Date: Tue, 25 Oct 2005 17:53:26 +0200 From: =?UTF-8?B?QnVyZMOtayBQZXRy?= Reply-To: pet@itbridge.net Organization: IT bridge.net s.r.o. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: SASL with user name as email address Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I use saslauthd to autentication smtpauth, cyrus-imap. Backend is LDAP. I have problem with autentication of cyrus-imap, because I use virtualdomains users name as mail address. My username is such as user1@domain.tld. When I test it with testsaslauthd , its ok. When I test it with connect across cyrus-imap server, cyrus-imap server sends it as user=user1 & realm=domain.tld to saslauthd. It don't find user1. Exist some way to force cyrus-imap server don't partition username to user & realm? Pet 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 j9OBBXS9046263; Mon, 24 Oct 2005 04:11: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 j9OBBXAf046262; Mon, 24 Oct 2005 04:11: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 j9OBBVvZ046253 for ; Mon, 24 Oct 2005 04:11:32 -0700 (PDT) (envelope-from alexey.melnikov@isode.com) Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 Oct 2005 12:11:18 +0100 Message-ID: <435CC154.5070504@isode.com> Date: Mon, 24 Oct 2005 12:11:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: Update to DIGEST-MD5 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: Hi folks, I've just posted -07. Here is the list of major changes: 1). Removed 'AES in CBC mode with explicit IV in a separate block' proposal. 2). Added text about channel bindings. Updated ABNF as the result. Pending changes: 1). AES in Counter mode. 2). Replace HTTP ABNF with regular ABNF. Regards, 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 j9MI8Wv4087377; Sat, 22 Oct 2005 11:08: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 j9MI8WHF087376; Sat, 22 Oct 2005 11:08:32 -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 j9MI8UUo087369 for ; Sat, 22 Oct 2005 11:08:31 -0700 (PDT) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.115] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 22 Oct 2005 19:08:22 +0100 Message-ID: <435A8015.2090703@isode.com> Date: Sat, 22 Oct 2005 19:08:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Yu CC: ietf-sasl@imc.org Subject: Re: IETF64 SASL call for agenda items 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: Tom Yu wrote: >Hi, > >If you have particular items you would like to discuss at the IETF64 >SASL WG session, please let me know. I would like to post a draft >schedule before the end of this week. > I suggest we go through the list of [smaller] open issues for DIGEST-MD5 and base spec and do a live editing session. 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 j9J35pg9058992; Tue, 18 Oct 2005 20:05: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 j9J35p5B058991; Tue, 18 Oct 2005 20:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9J35oqO058985 for ; Tue, 18 Oct 2005 20:05:50 -0700 (PDT) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j9J35mml028911 for ; Tue, 18 Oct 2005 23:05:48 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j9J2w5vI018522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Oct 2005 22:58:06 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j9J2w5I6021806; Tue, 18 Oct 2005 22:58:05 -0400 (EDT) To: ietf-sasl@imc.org Subject: IETF64 SASL call for agenda items From: Tom Yu Date: Tue, 18 Oct 2005 22:58:05 -0400 Message-ID: Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, If you have particular items you would like to discuss at the IETF64 SASL WG session, please let me know. I would like to post a draft schedule before the end of this week. ---Tom 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 j9CNmcNw084477; Wed, 12 Oct 2005 16:48: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 j9CNmcTa084476; Wed, 12 Oct 2005 16:48:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CNmbDE084469 for ; Wed, 12 Oct 2005 16:48:37 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.homeunix.org (d64-180-189-53.bchsia.telus.net [64.180.189.53]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j9CNmU99024074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 17:48:31 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.homeunix.org (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id j9CNmTBk027094; Wed, 12 Oct 2005 16:48:29 -0700 (PDT) In-Reply-To: <6.2.1.2.0.20051012151845.06ac3010@mail.openldap.org> References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> <6.2.1.2.0.20051012143708.0694c2a8@mail.openldap.org> <4C90E0DC-75CF-4096-BBD8-E2B7E05D68BE@orthanc.ca> <6.2.1.2.0.20051012151845.06ac3010@mail.openldap.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D48EFB4-C6D8-4CE6-A036-CB6CE65927DD@orthanc.ca> Cc: ietf-sasl@imc.org Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Date: Wed, 12 Oct 2005 16:48:28 -0700 To: "Kurt D. Zeilenga" X-Mailer: Apple Mail (2.734) X-DCC-neonova-Metrics: orthanc.ca 1127; Body=2 Fuz1=2 Fuz2=2 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 12, 2005, at 3:31 PM, Kurt D. Zeilenga wrote: > Please note that I did not state that we should mandate use > of TLS. I stated we should mandate implementations of > CRAM-MD5 support its use with TLS. Sorry, I thought you were saying that CRAM-MD5 should only be allowed under an encrypted TLS session (like the AUTH PLAIN restriction in the current IMAP specification). --lyndon 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 j9CMWAgq078838; Wed, 12 Oct 2005 15:32: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 j9CMWAhC078837; Wed, 12 Oct 2005 15:32:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CMW96H078829 for ; Wed, 12 Oct 2005 15:32:09 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j9CMW8on012435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 22:32:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051012151845.06ac3010@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 12 Oct 2005 15:31:43 -0700 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Cc: Chris Newman , ietf-sasl@imc.org In-Reply-To: <4C90E0DC-75CF-4096-BBD8-E2B7E05D68BE@orthanc.ca> References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> <6.2.1.2.0.20051012143708.0694c2a8@mail.openldap.org> <4C90E0DC-75CF-4096-BBD8-E2B7E05D68BE@orthanc.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: Lyndon, Please note that I did not state that we should mandate use of TLS. I stated we should mandate implementations of CRAM-MD5 support its use with TLS. I also note that the IETF has no authority. The terms 'require' and 'mandate' are only used to indicate what we believe implementations are to support to be considered conformant with our specification, they are not intended to imply that the IETF would take some action against them if they were not to heed our requirements. Given recent discussions within the security and applications area, I suspect that any revision of CRAM-MD5 specification which did not address well the known security issues with this mechanism would fall to obtain necessary consensus for publication on the standards track. One possible way to address these issues is by limiting the applicability of the mechanism (though I have my doubts that such an applicability statement would fly). Kurt At 03:13 PM 10/12/2005, Lyndon Nerenberg wrote: >On Oct 12, 2005, at 2:45 PM, Kurt D. Zeilenga wrote: > >>Do we >>see value in specifying a CRAM-MD5 mechanism that >>requires implementors to support its use with TLS? > >I am against this. Only the application knows if the data stream >needs to be encrypted. > >I'm working on quite a few projects right now where I need non- plaintext authentication, so that I can show that a specific entity >was connected to a service at a specific time, but the value of the >data itself doesn't justify encryption. But even more importantly, >by law I *cannot* encrypt the data stream, so any mechanism that >mandates it is a non-starter. CRAM-MD5 fits this role perfectly. > >While I admire the IETF wanting to enhance security, we really have >to be careful not to start acting too authoritarian. We're here to >provide tools, not mandate behaviour. SASL mechanisms are tools that >provide varying levels and types of security. It's not up to this WG >to dictate to the world the specific instances where they can or >cannot be used. (But it *is* our responsibility to give *guidance* >on when it is -- and is not -- appropriate to use a particular >mechanism.) > >--lyndon 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 j9CMDglY077308; Wed, 12 Oct 2005 15:13:42 -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 j9CMDg51077306; Wed, 12 Oct 2005 15:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CMDf1A077300 for ; Wed, 12 Oct 2005 15:13:42 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.homeunix.org (d64-180-189-53.bchsia.telus.net [64.180.189.53]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j9CMDWXj023630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 16:13:37 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.homeunix.org (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id j9CMDPQP027054; Wed, 12 Oct 2005 15:13:29 -0700 (PDT) In-Reply-To: <6.2.1.2.0.20051012143708.0694c2a8@mail.openldap.org> References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> <6.2.1.2.0.20051012143708.0694c2a8@mail.openldap.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C90E0DC-75CF-4096-BBD8-E2B7E05D68BE@orthanc.ca> Cc: Chris Newman , ietf-sasl@imc.org Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Date: Wed, 12 Oct 2005 15:13:23 -0700 To: "Kurt D. Zeilenga" X-Mailer: Apple Mail (2.734) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 12, 2005, at 2:45 PM, Kurt D. Zeilenga wrote: > Do we > see value in specifying a CRAM-MD5 mechanism that > requires implementors to support its use with TLS? I am against this. Only the application knows if the data stream needs to be encrypted. I'm working on quite a few projects right now where I need non- plaintext authentication, so that I can show that a specific entity was connected to a service at a specific time, but the value of the data itself doesn't justify encryption. But even more importantly, by law I *cannot* encrypt the data stream, so any mechanism that mandates it is a non-starter. CRAM-MD5 fits this role perfectly. While I admire the IETF wanting to enhance security, we really have to be careful not to start acting too authoritarian. We're here to provide tools, not mandate behaviour. SASL mechanisms are tools that provide varying levels and types of security. It's not up to this WG to dictate to the world the specific instances where they can or cannot be used. (But it *is* our responsibility to give *guidance* on when it is -- and is not -- appropriate to use a particular mechanism.) --lyndon 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 j9CLkPbH075556; Wed, 12 Oct 2005 14:46: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 j9CLkPD6075555; Wed, 12 Oct 2005 14:46:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CLkPhj075548 for ; Wed, 12 Oct 2005 14:46:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j9CLkOHl009902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 21:46:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20051012143708.0694c2a8@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 12 Oct 2005 14:45:59 -0700 To: Chris Newman From: "Kurt D. Zeilenga" Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Cc: Lyndon Nerenberg , ietf-sasl@imc.org In-Reply-To: <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> 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 10:52 AM 10/12/2005, Chris Newman wrote: >Until a suitable replacement is found, I agree it is premature to move CRAM-MD5 to historic. While I tend to agree that its premature to move CRAM-MD5 to historic, I feel that CRAM-MD5 is not suitable for continued standardization as currently specified and implemented. In particular, the current specification and implementations offer no facility for detecting high-attacks (e.g., data integrity protection), without any facility for prevention of offline dictionary attacks (confidential protection of the authentication exchange). So, to me, the question is whether to simply document existing practice and its pitfalls as Informational, or revise the mechanism specification to address these and other concerns (such as internationalization) for publication on the Standards Track. Do we see value in specifying a CRAM-MD5 mechanism that requires implementors to support its use with TLS? If not, than we should opt to just detail existing practice and not the security concerns. 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 j9CII3cb053522; Wed, 12 Oct 2005 11:18: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 j9CII3ox053521; Wed, 12 Oct 2005 11:18:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CII21B053514 for ; Wed, 12 Oct 2005 11:18:02 -0700 (PDT) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j9CII0eh004719 for ; Wed, 12 Oct 2005 14:18:01 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j9CIHrVv000288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2005 14:17:54 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j9CIHrta029869; Wed, 12 Oct 2005 14:17:53 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: CONSENSUS CALL: GSSAPI mechanism spec References: From: Tom Yu Date: Wed, 12 Oct 2005 14:17:53 -0400 In-Reply-To: (Tom Yu's message of "Fri, 30 Sep 2005 17:23:05 -0400") Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "tlyu" == Tom Yu writes: tlyu> At IETF63, there appeared to consensus in the room to separate the tlyu> SASL GSSAPI mechanism specification into distinct specifications for tlyu> the legacy (krb5 and SPNEGO) and the family of mechanisms. Alexey's tlyu> current draft (Thanks Alexey!) reflects the first part of this tlyu> consensus. Hearing no objections, I declare that the consensus of the Working Group is to divide the GSSAPI SASL mechanism specification as described above. ---Tom 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 j9CIGXoE053402; Wed, 12 Oct 2005 11:16: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 j9CIGXo3053401; Wed, 12 Oct 2005 11:16:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CIGWoX053393 for ; Wed, 12 Oct 2005 11:16:32 -0700 (PDT) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j9CIGUeh002855 for ; Wed, 12 Oct 2005 14:16:30 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j9CIGNTZ029587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2005 14:16:24 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j9CIGN94029857; Wed, 12 Oct 2005 14:16:23 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: CONSENSUS CALL: DIGEST-MD5 AES cipher mode References: From: Tom Yu Date: Wed, 12 Oct 2005 14:16:23 -0400 In-Reply-To: (Tom Yu's message of "Fri, 30 Sep 2005 17:23:48 -0400") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "tlyu" == Tom Yu writes: tlyu> At IETF63, there appeared to be consensus in the room to drop tlyu> "proposal #2" from DIGEST-MD5's specification of a AES CBC cipher tlyu> mode. This proposal involves sending a separate IV in a separate SASL tlyu> block, and not using a new explicit IV in each block. Hearing no objections, I declare that the consensus of the Working Group is to drop "proposal #2" from the AES cipher mode description in DIGEST-MD5. ---Tom 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 j9CHqbcc051355; Wed, 12 Oct 2005 10:52:37 -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 j9CHqbn7051354; Wed, 12 Oct 2005 10:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9CHqa9L051348 for ; Wed, 12 Oct 2005 10:52:36 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9CHqa1L002074 for ; Wed, 12 Oct 2005 11:52:36 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) id <0IO900I01DMN3000@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-sasl@imc.org; Wed, 12 Oct 2005 11:52:36 -0600 (MDT) Received: from [10.0.1.3] (216-165-225-129.altrionet.com [216.165.225.129]) by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPSA id <0IO900A7BDNFC350@mail-amer.sun.com>; Wed, 12 Oct 2005 11:52:36 -0600 (MDT) Date: Wed, 12 Oct 2005 10:52:23 -0700 From: Chris Newman Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track In-reply-to: To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Message-id: <92FE6CA2C363F98ED9B85AED@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote on 10/10/05 20:03 -0700: > On Oct 10, 2005, at 7:49 PM, Chris Newman wrote: >> However, I do not believe CRAM-MD5 should be promoted outside the >> email community as it has too many missing features to be generally >> useful > > Frankly, it's those lack of features that makes it such a useful mechanism. I see no evidence to support this assertion. In practice, SSL + plaintext-passwords has deployed much more successfully and much more widely than CRAM-MD5 despite being significantly more expensive computationally and several orders of magnitude more complex in terms of code and features. I would conclude that CRAM-MD5 is failing to deploy as widely as it could have because it lacks necessary features which are present in SSL + plaintext-password mechanisms. The fact that DIGEST-MD5 deployment has been even less successful than CRAM-MD5 has several causes: 1. it came out later. 2. it is more complex. 3. it has design flaws not present in CRAM-MD5. 4. it doesn't provide the features that make SSL + plaintext-password mechanisms so successful despite the cost. 5. the spec wasn't very good. > We're still a long way from seeing (e.g.) DIGEST-MD5 gain widespread > interoperability. (Try setting up DIGEST-MD5 authentication between > sendmail and any number of clients. It's an exercise in frustration. And > that's neither sendmail's nor the client's fault.) I can think of a lot of > applications where CRAM provides sufficient security for the job at hand, > and is simple enough to implement that there is a very good chance that it > will get done correctly. I agree that CRAM-MD5 is more useful and widely deployed than DIGEST-MD5. DIGEST-MD5 inherited a couple of bad design flaws from HTTP digest (the realms concept, putting the username in the hash) and the MD5 issue is just the final nail in the coffin for it as far as I'm concerned. I would be more comfortable moving DIGEST-MD5 to historic than I would be with moving CRAM-MD5 to historic. And I'm well aware that DIGEST-MD5 is partly my fault -- I guessed that HTTP digest would deploy and DIGEST-MD5 could share that deployment train, but I was wrong on both counts. I apologize for the mess I created in the process. > We don't have a replacement for CRAM that has the same proven > interoperability and wide deployment, therefore I think it would be > foolhardy to not move CRAM forward to Proposed status. This is a compelling argument. CRAM-MD5 deploys in a useful niche. DIGEST-MD5 is not a suitable replacement for that niche because of design flaws. Until a suitable replacement is found, I agree it is premature to move CRAM-MD5 to historic. - Chris 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 j9BBQPSX068949; Tue, 11 Oct 2005 04:26: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 j9BBQPgh068948; Tue, 11 Oct 2005 04:26:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BBQLAk068935 for ; Tue, 11 Oct 2005 04:26:24 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9BBQDG1026685; Tue, 11 Oct 2005 13:26:14 +0200 From: Simon Josefsson To: Chris Newman Cc: Lyndon Nerenberg , ietf-sasl@imc.org Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051011:ietf-sasl@imc.org::1IIAkdfugn9Ls99P:EUq X-Hashcash: 1:21:051011:chris.newman@sun.com::5bkdej9CmfSkEQCH:0mhZ X-Hashcash: 1:21:051011:lyndon@orthanc.ca::4dtpp/2T+f9qCAbO:80S9 X-Hashcash: 1:21:051011:chris.newman@sun.com::MiDAKr1HjaHfohjw:BX4w Date: Tue, 11 Oct 2005 13:26:02 +0200 In-Reply-To: (Chris Newman's message of "Mon, 10 Oct 2005 19:49:58 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris Newman writes: > I'm neutral on this topic. > > CRAM-MD5 is widely deployed in the email community and will remain widely > deployed and useful in that community regardless of the standards status. Agreed. > However, I do not believe CRAM-MD5 should be promoted outside the > email community as it has too many missing features to be generally > useful (client nonce, authorization id, salt, hash function agility, > proxy support, etc.). I think we could add warnings that describe this problem to the draft, but let others decide whether or not those limitations is critical for their application or not. I don't think the draft should say that CRAM-MD5 should only be used for e-mail protocols. I think there are other places where CRAM-MD5 is useful, even considering all the limitations. EAP-tunneled SASL over TLS is one scenario, to provide network logon, which isn't completely unlikely. I agree with Lyndon that the lack of features is CRAM-MD5 best strength. Thanks, 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 j9B90A3o036524; Tue, 11 Oct 2005 02:00: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 j9B90ATc036523; Tue, 11 Oct 2005 02:00:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.pscs.co.uk (lmail.pscs.co.uk [194.143.169.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9B907Zd036515 for ; Tue, 11 Oct 2005 02:00:08 -0700 (PDT) (envelope-from paul@pscs.co.uk) Received: from 192.168.66.101 by mail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 11 Oct 2005 09:23:14 +0100 Message-Id: <6.1.0.6.2.20051011092247.0563d078@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 11 Oct 2005 09:23:12 +0100 To: Lyndon Nerenberg , Chris Newman From: Paul Smith Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Cc: ietf-sasl@imc.org In-Reply-To: References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.2.7 - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:03 11/10/2005, Lyndon Nerenberg wrote: >We don't have a replacement for CRAM that has the same proven >interoperability and wide deployment, therefore I think it would be >foolhardy to not move CRAM forward to Proposed status. Put me on the 'me too' list for this :) Paul VPOP3 - Internet Email Server/Gateway support@pscs.co.uk http://www.pscs.co.uk/ 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 j9B33QbT000689; Mon, 10 Oct 2005 20:03: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 j9B33QNt000688; Mon, 10 Oct 2005 20:03:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9B33Pow000676 for ; Mon, 10 Oct 2005 20:03:26 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.homeunix.org (d64-180-189-53.bchsia.telus.net [64.180.189.53]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j9B33KFQ053253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 21:03:21 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.homeunix.org (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id j9B33Frh020191; Mon, 10 Oct 2005 20:03:15 -0700 (PDT) In-Reply-To: References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-sasl@imc.org Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Date: Mon, 10 Oct 2005 20:03:13 -0700 To: Chris Newman X-Mailer: Apple Mail (2.734) X-DCC-sgs_public_dcc_server-Metrics: orthanc.ca 1199; Body=2 Fuz1=2 Fuz2=2 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 10, 2005, at 7:49 PM, Chris Newman wrote: > However, I do not believe CRAM-MD5 should be promoted outside the > email community as it has too many missing features to be generally > useful Frankly, it's those lack of features that makes it such a useful mechanism. We're still a long way from seeing (e.g.) DIGEST-MD5 gain widespread interoperability. (Try setting up DIGEST-MD5 authentication between sendmail and any number of clients. It's an exercise in frustration. And that's neither sendmail's nor the client's fault.) I can think of a lot of applications where CRAM provides sufficient security for the job at hand, and is simple enough to implement that there is a very good chance that it will get done correctly. We don't have a replacement for CRAM that has the same proven interoperability and wide deployment, therefore I think it would be foolhardy to not move CRAM forward to Proposed status. --lyndon 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 j9B2nroW098681; Mon, 10 Oct 2005 19:49:53 -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 j9B2nr6D098680; Mon, 10 Oct 2005 19:49:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9B2nqGi098662 for ; Mon, 10 Oct 2005 19:49:53 -0700 (PDT) (envelope-from Chris.Newman@Sun.COM) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9B2nq1L025146 for ; Mon, 10 Oct 2005 20:49:52 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) id <0IO600A01D1UB100@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-sasl@imc.org; Mon, 10 Oct 2005 20:49:52 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPSA id <0IO6007LTD717HG0@mail-amer.sun.com>; Mon, 10 Oct 2005 20:49:52 -0600 (MDT) Date: Mon, 10 Oct 2005 19:49:58 -0700 From: Chris Newman Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track In-reply-to: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> To: Lyndon Nerenberg , ietf-sasl@imc.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm neutral on this topic. CRAM-MD5 is widely deployed in the email community and will remain widely deployed and useful in that community regardless of the standards status. However, I do not believe CRAM-MD5 should be promoted outside the email community as it has too many missing features to be generally useful (client nonce, authorization id, salt, hash function agility, proxy support, etc.). It is, however, important that the revised CRAM-MD5 specification be published as an RFC because 2195 has bugs. - Chris Lyndon Nerenberg wrote on 10/10/05 17:49 -0700: > >> I think this is poor idea. >> >> CRAM-MD5 appear to me to be the most widely implemented non-PLAIN SASL >> mechanism. Documenting that common use, and the internationalization >> improvement in the current document, with proper security guidance >> (i.e., require STARTTLS) appear suitable for standards track. > > I'm in full agreement here. While CRAM-MD5 is being superseded by other > mechanisms, it's not about to vanish. There's no more reason to move it to > historic than there is to declare telnet and FTP historic. 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 j9B0nhTf088452; Mon, 10 Oct 2005 17:49: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 j9B0nh8A088451; Mon, 10 Oct 2005 17:49:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9B0ngDw088445 for ; Mon, 10 Oct 2005 17:49:42 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.homeunix.org (d64-180-189-53.bchsia.telus.net [64.180.189.53]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j9B0nbCn030601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2005 18:49:38 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.homeunix.org (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id j9B0nXZK019898 for ; Mon, 10 Oct 2005 17:49:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B797859-4188-49C8-81BD-084EDE76ACCC@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track Date: Mon, 10 Oct 2005 17:49:32 -0700 To: ietf-sasl@imc.org X-Mailer: Apple Mail (2.734) X-DCC-sgs_public_dcc_server-Metrics: orthanc.ca 1199; Body=1 Fuz1=1 Fuz2=1 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think this is poor idea. > > CRAM-MD5 appear to me to be the most widely implemented non-PLAIN SASL > mechanism. Documenting that common use, and the internationalization > improvement in the current document, with proper security guidance > (i.e., require STARTTLS) appear suitable for standards track. I'm in full agreement here. While CRAM-MD5 is being superseded by other mechanisms, it's not about to vanish. There's no more reason to move it to historic than there is to declare telnet and FTP historic. --lyndon 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 j93LAGGL072442; Mon, 3 Oct 2005 14:10:16 -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 j93LAGcO072441; Mon, 3 Oct 2005 14:10:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j93LAFVI072435 for ; Mon, 3 Oct 2005 14:10:15 -0700 (PDT) (envelope-from tlyu@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j93LAD4u008760 for ; Mon, 3 Oct 2005 17:10:13 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j93LA9YN015805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 Oct 2005 17:10:10 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j93LA9xb021498; Mon, 3 Oct 2005 17:10:09 -0400 (EDT) To: ietf-sasl@imc.org Subject: fwd: SASL WG session at IETF64 From: Tom Yu Date: Mon, 03 Oct 2005 17:10:09 -0400 Message-ID: Lines: 41 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -------------------- Start of forwarded message -------------------- To: agenda@ietf.org Cc: hartmans-ietf@mit.edu, housley@vigilsec.com, kurt@openldap.com Subject: SASL WG session at IETF64 From: Tom Yu Date: Mon, 03 Oct 2005 12:52:54 -0400 Message-ID: Lines: 29 a. Working Group or BOF full name with acronym in brackets: Simple Authentication and Security Layer [SASL] b. AREA under which Working Group or BOF appears: Security c. CONFLICTS you wish to avoid, please be as specific as possible: KRB-WG, KITTEN, LDAPBIS, PKIX, XMPP, SAAG, TLS, AppsArea, IMAPEXT, EAP, LTRU, LEMONADE, SIEVE d. Expected Attendance (figures from the 63rd IETF are at the end of this message): 50 e. Special requests: "new-style" room layout f. Number of slots: 1 g. Length of slot: 2 hours -------------------- End of forwarded message -------------------- 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 j91ANt9F067155; Sat, 1 Oct 2005 03:23:55 -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 j91ANtI3067154; Sat, 1 Oct 2005 03:23:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j91ANpY4067148 for ; Sat, 1 Oct 2005 03:23:54 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j91ANmok027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Oct 2005 12:23:48 +0200 From: Simon Josefsson To: Tom Yu Cc: ietf-sasl@imc.org Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051001:ietf-sasl@imc.org::9JIiumYUcwWTr+vs:1z7h X-Hashcash: 1:21:051001:tlyu@mit.edu::oJ2Hw3I4SIdB2GdF:NFni X-Hashcash: 1:21:051001:tlyu@mit.edu::2KYp7fz7J6K2UWv1:s9/ Date: Sat, 01 Oct 2005 12:23:46 +0200 In-Reply-To: (Tom Yu's message of "Fri, 30 Sep 2005 17:22:50 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom Yu writes: > At IETF63, there appeared to be consensus in the room to remove > CRAM-MD5 from the standards track. There appears to be some > preference to advance the document as Historic. > > In the absence of objections, I will declare that the consensus of the > Working Group is to progress CRAM-MD5 as Historic. > > Please respond by noon US/Eastern time on Friday, October 7th. I think this is poor idea. CRAM-MD5 appear to me to be the most widely implemented non-PLAIN SASL mechanism. Documenting that common use, and the internationalization improvement in the current document, with proper security guidance (i.e., require STARTTLS) appear suitable for standards track. STARTTLS+CRAM-MD5 can offer an advantage over STARTTLS+PLAIN because PLAIN doesn't have any channel bindings with the TLS session. A tunnel attack would give the attacker the password with PLAIN, but with CRAM-MD5 the attacker would only get a CRAM-MD5 exchange. The attacker may get control over that particular CRAM-MD5 session, but cannot re-use the information gained, without computational burden, to connect a second time, as he would in the PLAIN case. STARTTLS+CRAM-MD5 can offer an advantage over DIGEST-MD5 because TLS offer better encryption and authentication flexibility than DIGEST-MD5. DIGEST-MD5's cryptographic properties (MD5 and RC4, AES approach uncertain) appear historic in comparison. Further, being able to re-use deployed CRAM-MD5 databases is an advantage to even STARTTLS+DIGEST-MD5. GSSAPI typically require more infrastructure than any of *-MD5, which in some environments traditionally has made it unpopular. I don't see a compelling reason to regard the construction STARTTLS+CRAM-MD5 as historic when considering the small set of other alternatives there are. Further, I also doesn't see any serious security problem with STARTTLS+CRAM-MD5. Could someone explain why CRAM-MD5 should be considered historic? The only reason I can think of is that CRAM-MD5 doesn't support authorization identities. However, that features of SASL has only been used in administrative tools (or are there any popular end-user clients that support authorization identities?) and those tools could easily use STARTTLS+PLAIN instead. Thanks, Simon