subscribe1

["Gabriel Bendayan" <[e-mail]>]

thanks




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DGWsig096551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 09:32:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DGWsaP096550; Sat, 13 Sep 2008 09:32:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from outspam.elim.net (outspam.elim.net [203.239.130.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DGWrN5096543 for <[e-mail]>; Sat, 13 Sep 2008 09:32:53 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by outspam.elim.net (NURI-MTA) with SMTP id 8C67A8C5675 for <[e-mail]>; Sun, 14 Sep 2008 01:32:52 +0900 (KST)
Received: from localhost ([127.0.0.1]) by localhost with SMTP id 48CBEB34550B for <[e-mail]>; Sun, 14 Sep 2008 01:32:52 +0900 (KST)
Received: from localhost (localhost [127.0.0.1]) by outspam.elim.net (NURI-MTA) with ESMTP id 774018C54F4 for <[e-mail]>; Sun, 14 Sep 2008 01:32:52 +0900 (KST)
Received: from outspam.elim.net ([127.0.0.1]) by localhost (outspam [127.0.0.1]) (MMP-FTR) with ESMTP id 21736-04 for <[e-mail]>; Sun, 14 Sep 2008 01:32:52 +0900 (KST)
Received: from mail.elim.net (mail.elim.net [203.239.130.5]) by outspam.elim.net (NURI-MTA) with ESMTP id 387FB8C5298 for <[e-mail]>; Sun, 14 Sep 2008 01:32:52 +0900 (KST)
Received: from pknth ([211.112.8.69]) by mail.elim.net (8.13.6/8.13.6) with ESMTP id m8DGRefR028331 for <[e-mail]>; Sun, 14 Sep 2008 01:27:42 +0900 (KST)
Message-Id: <[e-mail]>
From: "Gabriel Bendayan" <[e-mail]>
Subject: subscribe1
To: [e-mail]
Content-Type: text/plain; charset="US-ASCII"
Reply-To: [e-mail]
Date: Sat, 13 Sep 2008 18:32:59 +0200
X-Priority: 3
X-Spam-Score: 6.185
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

thanks



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m89Jj7F4006447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 12:45:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m89Jj7sF006446; Tue, 9 Sep 2008 12:45:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m89Jj7sW006439 for <[e-mail]>; Tue, 9 Sep 2008 12:45:07 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D58533A6B22; Tue,  9 Sep 2008 12:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-sasl-4422bis-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  9 Sep 2008 12:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=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-4422bis-00.txt
	Pages		: 33
	Date		: 2008-8-31
	
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.  In addition, this
   document defines one SASL mechanism, the EXTERNAL mechanism.

   This document obsoletes RFC 4422 [[when approved]].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-4422bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sasl-4422bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m898TRVt045954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 01:29:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m898TRCs045953; Tue, 9 Sep 2008 01:29:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m898TE7w045924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 9 Sep 2008 01:29:26 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-18-41.bredband.comhem.se ([80.216.18.41] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1Kcyaz-0006nC-Pv; Tue, 09 Sep 2008 10:29:11 +0200
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: GS2 status, and poll on wire encoding
References: <[e-mail]> <g9viv2$5ka$[e-mail]> <[e-mail]> <ga4202$icq$[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080909:[e-mail]::Yvo0cFuJdig8F63a:AnkM
X-Hashcash: 1:22:080909:[e-mail]::WNuozWSa9TMXsnQ6:N8+3
Date: Tue, 09 Sep 2008 10:29:09 +0200
In-Reply-To: <ga4202$icq$[e-mail]> (Frank Ellermann's message of "Mon, 8 Sep 2008 22:32:04 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>> I believe at least GNU SASL and Cyrus SASL does.
>
> My MD5 test suite doesn't, it's horribly intolerant
> for input without "=" pad characters.

A good implementation should be intolerant about base64 errors!
Otherwise there are side channels risks or worse problems.

> Of course that mainly means that I should fix it, add a flag for
> "4648" vs. "DWIM", or similar.

I think it would be better if everyone tried to implement the 4648
format and reject non-conforming data, rather than an underspecified
DWIM mode.  I believe GNU SASL strictly follows 4648, and I haven't seen
any problems in that area so far.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88Mdb1V007144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 15:39:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88Mdb5J007143; Mon, 8 Sep 2008 15:39:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88MdPU6007129 for <[e-mail]>; Mon, 8 Sep 2008 15:39:36 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 6E3274AC7F; Tue,  9 Sep 2008 00:39:24 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) (authenticated as [e-mail]) by kalyani.oryx.com with esmtp id 1220913563-65091-2162 for [e-mail]; Tue, 9 Sep 2008 00:39:23 +0200
Message-Id: <[e-mail]>
Date: Tue, 9 Sep 2008 00:39:32 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: GS2 status, and poll on wire encoding
References: <[e-mail]> <g9viv2$5ka$[e-mail]> <[e-mail]> <ga4202$icq$[e-mail]>
In-Reply-To: <ga4202$icq$[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Frank Ellermann writes:
> Simon Josefsson wrote:
>>  I believe at least GNU SASL and Cyrus SASL does.
>
> My MD5 test suite doesn't, it's horribly intolerant for input without 
> "=" pad characters. Of course that mainly means that I should fix it, 
> add a flag for "4648" vs. "DWIM", or similar.

If a lot of people get the pad character generation/handling wrong, 
maybe that means requiring the padding was a poor choice on part of 
whoever conceived the base64 spec.

(Blah blah descriptive vs. prescriptive grammar blah.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KUEsF098260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 13:30:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88KUEiT098259; Mon, 8 Sep 2008 13:30:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KUCaV098252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 13:30:13 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KcnNB-00076z-EI for [e-mail]; Mon, 08 Sep 2008 20:30:09 +0000
Received: from 212.82.251.104 ([212.82.251.104]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 08 Sep 2008 20:30:09 +0000
Received: from nobody by 212.82.251.104 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 08 Sep 2008 20:30:09 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: GS2 status, and poll on wire encoding
Date:  Mon, 8 Sep 2008 22:32:04 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Message-ID: <ga4202$icq$[e-mail]>
References:  <[e-mail]> <g9viv2$5ka$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.104
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> I believe at least GNU SASL and Cyrus SASL does.

My MD5 test suite doesn't, it's horribly intolerant
for input without "=3D" pad characters.  Of course
that mainly means that I should fix it, add a flag
for "4648" vs. "DWIM", or similar.

Over the years all problems I found with this test
suites fall in two categories:

- B64 GiGo effects
- Erratum submitted

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KCpEi096686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 13:12:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88KCpwL096685; Mon, 8 Sep 2008 13:12:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KCbxK096645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 13:12:49 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kcn67-0006Qk-NK for [e-mail]; Mon, 08 Sep 2008 20:12:32 +0000
Received: from 212.82.251.104 ([212.82.251.104]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 08 Sep 2008 20:12:31 +0000
Received: from nobody by 212.82.251.104 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 08 Sep 2008 20:12:31 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Proposed SASL WG charter description
Date:  Mon, 8 Sep 2008 22:14:33 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 20
Message-ID: <ga40v6$eij$[e-mail]>
References:  <[e-mail]> <g9vlhu$bnl$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.104
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> Net-UTF8 is about network transfer of character data.

Yes, it boils down to NFC with some fine print about
control characters and line ends. =20
  =20
> It's not about normalizing character data for input to
> cryptographic functions whose output is transferred.
> SASLprep was designed with the latter in mind, Net-UTF8
> (apparently) wasn't.

s/apparently/definitely/  But when all its SHOULDs are
promoted to MUSTs it will be good enough.  Implementors
need to know that NFC is not "only" recommended, it is
required.  After that what they get is a very desirable
u+00AA !=3D a canonicalization of Unicode, with libraries
everywhere.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88FO1b0074305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 08:24:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88FO1WN074304; Mon, 8 Sep 2008 08:24:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88FO0UO074298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 08:24:00 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.219] (host-74-211-11-208.beyondbb.com [74.211.11.208] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m88FNq2V065363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Sep 2008 15:23:53 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Proposed SASL WG charter description
Date: Mon, 8 Sep 2008 08:23:52 -0700
References: <[e-mail]> <g9vlhu$bnl$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sep 8, 2008, at 7:56 AM, Simon Josefsson wrote:

> One could also use Net-UTF8 for usernames and SASLprep for passwords.

I think it was and still is desirable to have one preparation  
algorithm for both usernames and passwords.

Also, I don't find Net-UTF8 all that appealing for use in preparing  
identifiers such as user names and passwords, but more for free-form  
text values. Net-UTF8 is about network transfer of character data.   
It's not about normalizing character data for input to cryptographic  
functions whose output is transferred.  SASLprep was designed with the  
latter in mind, Net-UTF8 (apparently) wasn't.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EuRcj072374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 07:56:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88EuRYf072373; Mon, 8 Sep 2008 07:56:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EuFhx072305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 07:56:27 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-18-41.bredband.comhem.se ([80.216.18.41] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1Kci9y-0006e9-A8; Mon, 08 Sep 2008 16:56:11 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Proposed SASL WG charter description
References: <[e-mail]> <g9vlhu$bnl$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080908:[e-mail]::B7emvpTQXBAUJeEy:142G
X-Hashcash: 1:22:080908:[e-mail]::rB0k/jcjHgxqG7JD:3K1G
X-Hashcash: 1:22:080908:[e-mail]::Qe3sL43TFlPzN2bt:ZzpL
X-Hashcash: 1:22:080908:[e-mail]::lsUQ1UExDDEZQfEu:dpez
Date: Mon, 08 Sep 2008 16:56:08 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Mon, 8 Sep 2008 07:13:51 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Sep 8, 2008, at 4:26 AM, Simon Josefsson wrote:
>
>>
>> Alexey Melnikov <[e-mail]> writes:
>>
>>> Frank Ellermann wrote:
>>>
>>>> Kurt Zeilenga wrote:
>>>>
>>>>
>>>>> This group will produce a document revising SASLprep [RFC4013]
>>>>> to improve Unicode version agility while maintaining RFC 4013
>>>>> behavior when used with RFC 4013 mandated version of Unicode.
>>>>> The outcome of this work will be a Standards Track RFC replacing
>>>>> RFC 4013.
>>>>>
>>>>>
>>>> Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>>>>
>>>>
>>> A very good question indeed.
>>
>> Given that few have implemented RFC 4013 I'm not sure that backwards
>> compatibility with it has to be an absolute mandate in the SASL WG
>> charter.
>
> My view is that it's not an "absolute mandate".  As I noted in my
> response to Frank's comments, my intent was to keep a narrow focus on
> the work.  I specially don't want to revisit discussions such as
> "Should character X be excluded?".   I want to limit the work to
> replacing stringprep tables with Unicode properties.  SASLprepbis(x)
> == SASLprep(x) for all x (where x is well formed Unicode 3.2 text).

Limiting the work would preclude considering Net-UTF8, as far as I can
tell.

>> Given the PR-29 problem (NFKC output has been altered for some code
>> points in later Unicode versions), perfect backwards compatibility may
>> not be something to strive for anyway.
>
> How about "backwards compatibility for characters used in practice"?
> PR-29 issues were limited to characters which do not occur in practice.

That would work.

>> Even though NFKC was
>> used by StringPrep for domain names, I'm not convinced it is the best
>> choice for passwords.
>
> I note that SASLprep is also used for user names.  Decisions need to
> be made not just based on "best choice for passwords" but "best choice
> for user names and passwords".

One could also use Net-UTF8 for usernames and SASLprep for passwords.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EEAh4068554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 07:14:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88EEAml068553; Mon, 8 Sep 2008 07:14:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EE9ah068545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 07:14:09 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.219] (host-74-211-11-208.beyondbb.com [74.211.11.208] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m88EDp41061825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Sep 2008 14:13:52 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Proposed SASL WG charter description
Date: Mon, 8 Sep 2008 07:13:51 -0700
References: <[e-mail]> <g9vlhu$bnl$[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sep 8, 2008, at 4:26 AM, Simon Josefsson wrote:

>
> Alexey Melnikov <[e-mail]> writes:
>
>> Frank Ellermann wrote:
>>
>>> Kurt Zeilenga wrote:
>>>
>>>
>>>> This group will produce a document revising SASLprep [RFC4013]
>>>> to improve Unicode version agility while maintaining RFC 4013
>>>> behavior when used with RFC 4013 mandated version of Unicode.
>>>> The outcome of this work will be a Standards Track RFC replacing
>>>> RFC 4013.
>>>>
>>>>
>>> Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>>>
>>>
>> A very good question indeed.
>
> Given that few have implemented RFC 4013 I'm not sure that backwards
> compatibility with it has to be an absolute mandate in the SASL WG
> charter.

My view is that it's not an "absolute mandate".  As I noted in my  
response to Frank's comments, my intent was to keep a narrow focus on  
the work.  I specially don't want to revisit discussions such as  
"Should character X be excluded?".   I want to limit the work to  
replacing stringprep tables with Unicode properties.  SASLprepbis(x)  
== SASLprep(x) for all x (where x is well formed Unicode 3.2 text).


> Given the PR-29 problem (NFKC output has been altered for some code
> points in later Unicode versions), perfect backwards compatibility may
> not be something to strive for anyway.

How about "backwards compatibility for characters used in practice"?
PR-29 issues were limited to characters which do not occur in practice.

> Speaking as implementer of RFC 4013, I'd be happy to obsolete it in
> favor of net-UTF8.
>
>>> Roughly this could mean to replace NFKC-x by NFC-y.  Of course
>>> NFKC-x is a proper subset of NFC-y, what I'm talking about is
>>> to minimize the SASL-specific restrictions x vs. y, and to get
>>> rid of NFKC.
>>>
>>>
>> I am not sure NFC is better than KFKC for usernames/passwords.
>> But the idea of using NET-Unicode as the base seems interesting to  
>> me.
>
> NFKC removes more entropy from passwords than NFC.

Yes.  This issue was discussed when SASLprep was put forth on the  
Standards Track.  If we replace SASLprep, we will potentially revisit  
every decision.  I rather avoid doing so.  I rather we simply address  
the Unicode agility issue and move on.

> Even though NFKC was
> used by StringPrep for domain names, I'm not convinced it is the best
> choice for passwords.

I note that SASLprep is also used for user names.  Decisions need to  
be made not just based on "best choice for passwords" but "best choice  
for user names and passwords".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88DwAcB066942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 06:58:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88DwAvh066941; Mon, 8 Sep 2008 06:58:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88DvxUU066924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 06:58:10 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.219] (host-74-211-11-208.beyondbb.com [74.211.11.208] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m88Dvs4T061105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Sep 2008 13:57:56 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g9vlhu$bnl$[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Proposed SASL WG charter description
Date: Mon, 8 Sep 2008 06:57:54 -0700
References: <[e-mail]> <g9vlhu$bnl$[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sep 6, 2008, at 9:35 PM, Frank Ellermann wrote:

>
> Kurt Zeilenga wrote:
>
>> This group will produce a document revising SASLprep [RFC4013]
>> to improve Unicode version agility while maintaining RFC 4013
>> behavior when used with RFC 4013 mandated version of Unicode.
>> The outcome of this work will be a Standards Track RFC
>> replacing RFC 4013.
>
> Does that allow for "abandon SASLprep in favour of net-UTF8" ?

The above work item for revising of SASLprep technical specification  
item, not for engineering a complete SASLprep replacement item.  In  
proposing this work in this way, I was hoping to keep it narrowly  
focused.   Basically, revise SASL prep to use Unicode properties  
instead of stringprep tables, so that SASLprep has decent Unicode  
agility.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88BYpPv054389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 04:34:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88BYpnE054388; Mon, 8 Sep 2008 04:34:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88BYnkt054382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 04:34:51 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-18-41.bredband.comhem.se ([80.216.18.41] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1Kcf16-0006by-9k; Mon, 08 Sep 2008 13:34:48 +0200
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: GS2 status, and poll on wire encoding
References: <[e-mail]> <g9viv2$5ka$[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080908:[e-mail]::FbytVlG7UaoyKuUo:1ZOs
X-Hashcash: 1:22:080908:[e-mail]::eGIvD6ngiN5a9YdT:DYvS
Date: Mon, 08 Sep 2008 13:34:47 +0200
In-Reply-To: <g9viv2$5ka$[e-mail]> (Frank Ellermann's message of "Sun, 7 Sep 2008 05:51:02 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>> 4) Something else, namely: ....
>
> ...no preference, but IFF you go for "textual"
> please consider case-insensitive hex., no B64.  

Base64 implementations often have a lot of problem that makes them
unsuitable for use in security protocols, so you have a point.  However,
I believe the majority of SASL profiles out there already makes use of
base64, so implementations better have a good implementation of it handy
anyway.  I believe at least GNU SASL and Cyrus SASL does.

The only reason I can see to prefer base64 would be if it is worth the
extra complexity in order to reduce bandwidth.

I don't feel strongly about hex vs base64.  Other thoughts?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88BREPw053751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 04:27:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88BRE6k053750; Mon, 8 Sep 2008 04:27:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88BR0Gj053729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 04:27:12 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-18-41.bredband.comhem.se ([80.216.18.41] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KcetQ-0006br-Cv; Mon, 08 Sep 2008 13:26:56 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Proposed SASL WG charter description
References: <[e-mail]> <g9vlhu$bnl$[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080908:[e-mail]::WvOARH9Qnp8IvUOz:CHXr
X-Hashcash: 1:22:080908:[e-mail]::ijZWwRwdAHHVnOoc:LCAh
X-Hashcash: 1:22:080908:[e-mail]::AesLtVVm5JmjzMEO:FyJG
Date: Mon, 08 Sep 2008 13:26:51 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sun, 07 Sep 2008 13:39:56 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Frank Ellermann wrote:
>
>>Kurt Zeilenga wrote:
>>  
>>
>>>This group will produce a document revising SASLprep [RFC4013]
>>>to improve Unicode version agility while maintaining RFC 4013
>>>behavior when used with RFC 4013 mandated version of Unicode.
>>> The outcome of this work will be a Standards Track RFC replacing
>>> RFC 4013.
>>>    
>>>
>>Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>>  
>>
> A very good question indeed.

Given that few have implemented RFC 4013 I'm not sure that backwards
compatibility with it has to be an absolute mandate in the SASL WG
charter.

Given the PR-29 problem (NFKC output has been altered for some code
points in later Unicode versions), perfect backwards compatibility may
not be something to strive for anyway.

Speaking as implementer of RFC 4013, I'd be happy to obsolete it in
favor of net-UTF8.

>>Roughly this could mean to replace NFKC-x by NFC-y.  Of course
>>NFKC-x is a proper subset of NFC-y, what I'm talking about is
>>to minimize the SASL-specific restrictions x vs. y, and to get
>>rid of NFKC.
>>  
>>
> I am not sure NFC is better than KFKC for usernames/passwords.
> But the idea of using NET-Unicode as the base seems interesting to me.

NFKC removes more entropy from passwords than NFC.  Even though NFKC was
used by StringPrep for domain names, I'm not convinced it is the best
choice for passwords.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m87CeIR3028301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Sep 2008 05:40:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m87CeIAa028300; Sun, 7 Sep 2008 05:40:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m87Ce4Ch028284 for <[e-mail]>; Sun, 7 Sep 2008 05:40:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 7 Sep 2008 13:40:02 +0100
Message-ID: <[e-mail]>
Date: Sun, 07 Sep 2008 13:39:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Frank Ellermann <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed SASL WG charter description
References: <[e-mail]> <g9vlhu$bnl$[e-mail]>
In-Reply-To: <g9vlhu$bnl$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Frank Ellermann wrote:

>Kurt Zeilenga wrote:
>  
>
>>This group will produce a document revising SASLprep [RFC4013]
>>to improve Unicode version agility while maintaining RFC 4013
>>behavior when used with RFC 4013 mandated version of Unicode.
>>The outcome of this work will be a Standards Track RFC 
>>replacing RFC 4013.
>>    
>>
>Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>  
>
A very good question indeed.

>Roughly this could mean to replace NFKC-x by NFC-y.  Of course
>NFKC-x is a proper subset of NFC-y, what I'm talking about is
>to minimize the SASL-specific restrictions x vs. y, and to get
>rid of NFKC.
>  
>
I am not sure NFC is better than KFKC for usernames/passwords.
But the idea of using NET-Unicode as the base seems interesting to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m874XJ1s002421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 21:33:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m874XJjk002420; Sat, 6 Sep 2008 21:33:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m874XH4U002413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 6 Sep 2008 21:33:18 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KcBxY-0000Az-V1 for [e-mail]; Sun, 07 Sep 2008 04:33:12 +0000
Received: from 212.82.251.146 ([212.82.251.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 04:33:12 +0000
Received: from nobody by 212.82.251.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 04:33:12 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Proposed SASL WG charter description
Date:  Sun, 7 Sep 2008 06:35:15 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 25
Message-ID: <g9vlhu$bnl$[e-mail]>
References:  <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.146
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> This group will produce a document revising SASLprep [RFC4013]
> to improve Unicode version agility while maintaining RFC 4013
> behavior when used with RFC 4013 mandated version of Unicode.
> The outcome of this work will be a Standards Track RFC=20
> replacing RFC 4013.

Does that allow for "abandon SASLprep in favour of net-UTF8" ?

Roughly this could mean to replace NFKC-x by NFC-y.  Of course
NFKC-x is a proper subset of NFC-y, what I'm talking about is
to minimize the SASL-specific restrictions x vs. y, and to get
rid of NFKC.

> Additionally, the WG will deliver a document summarizing its =20
> DIGEST-MD5 concerns and requesting RFC 2831 be moved to=20
> Historic status.  This document will be based upon=20
> draft-ietf-sasl-digest-to-historic.

BTW, maybe mention XMPP as a major protocol affected by SASL.
We know this, the XMPP folks know it, I think BEEP covers it,
but for other readers this might be not obvious.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m874AsT7001452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 21:10:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m874AsEB001451; Sat, 6 Sep 2008 21:10:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m874AqSl001443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 6 Sep 2008 21:10:53 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KcBbs-0007mZ-GE for [e-mail]; Sun, 07 Sep 2008 04:10:48 +0000
Received: from 212.82.251.146 ([212.82.251.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 04:10:48 +0000
Received: from nobody by 212.82.251.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 04:10:48 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Summary of opinions regarding the CRAM-MD5 I-D
Date:  Sun, 7 Sep 2008 06:12:51 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 23
Message-ID: <g9vk7u$8n3$[e-mail]>
References:  <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.146
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
=20
> Kurt Zeilenga has raised concerns with publishing the document =20
> "basically as-is" (as Informational).  He has suggested that
> the document could be changed so that it might be suitable for
> publication on the Standards Track but doubts that the WG has
> sufficient energy to do so and/or that the WG would find those
> such changes would be too disruptive to existing deployments.

Two amendments:

- Simon's comparison of PLAIN and CRAM-MD5 was interesting.  It
  would be good to have this in the new RFC (independent of its
  status) as far as we can agree on the content.  This includes
  your explanation why PLAIN offers more flexibility wrt i18n.

- Related, the fate of SASLprep is crucial.  We have only one
  chance to get CRAM-MD5 i18n right.  We can't change our mind
  later (as it might be possible for PLAIN, or with yet another
  parameter for DIGEST-MD5).  Of course we could simply rename
  any SASL mechanism, and use new name to indicate a variation.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m873nDRm000450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 20:49:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m873nDDT000449; Sat, 6 Sep 2008 20:49:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m873n0MQ000437 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 6 Sep 2008 20:49:12 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KcBGm-00072F-6J for [e-mail]; Sun, 07 Sep 2008 03:49:00 +0000
Received: from 212.82.251.146 ([212.82.251.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 03:49:00 +0000
Received: from nobody by 212.82.251.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 07 Sep 2008 03:49:00 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: GS2 status, and poll on wire encoding
Date:  Sun, 7 Sep 2008 05:51:02 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 8
Message-ID: <g9viv2$5ka$[e-mail]>
References:  <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.146
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> 4) Something else, namely: ....

...no preference, but IFF you go for "textual"
please consider case-insensitive hex., no B64. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m860QIBA011689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2008 17:26:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m860QI8q011688; Fri, 5 Sep 2008 17:26:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m860Q4sP011678 for <[e-mail]>; Fri, 5 Sep 2008 17:26:15 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 54E064116; Fri,  5 Sep 2008 20:26:01 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 05 Sep 2008 20:26:01 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 26 Aug 2008 20:40:37 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:

    Simon> A more interesting discussion seems to be: Assuming the
    Simon> document recommends CRAM-MD5+TLS sufficiently well (similar
    Simon> to the wording in the PLAIN document), would such a
    Simon> document be acceptable to put on the Standards Track and
    Simon> with the applicability of COMMON?

    Simon> If that is not the WG consensus, it would be clearer to
    Simon> abandon the current CRAM-MD5 specification and produce a
    Simon> "Moving CRAM-MD5 to Historic" document.

I don't see this point at all.
I actually think publishing the current cram-md5 as informational with limited recommended deployment would be a good step forward.
I certainly prefer abandoning cram-md5 to publishing on the standards track.

    Simon> However, I believe CRAM-MD5+TLS, with warnings about
    Simon> channel binding vulnerabilities, is valuable to have on the
    Simon> standards track until there is other solutions that we can
    Simon> recommend instead (i.e., GS2+SCRAM).

I disagree as I've stated previously.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m84FaGeh013020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 08:36:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m84FaGqn013019; Thu, 4 Sep 2008 08:36:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m84Fa5gJ013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 4 Sep 2008 08:36:15 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m84Fa4Gl097236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Thu, 4 Sep 2008 15:36:05 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Proposed SASL WG charter description
Date: Thu, 4 Sep 2008 08:36:04 -0700
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For your consideration...   The chairs intend to determine whether WG  
consensus supports recommending a proposed revised charter based on  
the following description to the IESG consideration within the next  
week or so.

Most of this text has been discussed previously.  New to this proposal  
is text calling out SASLprep and CRAM-MD5 work.  (The former was not  
mentioned because, at the time, we weren't ready to do this work.  I  
think we now are.  The latter was not mentioned because we thought we  
would be done before the charter proposal could possibly be approved  
by the IESG.)

A revised milestone proposal will be posted separately.

-- Kurt



Simple Authentication and Security Layer (sasl)

Description of Working Group:

The Simple Authentication and Security Layer [RFC4422] provides key  
security services to a number of application protocols including BEEP,  
IMAP, LDAP, POP, and SMTP. The purpose of this working group is to  
shepherd SASL, including select SASL mechanisms, through the Internet  
Standards process.

This group will work to progress the SASL Technical Specification  
toward Draft Standard.

This group will produce a document revising SASLprep [RFC4013] to  
improve Unicode version agility while maintaining RFC 4013 behavior  
when used with RFC 4013 mandated version of Unicode.  The outcome of  
this work will be a Standards Track RFC replacing RFC 4013.

The group has determined that DIGEST-MD5 [RFC2831] is not suitable for  
progression on the Standards Track due to interoperability,  
internationalization, and security concerns.  The group will deliver a  
technical specification for a suitable password-based challenge/ 
response replacement mechanism for Standard Track consideration.  The  
replacement mechanism is expected to be "better than" DIGEST-MD5 from  
a number of perspectives including interoperability,  
internationalization, and security.  The replacement mechanism is not  
expected to (but may) provide a security layer itself, instead rely on  
security services provided at a lower layer (e.g., TLS) and channel  
bindings.  The WG is expected to strike a consensus-supported balance  
between the many qualities desired in the replacement.  Desired  
qualities include (but is not limited to) negotiated key hardening  
iteration count, downgrade attack protection, and mutual  
authentication.  The group intends to consider a number of approaches,  
including draft-newman-auth-scam and draft-josefsson-password-auth, as  
input.  Additionally, the WG will deliver a document summarizing its  
DIGEST-MD5 concerns and requesting RFC 2831 be moved to Historic  
status.  This document will be based upon draft-ietf-sasl-digest-to- 
historic.

This group will deliver a revised Technical Specification suitable for  
publication as Proposed Standard for the GSS-API family of SASL  
mechanisms. This work will be based upon draft-ietf-sasl-gs2.

The group will produce a successor document for the CRAM-MD5  
specification, RFC 2195.  The outcome can be a Standards Track  
specification replacing RFC 2195, an Informational document moving RFC  
2195 to Historic, or an Informational document that documents existing  
implementation practice.

The following areas are not within the scope of work of this WG:

- new features,

- SASL Mechanisms not specifically mentioned above, and

- SASL "profiles".

However, the SASL WG is an acceptable forum for review of SASL-related  
submissions produced by others as long as such review does not impede  
progress on the WG objectives listed above.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m84DTCMr002658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 06:29:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m84DTC0m002657; Thu, 4 Sep 2008 06:29:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m84DT0TO002638 for <[e-mail]>; Thu, 4 Sep 2008 06:29:11 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id 30so610355nfu.24 for <[e-mail]>; Thu, 04 Sep 2008 06:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=Ruc1W3v5w7pgVHd176fLJPi/jmrTybp49H3qL4OPdHs=; b=skszq/M4J998qAUdzDXCWUCW06SppzrZ6BzOD3huR1Uug4Uv8EImIA9ab8vyiIuJeu nexV192kiEzmIqpvomauopxPF1C/b4psXIOxNDp/EBoQBgItenkYLxVTazYRu0ycIB7o 7rcSRqm0wFkJKlA0QDsMtS0WpvkdUwn6fEHYc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=WpSrkOsk2PWr0HgMTnJbxn0T8kM0o3zmnB6pSnbHF8HvMEkEly8dm/91PZ7srHauE7 JfwB5YTR7hF6TqrZ2NLN5cve1F4NchhjsXirdkWGqLWlMpmImBjBJRcbAX+Mba0k+C3R 1SNEAEh4/e3kKt60rQKFDLI95PRAGtbA4wQzM=
Received: by 10.187.168.15 with SMTP id v15mr2384108fao.100.1220534939717; Thu, 04 Sep 2008 06:28:59 -0700 (PDT)
Received: by 10.187.215.19 with HTTP; Thu, 4 Sep 2008 06:28:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 4 Sep 2008 14:28:59 +0100
From: "Alexey Melnikov" <[e-mail]>
To: "Kurt Zeilenga" <[e-mail]>
Subject: Re: Summary of opinions regarding the CRAM-MD5 I-D
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_41236_20403585.1220534939724"
References: <[e-mail]>
X-Google-Sender-Auth: 3d202dbbc7dba79a
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_41236_20403585.1220534939724
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Sep 3, 2008 at 6:54 PM, Kurt Zeilenga <[e-mail]>wrote:
>
> In Pasi recently suggested to the chairs: "I believe it would be useful to
> post a message summarizing the WG members' opinions on
> draft-ietf-sasl-crammd5: who's happy with progressing the document basically
> as-is, and who is not?"
>
> Most of the opinions I am aware of were stated under the belief that the
> I-D was going to progressed with a recommendation for publication on the
> Informational track.   I believe that most of the opinions in stated under
> an assumption that the document would be modified to state the Intended
> Category is "Informational", and that RFC 2195 would be moved to Historic
> status, as indicated in my 6 Jun "Moving forward with CRAM-MD5".  So this
> summary is with this in mind.
>
> I encourage clarification of one's own opinions in response to this
> message.  I intend to make a statement regarding WG consensus regarding this
> document before the week is out.

I prefer to publish the document. I think it should be Informational (I am
opposed to Standard Track) and have a warning saying that it only works for
US-ASCII usernames/passwords.

------=_Part_41236_20403585.1220534939724
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><div class="gmail_quote">On Wed, Sep 3, 2008 at 6:54 PM, Kurt Zeilenga <span dir="ltr">&lt;<a href="mailto:[e-mail]" target="_blank">[e-mail]</a>&gt;</span> wrote: 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">In Pasi recently suggested to the chairs: &quot;I believe it would be useful to post a message summarizing the WG members&#39; opinions on draft-ietf-sasl-crammd5: who&#39;s happy with progressing the document basically as-is, and who is not?&quot;<br>
<br>Most of the opinions I am aware of were stated under the belief that the I-D was going to progressed with a recommendation for publication on the Informational track. &nbsp; I believe that most of the opinions in stated under an assumption that the document would be modified to state the Intended Category is &quot;Informational&quot;, and that RFC 2195 would be moved to Historic status, as indicated in my 6 Jun &quot;Moving forward with CRAM-MD5&quot;. &nbsp;So this summary is with this in mind.<br>
<br>I encourage clarification of one&#39;s own opinions in response to this message. &nbsp;I intend to make a statement regarding WG consensus regarding this document before the week is out.</blockquote>
<div>I prefer to publish the document. I think it should be Informational (I am opposed to Standard Track) and have a warning saying that it only works for US-ASCII usernames/passwords.</div>
<div>&nbsp;</div></div></div>

------=_Part_41236_20403585.1220534939724--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83HsiY3016115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 10:54:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83HsiRb016114; Wed, 3 Sep 2008 10:54:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83HsXxn016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 3 Sep 2008 10:54:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m83HsVLF059672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Wed, 3 Sep 2008 17:54:33 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Summary of opinions regarding the CRAM-MD5 I-D
Date: Wed, 3 Sep 2008 10:54:31 -0700
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In Pasi recently suggested to the chairs: "I believe it would be  
useful to post a message summarizing the WG members' opinions on draft- 
ietf-sasl-crammd5: who's happy with progressing the document basically  
as-is, and who is not?"

Most of the opinions I am aware of were stated under the belief that  
the I-D was going to progressed with a recommendation for publication  
on the Informational track.   I believe that most of the opinions in  
stated under an assumption that the document would be modified to  
state the Intended Category is "Informational", and that RFC 2195  
would be moved to Historic status, as indicated in my 6 Jun "Moving  
forward with CRAM-MD5".  So this summary is with this in mind.

I encourage clarification of one's own opinions in response to this  
message.  I intend to make a statement regarding WG consensus  
regarding this document before the week is out.

Lyndon Nerenberg has stated he is opposed to publishing the document  
off the standards track.  I believe he thinks portions of the document  
need some further work.

Frank Ellerman has expressed opposing opinions regarding the content  
of the document, as well as the publication on the Informational track.

Chris Newman opinion seems best reflected by his 23 Jun statement "I  
support any action which gets a CRAM-MD5 revision published..." and  
his 29 July statement "I would not break any consensus that involved  
publishing a revision of CRAM."

Sam Hartman opinion seems to be that CRAM-MD5 should be obsoleted.  He  
has stated he would not be part of any consensus to publish CRAM-MD5  
on the Standards Track.

Pasi Eronen made a narrow statement regarding intended track of the  
document that implies he leans towards Informational but that he can  
live with Standards Track.   It is unclear whether he has formed an  
opinion with regard to the content of the document.

Simon Josefsson appears to be of the opinion currently that the I-D  
needs some revision before progression.  I note that he has suggested  
that the document could be revised so that would be suitable for  
publication on the Standards Tracks.  He suggested the WG consider  
obsoleting CRAM-MD5.

Kurt Zeilenga has raised concerns with publishing the document  
"basically as-is" (as Informational).  He has suggested that the  
document could be changed so that it might be suitable for publication  
on the Standards Track but doubts that the WG has sufficient energy to  
do so and/or that the WG would find those such changes would be too  
disruptive to existing deployments.  He has also suggested the WG  
consider obsoleting CRAM-MD5.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83HXluW015005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 10:33:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83HXl3v015004; Wed, 3 Sep 2008 10:33:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83HXdXi014993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 3 Sep 2008 10:33:46 -0700 (MST) (envelope-from [e-mail])
Received: from 70-5-45-223.area3.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m83HXZO5010326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 13:33:36 -0400 (EDT)
Date: Wed, 03 Sep 2008 13:33:35 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: GS2 status, and poll on wire encoding
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, September 03, 2008 09:53:30 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Wed, Sep 03, 2008 at 03:18:12PM +0200, Simon Josefsson wrote:
>> Can we do a quick poll to see determine a way forward?  Post a +1
>> indicating which of these you prefer:
>
> I think the poll is backwards.  We should vote on a layout for SCRAM and
> then let GS2 follow it so we can have wire-compatible SCRAM and
> SCRAM-as-GS2/GSS-mech.
>
> Sam summarized the SCRAM options that are amenable to Chris and pretty
> much anyone else who commented.  Let's start with that.


+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83Errd4002538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 07:53:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83ErrSe002537; Wed, 3 Sep 2008 07:53:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83Erg4X002508 for <[e-mail]>; Wed, 3 Sep 2008 07:53:53 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m83Ergwk023894 for <[e-mail]>; Wed, 3 Sep 2008 14:53:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m83Erg6c052867 for <[e-mail]>; Wed, 3 Sep 2008 08:53:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m83ErbBj001471; Wed, 3 Sep 2008 09:53:38 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m83ErUf2001470; Wed, 3 Sep 2008 09:53:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 3 Sep 2008 09:53:30 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: GS2 status, and poll on wire encoding
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 03, 2008 at 03:18:12PM +0200, Simon Josefsson wrote:
> Can we do a quick poll to see determine a way forward?  Post a +1
> indicating which of these you prefer:

I think the poll is backwards.  We should vote on a layout for SCRAM and
then let GS2 follow it so we can have wire-compatible SCRAM and
SCRAM-as-GS2/GSS-mech.

Sam summarized the SCRAM options that are amenable to Chris and pretty
much anyone else who commented.  Let's start with that.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83DIUQS094204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 06:18:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83DIUpR094203; Wed, 3 Sep 2008 06:18:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83DIGZs094190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 3 Sep 2008 06:18:29 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-18-41.bredband.comhem.se ([80.216.18.41] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KasFR-0005m5-D1 for [e-mail]; Wed, 03 Sep 2008 15:18:14 +0200
X-Hashcash: 1:22:080903:[e-mail]::O5JUnC/t5Xy9iGMW:USrc
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: GS2 status, and poll on wire encoding
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 03 Sep 2008 15:18:12 +0200
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The discussion on GS2 encoding appears to have slowed down.  As far as I
can tell, there is a preference for GS2 to use a textual wire encoding.
Possibly people who haven't spoken up disagree with that preference.  I
am ready to revise the document, but I'd like to understand if someone
would strongly disagree, to avoid wasting time modifying the document.

As far as I know, determining the wire encoding, and waiting for a
GSS-mechanism description of SCRAM, are the only issues that is holding
GS2 back.  If there are other concerns with the current document, please
let me know!

Can we do a quick poll to see determine a way forward?  Post a +1
indicating which of these you prefer:

1) Please make GS2 use a textual wire encoding

2) Please keep the binary wire encoding in GS2

3) I don't care, just get it finished ASAP
   (which would likely mean binary encoding since that is what the
   document currently uses, and rewriting it and reviewing the new
   document will take time)

4) Something else, namely: ....

Of course, the poll is informal, and is just for my information as
document editor.  Feel free to reword my text if it helps you to give a
better answer.

It would be useful if someone else would help to gauge consensus.  If
this thread doesn't lead to a clear answer, hopefully it will serve as
input to asking better questions.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83CW0lO090734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 05:32:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83CW0Zp090733; Wed, 3 Sep 2008 05:32:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83CVlqU090714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 3 Sep 2008 05:31:59 -0700 (MST) (envelope-from [e-mail])
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m83CVRf6020205; Wed, 3 Sep 2008 15:31:41 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 15:31:29 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 15:31:27 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Response to Frank Ellermann's appeal
Date: Wed, 3 Sep 2008 15:31:25 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Response to Frank Ellermann's appeal
Thread-Index: AckNwPtPnyyJmHYfSpCGFsdgp0/vqg==
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Sep 2008 12:31:27.0016 (UTC) FILETIME=[FC09EA80:01C90DC0]
X-Nokia-AV: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1. Background

On 2008-08-11, Kurt Zeilenga, co-chair of SASL WG, posted a message
(http://www.imc.org/ietf-sasl/mail-archive/msg03204.html):

> I believe there is consensus within the WG that RFC 2195 failed to
> adequately specify how character data inputs, in particular the
> shared secret, are to be encoded and prepared for input to
> cryptographic functions and this has lead to interoperability
> problems.  Your input was considered by the WG, but not found to be
> compelling.

Later on the same day, Frank Ellermann posted a reply
(http://www.imc.org/ietf-sasl/mail-archive/msg03204.html).

In his email, Frank argues that RFC 2195 only specifies the use of
ASCII passwords (and possibly other strings), and if some
implementations have allowed the use of non-ASCII characters, they
have implemented something that's not in the specification.

In the end of his email, Frank writes:

> I appeal that decision.  As remedy I propose to issue an IETF=20
> Last Call of the CRAM-MD5 draft on standards track.

There were off-list emails clarifying that this was intended as an
appeal to the Area Director. Since the topic has been discussed with
the WG chairs before, without being resolved to Frank's satisfaction,
an appeal to the AD is possible.


2. Summary

Frank's appeal raises the following objection:

The WG chair (Kurt Zeilenga) was incorrect to declare rough WG
consensus on RFC 2195 having interoperability problems.  In Frank's
opinion, RFC 2195, as specified in the RFC, does not in fact have
interoperability problems, and any interoperability problems would be
due to implementing undocumented functionality beyond RFC 2195. He
also believes that sufficiently many other WG members share this
opinion, so declaring rough WG consensus was incorrect.

In subsequent off-list emails, it has been clarified that the
following topics are not in the scope of this appeal:

- Whether draft-ietf-sasl-crammd5 should be published as
  Informational, Proposed Standard, Draft Standard, or Historic.
  While interoperability can be one consideration related to this
  question, other factors need to be considered as well.  Also, there
  is still ongoing WG discussions about this topic, so a process
  appeal (claiming consensus was incorrectly declared) or a
  substantive appeal (claiming the decision is wrong) would be
  premature.

- Whether implementations of draft-ietf-sasl-crammd5, which adds
  support for non-ASCII characters, are likely to have
  interoperability problems.

- Whether implementations of draft-ietf-sasl-crammd5 are likely to
  have interoperability problems with existing implementations of=20
  RFC 2195.

- Whether CRAM-MD5 is "secure enough", or more/less preferable=20
  or secure than some other SASL mechanisms.


3. Background research

When digging deeper to this topic, I found a number of things that,
while they're not directly related to Kurt's email on 2008-08-11, may
have partly contributed to the situation:

- Discussions about CRAM-MD5 have spread over a long time. I=20
  browsed through the archives for past two years, and had hard=20
  time getting a good picture of the situation (e.g. I couldn't=20
  even find a message summarizing the results of the March 2007
  WG last call).

- The WG charter is badly out of date, and apparently hasn't really
  reflected reality in a long time. Also, the proposed new charter=20
  text (from February 2008) didn't even list CRAM-MD5 at all, and
  even after reading the mailing list archive, it wasn't quite
  clear whether this was intentional or not.

- In his email on 2008-08-27, Kurt explained that when he wrote "I
  believe there is consensus.." (on 2008-08-11), his intent was to
  test this belief by stating it, not to declare WG consensus and
  close discussion. This distinction could have been phrased in a
  clearer way, and I find it plausible that some WG members did not
  read it this way.

Furthermore, it's not quite obvious that we even *need* WG consensus
on the specific question raised by Frank.  For draft-ietf-sasl-crammd5,=20
IMHO it's valuable to document what existing widely used CRAM-MD5
implementations have done, even if their behavior varies and isn't
ideal by today's standards.  Documenting that behavior doesn't
necessarily require us to agree on whether the implementations were
strictly following RFC 2195 or not. This particular question also
does not determine the intended status of the document.


4. Decision

I did not find sufficient information to clearly determine whether
Kurt's statement about rough consensus, if interpreted as declaring
consensus, would be incorrect or not. It's possible that the
information exists, but is just spread over too long time for me to
find. Given this, and Kurt's clarification on 2008-08-27 that his
intent was not to declare WG consensus, I do not believe any specific
AD action to remedy the situation is needed.

(Also, the remedy suggested by Frank -- "issue an IETF Last Call of the
CRAM-MD5 draft on standards track" -- does not seem to be appropriate,
given that the discussion about the ongoing status is still ongoing.)


5. Additional Suggestions

Although my decision is not to mandate any particular remedy for this
appeal, it's also clear that draft-ietf-sasl-crammd5 hasn't been
progressing well lately, and it's not a good example of how we'd like
the IETF WG process to work.=20

Instead of digging more deeply to the archives to figure out who said
what, I think we need to concentrate on getting the document ready and
shipped soon. This has been dragging on too long, and I guess we're
running out of steam for this work item. Thus, I'd like to make the
following suggestions for the WG to consider. These suggestions are
something I probably should have made before this mess turned into
an appeal, and they're not directly to the topic being appealed.

1) WG chairs: I believe it would be useful to post a message
summarizing the WG members' opinions on draft-ietf-sasl-crammd5: who's
happy with progressing the document basically as-is, and who is not?
And for the folks in the latter group, what *specific* changes would
make them to change their mind? (If you do not have the information
needed here, it would suggest that another WGLC could be helpful.)

For the question of intended status, it would be useful to know more
than binary opinions (e.g. "I prefer X but could live with Y" or "both
X and Y work for me"). If you don't have accurate information about
the current opinions, a straw poll might be useful to gather them
(explicitly giving flexible options like thes listed above).

Based on this, I think it would be useful to propose some kind of plan
for moving forward. I'd be fine with almost any plan that gets us to
completion within reasonable time (the milestone was 2 years ago), and
doesn't require the WG to come up with huge amounts of new energy for
this work item (which doesn't look very likely).

For the record: if there is rough WG consensus that the document is
appropriate for Standards Track, I am willing to send it to IETF last
call and IESG evaluation for Standards Track. Even though CRAM-MD5 is
not perfect by any means, it is widely deployed and used, and IMHO
it's valuable to have an up-to-date document describing it. My
personal preference might be more towards Informational, but I can
live with Standards Track, too, if that gets the document published.

The last call and IESG evaluation may, of course, result in the IESG
deciding that a different category is more appropriate. Also, since
the draft adds new non-trivial functionality to RFC 2195 (which isn't
covered by implementation reports of RFC 2195, I presume), if it's
going to be on Standards Track, it probably should be recycled at
Proposed Standard instead of being moved to Draft Standard.


2) To WG chairs and all WG members: Please get rough consensus on
updated SASL WG charter, which either includes CRAM-MD5 as a WG item
(and says something about it), or intentionally drops it, and submit
it to new IESG/IAB review (and eventually public review) as soon as
possible. Preferably within a couple of weeks.


3) To all WG members: No amount of tweaking will make CRAM-MD5=20
perfect -- and its been dragging on too long already -- so I would not
recommend spending lot of energy on it. It's valuable to document
existing widely deployed protocols, but once that's done to "good
enough" level, I think getting other documents, like the DIGEST-MD5
successor and GS2, ready, would be better use of our time.

Best regards,
Pasi