Subject: IETF64 SASL draft agenda
From: Tom Yu <[email-masked]>
To: [email-masked]
Date: Fri, 28 Oct 2005 18:30:10 -0400
List-Id: <ietf-sasl.imc.org>

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

Date: Thu, 27 Oct 2005 14:05:31 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt 
Sender: [email-masked]

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, [email-masked] 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 
>[email-masked] 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:
>        [email-masked].
>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:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-12.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-07.txt 
Date: Thu, 27 Oct 2005 15:50:02 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 26 Oct 2005 17:53:57 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL with user name as email address
Cc: [email-masked]
Sender: [email-masked]

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 [email-masked]. 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
<[email-masked]>.  More information
about the Cyrus SASL list can be found at:
<http://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl>.

Kurt, IETF SASL WG co-chair 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt 
Date: Wed, 26 Oct 2005 18:50:02 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 25 Oct 2005 17:53:26 +0200
From: =?UTF-8?B?QnVyZMOtayBQZXRy?= <[email-masked]>
Reply-To: [email-masked]
Organization: IT bridge.net s.r.o.
To: [email-masked]
Subject: SASL with user name as email address
Sender: [email-masked]

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 
[email-masked]. 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

Date: Mon, 24 Oct 2005 12:11:16 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Update to DIGEST-MD5
Sender: [email-masked]

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

Date: Sat, 22 Oct 2005 19:08:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: IETF64 SASL call for agenda items
Sender: [email-masked]

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.

To: [email-masked]
Subject: IETF64 SASL call for agenda items
From: Tom Yu <[email-masked]>
Date: Tue, 18 Oct 2005 22:58:05 -0400
Lines: 7
Sender: [email-masked]

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

Cc: [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Date: Wed, 12 Oct 2005 16:48:28 -0700
To: "Kurt D. Zeilenga" <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 15:31:43 -0700
To: Lyndon Nerenberg <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Cc: Chris Newman <[email-masked]>, [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Date: Wed, 12 Oct 2005 15:13:23 -0700
To: "Kurt D. Zeilenga" <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 12 Oct 2005 14:45:59 -0700
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

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 

To: [email-masked]
Subject: Re: CONSENSUS CALL: GSSAPI mechanism spec
From: Tom Yu <[email-masked]>
Date: Wed, 12 Oct 2005 14:17:53 -0400
Lines: 13
Sender: [email-masked]

>>>>> "tlyu" == Tom Yu <[email-masked]> 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

To: [email-masked]
Subject: Re: CONSENSUS CALL: DIGEST-MD5 AES cipher mode
From: Tom Yu <[email-masked]>
Date: Wed, 12 Oct 2005 14:16:23 -0400
Lines: 12
Sender: [email-masked]

>>>>> "tlyu" == Tom Yu <[email-masked]> 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

Date: Wed, 12 Oct 2005 10:52:23 -0700
From: Chris Newman <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 11 Oct 2005 13:26:02 +0200
Sender: [email-masked]

Chris Newman <[email-masked]> 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

Date: Tue, 11 Oct 2005 09:23:12 +0100
To: Lyndon Nerenberg <[email-masked]>, Chris Newman <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Cc: [email-masked]
Sender: [email-masked]

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
[email-masked]                      http://www.pscs.co.uk/

Cc: [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Date: Mon, 10 Oct 2005 20:03:13 -0700
To: Chris Newman <[email-masked]>
X-DCC-sgs_public_dcc_server-Metrics: orthanc.ca 1199; Body=2 Fuz1=2 Fuz2=2
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=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

Date: Mon, 10 Oct 2005 19:49:58 -0700
From: Chris Newman <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

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.

From: Lyndon Nerenberg <[email-masked]>
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
Date: Mon, 10 Oct 2005 17:49:32 -0700
To: [email-masked]
X-DCC-sgs_public_dcc_server-Metrics: orthanc.ca 1199; Body=1 Fuz1=1 Fuz2=1
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=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

To: [email-masked]
Subject: fwd: SASL WG session at IETF64
From: Tom Yu <[email-masked]>
Date: Mon, 03 Oct 2005 17:10:09 -0400
Lines: 41
Sender: [email-masked]

-------------------- Start of forwarded message --------------------
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: SASL WG session at IETF64
From: Tom Yu <[email-masked]>
Date: Mon, 03 Oct 2005 12:52:54 -0400
Message-ID: <[email-masked]>
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 --------------------

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: CONSENSUS CALL: remove CRAM-MD5 from standards track
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 01 Oct 2005 12:23:46 +0200
Sender: [email-masked]

Tom Yu <[email-masked]> 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