Subject: SASL to draft questionnaire

From: Chris Newman <[email-masked]>
Date: Tue, 29 Jul 2008 17:14:32 +0100

Here's a proposed questionnaire for an implementation report.

I am not volunteering to compile responses to the questions, but I am 
willing to answer these questions for my implementations.

		- Chris

---
RFC 4422 Implementation Questionnaire
===============================================
0. Contact and Description
Organization Name:
Implementation (Software or Service) Name:

1. Have you implemented SASL and/or SASL mechanism?

2. Which SASL mechanisms have you implemented?

3. For how long has it been deployed?

4. What features have NOT been implemented from SASL?

5. What features of SASL or SASL mechanisms are problematic for your 
implementation?

6. Please add any other comments you wish to share:

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jul 2008 12:22:52 -0600

> Here's a proposed questionnaire for an implementation report.

Is the intended audience for the questionnaire only those who have 
implemented SASL libraries, or also authors and implementors of using 
protocols such as IMAP and XMPP? I could work to gather feedback from 
the XMPP community if desired.

Peter

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jul 2008 00:11:19 +0100

On Jul 29, 2008, at 7:22 PM, Peter Saint-Andre wrote:

> implemented SASL libraries, or also authors and implementors of  
> using protocols such as IMAP and XMPP? I could work to gather  
> feedback from the XMPP community if desired.

I think the audience includes all who have implemented any portion of  
the specification.  Depending on the boundaries between your  
application code and the library, that might include you.   If so, you  
should try to make clear which portion of specification you  
implemented, versus implementations you incorporate through a  
library.  Also independent versus dependent (derivative) should be  
distinguished.  I would suggest that addition of a question:

   Is your implementation of SASL derived from, or dependent upon, any  
other implementation (such as SASL)?  If so, explain.

This would help in evaluating whether we have two independent  
implementations of each feature.

Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jul 2008 09:08:03 +0100

On Jul 30, 2008, at 12:11 AM, Kurt Zeilenga wrote:

> I think the audience includes all who have implemented any portion  
> of the specification.  Depending on the boundaries between your  
> application code and the library, that might include you.   If so,  
> you should try to make clear which portion of specification you  

s/as SASL/as a SASL library/

---

From: Chris Newman <[email-masked]>
Date: Wed, 30 Jul 2008 18:14:47 +0100

> RFC 4422 Implementation Questionnaire
   Sun Microsystems, formerly Sun/Netscape alliance, formerly Innosoft
> Implementation (Software or Service) Name:
   See 1.

> 1. Have you implemented SASL and/or SASL mechanism?

Yes.  I have written two implementations, maintained a third and 
assisted-to-maintain/integrated with a fourth implementation.

A. Innosoft SASL library: full implementation of SASL API and abstraction 
integrated into two IMAP servers, two POP servers and an SMTP server. 
Supports shared libraries for SASL mechanisms.  Designed to work with 
OS-native authentication systems and independent authentication systems. 
Both client & server support (test client only).  Test client and test 
server code also support ACAP & IMSP.  Still used in Process Software's 
PMDF product.

B. Sun "HULA" library: An LDAP-centric SASL API with co-process model for 
plug-in mechanisms.  Integrated into POP and IMAP proxy.  Server-only.

C. Netscape-dervied proxy: IMAP and POP proxy implementation with 
hard-coded mechanisms and no abstraction.  Server with limited proxy-client 
support.  Server code has been replaced by B in current product and is no 
longer in production use.

D. Sun JES libsasl library: used by POP, IMAP, SMTP and LDAP servers.  Also 
LDAP client library and test client.

> 1.5  Is your implementation of SASL derived from, or dependent upon, any

A: implemented by Chris Newman, SASL API same as D (independent 
implementations of
   same API).

B: implemented by Chris Newman, new independent API but informed by A & C.

C: implemented by Rob Walker, independent.

D: CMU SASL fork with a few changes, same API as A.

> 2. Which SASL mechanisms have you implemented?

A: Plug-ins: PLAIN, LOGIN, CRAM-MD5, ANONYMOUS, EXTERNAL, DIGEST-MD5, OTP. 
Experimental: SCRAM-MD5 (1999), PASSDSS.

B: Built-in: PLAIN, LOGIN, ANONYMOUS, EXTERNAL, CRAM-MD5.

C: Integrated: PLAIN, LOGIN, EXTERNAL, CRAM-MD5.

D: Built-in: EXTERNAL, ANONYMOUS.  Plug-in: PLAIN, LOGIN, CRAM-MD5, 
DIGEST-MD5.  The LDAP server and client also support GSSAPI.

PLAIN is as specified in RFC 2595.

> 3. For how long has it been deployed?

A: about 12 years
B: about 2 years
C: about 10 years
D: about 5 years

> 4. What features have NOT been implemented from SASL?

SASL security layers are largely unimplemented except for experimental 
unreleased code for A and possible LDAP+GSSAPI support (I'm unsure about 
the latter).

Except for the test client/server for A, these do not implement "additional 
data with a successful outcome" in a protocol profile.

None of these implement SASLprep.

Only D has implemented multiple authentications.

While most of these mechanisms/implementations in theory support UTF-8 
usernames and passwords that feature has never been tested with any of them 
to my knowledge.  A & D validate basic UTF-8 syntax.  B validates full 
UTF-8 syntax as specified in RFC 3629.

None of the test/proxy clients check for for a mechanism list modified by 
an attacker and close the connection (a SHOULD in RFC 4422).

> 5. What features of SASL or SASL mechanisms are problematic for your

We have had bugs with the empty initial client response encoded as "=" in 
SMTP and POP.  I have seen the same bug in other implementations.  This 
seems to be implementation only.

The question of whether and when EXTERNAL is used with TLS in the context 
of imaps and pops is unclear and does not interoperate.  While it is clear 
for IMAP+STARTTLS and POP+TLS, there are significant clients that get this 
wrong.

We continue to advertise the non-standard LOGIN mechanism in SMTP as it is 
not clear that PLAIN is used by all clients.  We have disabled use of this 
mechanism in all other protocols.

We actively use both SASL-PLAIN and a non-standard ("PROXYAUTH") separate 
protocol command for administrative proxy authentication.  Due to the NUL 
octets in SASL PLAIN, many customers/support staff prefer the non-standard 
mechanism.

We had some minor problems with DIGEST-MD5 interoperability.  We have 
decided to deprecate and remove DIGEST-MD5 from future releases of 
SMTP/POP/IMAP due to lack of customer interest and the cost of carrying 
forward that level of complexity.

> 6. Please add any other comments you wish to share:

We have not implemented SASLprep because we have no customer demand for it 
and the cost/benefit analysis suggests it is not worth the engineering 
investment.

Getting the TLS security layer correct in all our protocols has required a 
huge ongoing engineering investment.  As we view SASL security layers as 
inferior to TLS we have no interest in repeating that investment.  Channel 
Binding seems like a much more cost-effective way to achieve the only 
benefit SASL security layers provide over TLS security layers.

I fully support advancement of RFC 4422 to draft status.  It is my opinion 
both SASLprep and SASL security layers should be deprecated or omitted when 
RFC 4422 advances.  However, I would rather 4422 advances with those 
features than have it not advance.

		- Chris

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 31 Jul 2008 11:27:45 +0200

On Jul 30, 2008, at 7:14 PM, Chris Newman wrote:

> A. Innosoft SASL library: full implementation of SASL API and  
> abstraction integrated into two IMAP servers, two POP servers and an  
> SMTP server. Supports shared libraries for SASL mechanisms.   
> Designed to work with OS-native authentication systems and  
> independent authentication systems. Both client & server support  
> (test client only).  Test client and test server code also support  
> ACAP & IMSP.  Still used in Process Software's PMDF product.
>
> B. Sun "HULA" library: An LDAP-centric SASL API with co-process  
> model for plug-in mechanisms.  Integrated into POP and IMAP proxy.   
> Server-only.
>
> hard-coded mechanisms and no abstraction.  Server with limited proxy- 
> client support.  Server code has been replaced by B in current  
> product and is no longer in production use.
>
> D. Sun JES libsasl library: used by POP, IMAP, SMTP and LDAP  
> servers.  Also LDAP client library and test client.
>
> A: Plug-ins: PLAIN, LOGIN, CRAM-MD5, ANONYMOUS, EXTERNAL, DIGEST- 
> MD5, OTP. Experimental: SCRAM-MD5 (1999), PASSDSS.
>
> SASL security layers are largely unimplemented except for  
> experimental unreleased code for A and possible LDAP+GSSAPI support  
> (I'm unsure about the latter).
I can confirm SASL security layers are implemented for LDAP+GSSAPI and  
LDAP+DIGEST-MD5 with implementation D.

Ludovic.

>
>
> Except for the test client/server for A, these do not implement  
> "additional data with a successful outcome" in a protocol profile.
>
> While most of these mechanisms/implementations in theory support  
> UTF-8 usernames and passwords that feature has never been tested  
> with any of them to my knowledge.  A & D validate basic UTF-8  
> syntax.  B validates full UTF-8 syntax as specified in RFC 3629.
>
> None of the test/proxy clients check for for a mechanism list  
> modified by an attacker and close the connection (a SHOULD in RFC  
> 4422).
>
> We have had bugs with the empty initial client response encoded as  
> "=" in SMTP and POP.  I have seen the same bug in other  
> implementations.  This seems to be implementation only.
>
> The question of whether and when EXTERNAL is used with TLS in the  
> context of imaps and pops is unclear and does not interoperate.   
> While it is clear for IMAP+STARTTLS and POP+TLS, there are  
> significant clients that get this wrong.
>
> We continue to advertise the non-standard LOGIN mechanism in SMTP as  
> it is not clear that PLAIN is used by all clients.  We have disabled  
> use of this mechanism in all other protocols.
>
> We actively use both SASL-PLAIN and a non-standard ("PROXYAUTH")  
> separate protocol command for administrative proxy authentication.   
> Due to the NUL octets in SASL PLAIN, many customers/support staff  
> prefer the non-standard mechanism.
>
> We had some minor problems with DIGEST-MD5 interoperability.  We  
> have decided to deprecate and remove DIGEST-MD5 from future releases  
> of SMTP/POP/IMAP due to lack of customer interest and the cost of  
> carrying forward that level of complexity.
>
> We have not implemented SASLprep because we have no customer demand  
> for it and the cost/benefit analysis suggests it is not worth the  
> engineering investment.
>
> Getting the TLS security layer correct in all our protocols has  
> required a huge ongoing engineering investment.  As we view SASL  
> security layers as inferior to TLS we have no interest in repeating  
> that investment.  Channel Binding seems like a much more cost- 
> effective way to achieve the only benefit SASL security layers  
> provide over TLS security layers.
>
> I fully support advancement of RFC 4422 to draft status.  It is my  
> opinion both SASLprep and SASL security layers should be deprecated  
> or omitted when RFC 4422 advances.  However, I would rather 4422  
> advances with those features than have it not advance.
>
> 		- Chris
>
>

Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Lead               Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Thu, 31 Jul 2008 11:27:45 +0200
From: Ludovic Poitou <[email-masked]>
Subject: Re: Sun implementation report answers
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Jul 30, 2008, at 7:14 PM, Chris Newman wrote:

> A. Innosoft SASL library: full implementation of SASL API and  
> abstraction integrated into two IMAP servers, two POP servers and an  
> SMTP server. Supports shared libraries for SASL mechanisms.   
> Designed to work with OS-native authentication systems and  
> independent authentication systems. Both client & server support  
> (test client only).  Test client and test server code also support  
> ACAP & IMSP.  Still used in Process Software's PMDF product.
>
> B. Sun "HULA" library: An LDAP-centric SASL API with co-process  
> model for plug-in mechanisms.  Integrated into POP and IMAP proxy.   
> Server-only.
>
> hard-coded mechanisms and no abstraction.  Server with limited proxy- 
> client support.  Server code has been replaced by B in current  
> product and is no longer in production use.
>
> D. Sun JES libsasl library: used by POP, IMAP, SMTP and LDAP  
> servers.  Also LDAP client library and test client.
>
> A: Plug-ins: PLAIN, LOGIN, CRAM-MD5, ANONYMOUS, EXTERNAL, DIGEST- 
> MD5, OTP. Experimental: SCRAM-MD5 (1999), PASSDSS.
>
> SASL security layers are largely unimplemented except for  
> experimental unreleased code for A and possible LDAP+GSSAPI support  
> (I'm unsure about the latter).
I can confirm SASL security layers are implemented for LDAP+GSSAPI and  
LDAP+DIGEST-MD5 with implementation D.

Ludovic.

>
>
> Except for the test client/server for A, these do not implement  
> "additional data with a successful outcome" in a protocol profile.
>
> While most of these mechanisms/implementations in theory support  
> UTF-8 usernames and passwords that feature has never been tested  
> with any of them to my knowledge.  A & D validate basic UTF-8  
> syntax.  B validates full UTF-8 syntax as specified in RFC 3629.
>
> None of the test/proxy clients check for for a mechanism list  
> modified by an attacker and close the connection (a SHOULD in RFC  
> 4422).
>
> We have had bugs with the empty initial client response encoded as  
> "=" in SMTP and POP.  I have seen the same bug in other  
> implementations.  This seems to be implementation only.
>
> The question of whether and when EXTERNAL is used with TLS in the  
> context of imaps and pops is unclear and does not interoperate.   
> While it is clear for IMAP+STARTTLS and POP+TLS, there are  
> significant clients that get this wrong.
>
> We continue to advertise the non-standard LOGIN mechanism in SMTP as  
> it is not clear that PLAIN is used by all clients.  We have disabled  
> use of this mechanism in all other protocols.
>
> We actively use both SASL-PLAIN and a non-standard ("PROXYAUTH")  
> separate protocol command for administrative proxy authentication.   
> Due to the NUL octets in SASL PLAIN, many customers/support staff  
> prefer the non-standard mechanism.
>
> We had some minor problems with DIGEST-MD5 interoperability.  We  
> have decided to deprecate and remove DIGEST-MD5 from future releases  
> of SMTP/POP/IMAP due to lack of customer interest and the cost of  
> carrying forward that level of complexity.
>
> We have not implemented SASLprep because we have no customer demand  
> for it and the cost/benefit analysis suggests it is not worth the  
> engineering investment.
>
> Getting the TLS security layer correct in all our protocols has  
> required a huge ongoing engineering investment.  As we view SASL  
> security layers as inferior to TLS we have no interest in repeating  
> that investment.  Channel Binding seems like a much more cost- 
> effective way to achieve the only benefit SASL security layers  
> provide over TLS security layers.
>
> I fully support advancement of RFC 4422 to draft status.  It is my  
> opinion both SASLprep and SASL security layers should be deprecated  
> or omitted when RFC 4422 advances.  However, I would rather 4422  
> advances with those features than have it not advance.
>
> 		- Chris
>
>

Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Lead               Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date: Wed, 30 Jul 2008 21:19:20 -0700
Sender: [email-masked]

> Not speaking for Chris, I'd certainly oppose to "demote"
> CRAM-MD5.  A fine, mature draft standard.  Of course it
> has various limitations, maturity comes with "old", but
> "old" is not always "obsolete".

With my editor's eye-shade firmly removed, I also want to state my =20
opposition to taking this document off the standards track. Given that =20=

almost every modern email client (and most servers) support it, it's =20
arguably the most widely deployed SASL mechanism on the Internet =20
today. It would be a disservice to each and every one of those end-=20
users if we trashed the mechanism, especially considering there is no =20=

viable replacement anywhere in sight.

While CRAM-MD5 might not live up to the ideals of some IESG members' =20
vision of the world, it suffices today =96 and has for the last fourteen =
=20
years. And in those fourteen years, nothing has come along to supplant =20=

it. Its success speaks for itself.

When a new mechanism manages to achieve the same degree of deployment =20=

and acceptance, then we might consign CRAM-MD5 to the bin, but not =20
before.

--lyndon=

Date: Wed, 30 Jul 2008 19:01:42 +0100
From: Chris Newman <[email-masked]>
Subject: Re: Scram as a gs2 mechanism ABNF
To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

--On July 29, 2008 8:12:40 -0400 Sam Hartman <[email-masked]> wrote:
> Here are Nico and my notes on scram as a GSS-API mechanism.
>
> My hope is that Chris and others will find this acceptable.

FYI, I am not likely to find this protocol acceptable, but I want to make 
sure I understand the protocol before I commit one way or the other.  At 
this point, I do not understand the "mac" rule and need to confirm my 
assumptions.

My basis for evaluating this protocol relative to the current SCRAM 
protocol is as follows:

I recognize a modest benefit in code sharing, 
deployment/implementation/interoperability if a SCRAM-GS2 mechanism and a 
SCRAM-SASL mechanism use the same bits-on-the-wire as both a GSSAPI-guru 
and a SASL-app-guy can implement in their comfort zone.  I contrast that 
with separate SCRAM-GS2 used for things like NFS that are GSSAPI only, and 
SCRAM-SASL used for things that support SASL.  In that case, there's risk 
of the GSSAPI mechanism leaking through in a SASL-based protocol (even if 
we say SHOULD NOT) and introducing interop problems -- much the way 
GSS-SPNEGO leaked into SASL.  Regardless, if SCRAM is to succeed it needs 
to be implemented in multiple frameworks (HTTP-Auth, SASL, GSSAPI, 
SSH-auth, perhaps EAP).  So the benefit of potentially eliminating one 
framework is only a modest benefit.

I contrast that with the additional complexity of implementing a pure SASL 
mechanism.  GSSAPI is not an app-level protocol; it's an OS-level protocol 
when present.  Deploying things in the OS often takes longer than deploying 
them in the app layer.  So I consider the cost of deploying the SASL 
mechanism the overriding consideration in terms of actually getting this 
mechanism deployed.

Constant binary strings are ugly, but tolerable especially if they are few 
and only a prefix or postfix.  A length is much more problematic 
(regardless of whether or not it is binary).  Each computed length is an 
opportunity for a buffer overflow implementation bug and thus makes the 
protocol itself less secure when it enters the real world.  A security 
advisory saying SCRAM is insecure due to a buffer overflow in someone's 
implementation would do harm to SCRAM deployment.

If my understanding of the number of unnecessary length fields (6) this 
change introduces is correct, then it reduces the deployment security of 
SCRAM by an amount I find unacceptable.

> If not, there are changes to GS2 that could almost certainly make
> Chris happy.
>
>     gs2-length = 4*octet
>     ctx-length = gs2-length
>     wrap-length = gs2-length

I am assuming the "4*octet" is a big-endian 32-bit unsigned integer octet 
count of part of the protocol.  I am assuming ctx-length covers the 
"context" (for each exchange respectively: scram-c1, scram-s1, 
scram-c2-ctx, scram-s2-ctx).  I am assuming wrap-length covers the 
"wrapped" portion of each exchange (respectively: 0, 0, scram-c2-wrap, 
scram-s2-wrap).

>     gs2-header = ctx-length wrap-length
>
>     der-definite-length = %00-%7F / %81 octet / %82 2*octet / %83 3*octet
> / %84 4*octet
>
>     gss-init-ctx-header = %60 der-definite-length "<constant encoded OID
> octet string here>"

I am assuming that the "der-definite-length" is the length of the encoded 
OID only.  I presume gss-init-ctx-header will collapse to a constant octet 
string for each SCRAM mechanism name and no SCRAM implementation will be 
required to generate a DER ASN.1 length for this purpose.

>     scram-c1 = gs2-header gss-init-ctx-header username "," hash-list ","
> nonce 	       ;; wrap-length here is 4*%00
>
>     scram-s1 = gs2-header nonce "," hash-list "," salt "," iteration-count
> 	       ;; wrap-length here is 4*%00
>
>     mac = "m=" base64 ";"
>           ;; This is a GSS wrap with integrity token for SCRAM; normally
> 	  ;; this is all it will be, but a true SCRAM GSS mechanism may
> 	  ;; have sequence numbers too

I do not understand where the content of the base64 comes from.  How is the 
content computed by a SCRAM implementation with no GSSAPI library present?

>     channel-binding = *(octet)
>
>     scram-c2-ctx = nonce "," proof
>     scram-c2-wrap = mac "," 4*%00 channel-binding 4*octet %00
>                     [channel-binding] [authzid]
>     scram-c2 = gs2-header scram-c2-ctx scram-c2-wrap

I am confused about why the channel-binding may appear twice.  Can you 
explain?

>     scram-s2-ctx = verifier
>     scram-c2-wrap = mac "," ( %08 / %00 ) 3*%00
>     scram-s2 = gs2-header scram-s2-ctx scram-s2-wrap
>
>

Date: Wed, 30 Jul 2008 18:14:47 +0100
From: Chris Newman <[email-masked]>
Subject: Sun implementation report answers
To: [email-masked]
Sender: [email-masked]

   See 1.

A: about 12 years
B: about 2 years
C: about 10 years
D: about 5 years

		- Chris

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-ietf-sasl-digest-to-historic-00.txt
Date:  Wed, 30 Jul 2008 13:54:02 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 20
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

> Title           : Moving DIGEST-MD5 to Historic
> Author(s)       : A. Melnikov
> Filename        : draft-ietf-sasl-digest-to-historic-00.txt

In the otherwise apparently complete list of problems add:

| 9.  MD5-sess in RFC 2831 and RFC 2617 are incompatible.
|     RFC 2831 uses a "raw" (binary) hash, where RFC 2617
|     uses a hex. representation of this hash.
|     A corresponding RFC 2617 erratum was reported after
|     the publication of RFC 2831.

Of course all MD5-sess RFC 2831 examples published in RFCs
use the RFC 2831 variant, not the RFC 2617 variant. =20

The second statement about the RFC 2617 erratum might be
unnecessary, but it explains how that happened, and that
this was not some intentional RFC 2831 feature.

 Frank

Cc: Peter Saint-Andre <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: SASL to draft questionnaire
Date: Wed, 30 Jul 2008 09:08:03 +0100
Sender: [email-masked]

> implementations of each feature.

Cc: Chris Newman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Subject: Re: SASL to draft questionnaire
Date: Wed, 30 Jul 2008 00:11:19 +0100
Sender: [email-masked]

Kurt

Date: Tue, 29 Jul 2008 12:22:52 -0600
From: Peter Saint-Andre <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: SASL to draft questionnaire
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000003010901060101050709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter

--------------ms000003010901060101050709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000003010901060101050709--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-digest-to-historic-00.txt 
Date: Tue, 29 Jul 2008 09:15:03 -0700 (PDT)
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           : Moving DIGEST-MD5 to Historic
	Author(s)       : A. Melnikov
	Filename        : draft-ietf-sasl-digest-to-historic-00.txt
	Pages           : 7
	Date            : 2008-07-29

This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831.  It recommends that DIGEST-MD5 to be marked as OBSOLETE in
the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to
Historic status.

Note

A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.  Discussion
and suggestions for improvement are requested, and should be sent to
[email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-digest-to-historic-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-digest-to-historic-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Tue, 29 Jul 2008 17:14:32 +0100
From: Chris Newman <[email-masked]>
Subject: SASL to draft questionnaire
To: [email-masked]
Sender: [email-masked]

		- Chris

---

Date: Tue, 29 Jul 2008 15:32:56 +0100
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I was just performing a technical review of a document with "Intended 
Status: Standards Track" and stating my personal opinion of that intended 
status.  I would not break any consensus that involved publishing a 
revision of CRAM.

		- Chris

--On July 28, 2008 5:29:36 -0400 Tom Yu <[email-masked]> wrote:

> Chris Newman <[email-masked]> writes:
>
>> I have reviewed this and support its advancement on the standards track.
>
> We had Working Group consensus to take CRAM-MD5 off the standards
> track.  Are you suggesting that we re-evaluate that consensus?
>

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Scram as a gs2 mechanism ABNF
Date: Tue, 29 Jul 2008 08:45:34 -0400
Sender: [email-masked]

I do completely understand these are very rough.
I'd be happy to help explain things.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Scram as a gs2 mechanism ABNF
Date: Tue, 29 Jul 2008 08:12:40 -0400
Sender: [email-masked]

Here are Nico and my notes on scram as a GSS-API mechanism.

My hope is that Chris and others will find this acceptable.

If not, there are changes to GS2 that could almost certainly make
Chris happy.

    gs2-length = 4*octet
    ctx-length = gs2-length
    wrap-length = gs2-length

    gs2-header = ctx-length wrap-length

    der-definite-length = %00-%7F / %81 octet / %82 2*octet / %83 3*octet / %84 4*octet

    gss-init-ctx-header = %60 der-definite-length "<constant encoded OID octet string here>"

    scram-c1 = gs2-header gss-init-ctx-header username "," hash-list "," nonce
	       ;; wrap-length here is 4*%00

    scram-s1 = gs2-header nonce "," hash-list "," salt "," iteration-count
	       ;; wrap-length here is 4*%00

    mac = "m=" base64 ";"
          ;; This is a GSS wrap with integrity token for SCRAM; normally
	  ;; this is all it will be, but a true SCRAM GSS mechanism may
	  ;; have sequence numbers too
    channel-binding = *(octet)

    scram-c2-ctx = nonce "," proof
    scram-c2-wrap = mac "," 4*%00 channel-binding 4*octet %00 [channel-binding] [authzid]
    scram-c2 = gs2-header scram-c2-ctx scram-c2-wrap

    scram-s2-ctx = verifier
    scram-c2-wrap = mac "," ( %08 / %00 ) 3*%00
    scram-s2 = gs2-header scram-s2-ctx scram-s2-wrap

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Subject: Re: Updating SASLprep
Date: Tue, 29 Jul 2008 09:52:02 +0100
Sender: [email-masked]

On Jul 29, 2008, at 2:12 AM, Frank Ellermann wrote:

>
> Kurt Zeilenga wrote:
>
>> I would like to see SASLprep (and stringprep) revised to be
>> Unicode-version agile (as opposed to tied to a particular
>> version of Unicode).
>
> Definitely a MUST have, but it could make sense to wait what
> IDNAbis will do (this work is supposed to be ready this year).

I think it did make sense to wait for IDNAbis to get far enough along  
to under its impact upon stringprep and non-nameprep profiles of  
stringprep.  IDNAbis is now far enough along....

-- Kurt

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Channel binding for HTTP Digest Authentication
Date: Tue, 29 Jul 2008 09:37:15 +0100
Sender: [email-masked]

If time permits, I would like to discuss Stephan's "Channel binding  
for HTTP Digest Authentication" I-D as it might have some influence on  
our work.
http://tools.ietf.org/html/draft-santesson-digestbind-01

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Updating SASLprep
Date:  Tue, 29 Jul 2008 03:12:46 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 10
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Kurt Zeilenga wrote:

> I would like to see SASLprep (and stringprep) revised to be
> Unicode-version agile (as opposed to tied to a particular
> version of Unicode).

Definitely a MUST have, but it could make sense to wait what
IDNAbis will do (this work is supposed to be ready this year).

 Frank

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Updating SASLprep
Date: Mon, 28 Jul 2008 23:54:34 +0100
Sender: [email-masked]

In the context of discussing our charter update, I'd like to discuss  
(during our IETF#72 session and on list) the need to update SASLprep  
[RFC4013] (and stringprep) and how the such work should be done (e.g.,  
within SASL WG, some other WG, and/or an individual basis).

I would like to see SASLprep (and stringprep) revised to be Unicode- 
version agile (as opposed to tied to a particular version of Unicode).

-- Kurt

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date:  Mon, 28 Jul 2008 12:36:21 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Tom Yu wrote:

> Are you suggesting that we re-evaluate that consensus?

Not speaking for Chris, I'd certainly oppose to "demote"
CRAM-MD5.  A fine, mature draft standard.  Of course it
has various limitations, maturity comes with "old", but
"old" is not always "obsolete". =20

I've submitted a modification request for the CRAM-MD5=20
registry enter, the "intended use" should be "COMMON".

 1F

To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
From: Tom Yu <[email-masked]>
Date: Mon, 28 Jul 2008 05:29:36 -0400
Lines: 6
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

> I have reviewed this and support its advancement on the standards track.

We had Working Group consensus to take CRAM-MD5 off the standards
track.  Are you suggesting that we re-evaluate that consensus?

Date: Fri, 18 Jul 2008 18:20:31 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
To: [email-masked]
Sender: [email-masked]

I have reviewed this and support its advancement on the standards track.

		- Chris

--On July 14, 2008 11:45:02 -0700 [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		: The CRAM-MD5 SASL Mechanism
> 	Author(s)	: L. Nerenberg
> 	Filename	: draft-ietf-sasl-crammd5-10.txt
> 	Pages		: 10
> 	Date		: 2008-7-11
> 	
> This document defines a simple challenge-response authentication
>    mechanism, using a keyed MD5 digest, for use with the Simple
>    Authentication and Security Layer (SASL).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-10.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.
>

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-10.txt 
Date: Mon, 14 Jul 2008 11:45:02 -0700 (PDT)
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		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-10.txt
	Pages		: 10
	Date		: 2008-7-11
	
This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-10.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-crammd5-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-10.txt 
Date: Sun, 13 Jul 2008 10:45:02 -0700 (PDT)
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 GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson
	Filename        : draft-ietf-sasl-gs2-10.txt
	Pages           : 34
	Date            : 2008-07-13

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific
notion of channel binding.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-10.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-gs2-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

To: [email-masked]
Subject: SASL agenda items for IETF72
From: Tom Yu <[email-masked]>
Date: Fri, 11 Jul 2008 18:34:33 -0400
Lines: 12
Sender: [email-masked]

Draft Working Group agendas are due on July 16.  Please let the chairs
know if you have items you would like to put on the agenda for IETF72.

I would start with

* rechartering
* CRAM
* GS2
* SCRAM
* interop

Any others?

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt
Date:  Thu, 10 Jul 2008 18:10:36 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 24
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

JFTR, Paul Hoffman <[email-masked]> wrote on the DNSEXT list:

> At 2:46 PM +0200 7/10/08, Florian Weimer wrote:

>> ... I was mistaken about the strength of the MD5 attacks published so
>> far.  D'oh!
=20
> It is not the strength: it is the type of protection. If you need=20
> collision-resistance, you can probably safely assume that MD5 is too=20
> weak for anything, and getting weaker all the time. If you need=20
> preimage strength, MD5 is still untouched at 128 bits, and there=20
> haven't even been strong hints of any preimage weakness even though,=20
> post-Wang, there has been a huge amount of effort by people who want=20
> to be the first to show an attack.
=20
>> Given that, I agree that it deprecating HMAC-MD5 is premature, but =
the
>> three octets "MD5" are unfortunately tainted forever.
=20
> Not if we don't spread the FUD. It's really not that hard. Hashes=20
> have three properties (there are actually two types of preimages),=20
> and only one has been found weak in MD5 and SHA1. Things that don't=20
> use that property are not affected by the weakness of the property.

Date: Sun, 06 Jul 2008 15:29:22 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, Chris Newman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Jeffrey Hutzelman writes:
>  
>
>>On Mon, 31 Mar 2008, Hallvard B Furuseth wrote:
>>    
>>
>>>I think security requires that it can return one list of mechanisms
>>>which will work and one with mechanisms which might work.  (Both subsets
>>>of those reachable without mechanism-negotiation, as you say below.)
>>>(...)
>>>      
>>>
>>I haven't fully paged this discussion back in yet, but...
>>    
>>
>:-)
>  
>
Replying to this message after guarantying that everybody paged out this 
conversion :-).

>>I don't think you actually want to distinguish between two lists,
>>because doing so provides no utility.  I agree that it should be OK to
>>offer mechanisms that won't actually work for this user.  Doing so
>>increases the chance that the client will choose one of those, causing
>>authentication to fail when it could have succeeded, but that's
>>unlikely in practice because often the client has been configured to
>>expect a particular mechanism.
>>    
>>
>But the reason I suggested a mechanism-negotiation mechanism in the
>first place was situations where different users have different
>such as when the site is upgrading from an old mechanism.
>
>If nothing else, a "will work" list can reduce the amount of user
>interaction:  The client can use that right ahead, but ask the user
>for help if there are only "might work" mechanisms.
>
>Alternatively the client could try several "might work" mechanisms in
>succession, but as I mentioned that can interfere with policy about
>max allowed failed logins.
>
A server enforcing this policy would have to distinguish between "lack 
of secret for this user and this mechanism" and "the supplied secret is 
incorrect".
If the server implementation doesn't do that, it is broken.

>Or for that matter different mechanisms
>can need different information from the user - and thus again more user
>interaction than necessary.
>  
>
A properly written client only need to ask for a password once, if the 
server can report back lack of secret.
But yes, this can be quite annoying for users otherwise.

As a side note: I think we really need to spend some time telling client 
implementors how to implement retries/fallback during SASL negotiation.

>The "might work" list might offer no utility when there is a "will work"
>mechanism, if so a single list with a "will work"-flag is enough.
>  
>