Re: Sun implementation report answers

[Ludovic Poitou <[e-mail]>]

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

>
> Putting on my implementer hat, here are my answers:
>
>> RFC 4422 Implementation Questionnaire
>> ===============================================
>> 0. Contact and Description
>> Organization Name:
>  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
>>     other implementation (such as SASL)?  If so, explain.
>
> 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).
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.
>
> 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
>> implementation?
>
> 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
>
>

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







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 m6V9S6Y3076742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 02:28:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6V9S6w2076741; Thu, 31 Jul 2008 02:28:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6V9S2DT076734 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 31 Jul 2008 02:28:04 -0700 (MST) (envelope-from [e-mail])
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6V9RpxG000963 for <[e-mail]>; Thu, 31 Jul 2008 09:28:02 GMT
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 31 Jul 2008 10:27:51 +0100 (BST)
Received: from dhcp-egnb07-211-104.France.Sun.COM ([129.157.211.104]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 31 Jul 2008 10:27:47 +0100 (BST)
Date: Thu, 31 Jul 2008 11:27:45 +0200
From: Ludovic Poitou <[e-mail]>
Subject: Re: Sun implementation report answers
In-reply-to: <9D396836FF4A2A781BD30A32@446E7922C82D299DB29D899F>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.926)
Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F> <9D396836FF4A2A781BD30A32@446E7922C82D299DB29D899F>
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 Jul 30, 2008, at 7:14 PM, Chris Newman wrote:

>
> Putting on my implementer hat, here are my answers:
>
>> RFC 4422 Implementation Questionnaire
>> ===============================================
>> 0. Contact and Description
>> Organization Name:
>  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
>>     other implementation (such as SASL)?  If so, explain.
>
> 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).
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.
>
> 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
>> implementation?
>
> 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
>
>

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






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 m6V4Jbc8053807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 21:19:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6V4Jb5M053806; Wed, 30 Jul 2008 21:19:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (gandalf.orthanc.ca [216.40.124.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6V4JXtH053797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 30 Jul 2008 21:19:35 -0700 (MST) (envelope-from [e-mail])
Received: from peregrin.orthanc.ca (peregrin.orthanc.ca [216.40.124.67]) (authenticated bits=0) by orthanc.ca (8.14.2/8.14.2) with ESMTP id m6V4JWQa070544 for <[e-mail]>; Wed, 30 Jul 2008 21:19:33 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Lyndon Nerenberg <[e-mail]>
To: [e-mail]
In-Reply-To: <g6k7cq$3iv$[e-mail]>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date: Wed, 30 Jul 2008 21:19:20 -0700
References: <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]>
X-Mailer: Apple Mail (2.926)
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>

> 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=



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 m6UI28xO014747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 11:02:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UI286L014746; Wed, 30 Jul 2008 11:02:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UI21Ep014735 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 11:02:08 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6UI21PB004760 for <[e-mail]>; Wed, 30 Jul 2008 11:02:01 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 30 Jul 2008 11:02:01 -0700 (PDT)
Received: from nifty-silver.meeting.ietf.org ([130.129.23.144]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 30 Jul 2008 11:01:47 -0700 (PDT)
Date: Wed, 30 Jul 2008 19:01:42 +0100
From: Chris Newman <[e-mail]>
Subject: Re: Scram as a gs2 mechanism ABNF
In-reply-to: <[e-mail]>
To: Sam Hartman <[e-mail]>, [e-mail]
Message-id: <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
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 July 29, 2008 8:12:40 -0400 Sam Hartman <[e-mail]> 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
>
>






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 m6UHEtha010353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 10:14:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UHEten010352; Wed, 30 Jul 2008 10:14:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UHEsAl010345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 10:14:55 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6UHEsq8012244 for <[e-mail]>; Wed, 30 Jul 2008 10:14:54 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 30 Jul 2008 10:14:54 -0700 (PDT)
Received: from nifty-silver.meeting.ietf.org ([130.129.23.144]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 30 Jul 2008 10:14:51 -0700 (PDT)
Date: Wed, 30 Jul 2008 18:14:47 +0100
From: Chris Newman <[e-mail]>
Subject: Sun implementation report answers
In-reply-to: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
To: [e-mail]
Message-id: <9D396836FF4A2A781BD30A32@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
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>

Putting on my implementer hat, here are my answers:

> RFC 4422 Implementation Questionnaire
> ===============================================
> 0. Contact and Description
> Organization Name:
   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
>      other implementation (such as SASL)?  If so, explain.

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
> implementation?

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




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 m6UBr4Xn079868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 04:53:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UBr4Tr079867; Wed, 30 Jul 2008 04:53:04 -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 m6UBr0RK079858 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 04:53:02 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KOAEl-00020o-Gv for [e-mail]; Wed, 30 Jul 2008 11:52:59 +0000
Received: from 212.82.251.28 ([212.82.251.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 30 Jul 2008 11:52:59 +0000
Received: from nobody by 212.82.251.28 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 30 Jul 2008 11:52:59 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
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
Message-ID: <g6pkmh$moo$[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.28
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1914
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>

> 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



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 m6U88cIj059642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 01:08:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U88cKh059641; Wed, 30 Jul 2008 01:08:38 -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 m6U88blN059635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 01:08:38 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.36] ([130.129.21.36]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m6U883x5067062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 08:08:06 GMT (envelope-from [e-mail])
Cc: Peter Saint-Andre <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Kurt Zeilenga <[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: SASL to draft questionnaire
Date: Wed, 30 Jul 2008 09:08:03 +0100
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F> <[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 Jul 30, 2008, at 12:11 AM, Kurt Zeilenga wrote:

>
>
> On Jul 29, 2008, at 7:22 PM, Peter Saint-Andre wrote:
>
>> Chris Newman wrote:
>>
>>> 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.
>
> 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.

s/as SASL/as a SASL library/

> This would help in evaluating whether we have two independent  
> implementations of each feature.
>
> 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 m6U7LJGg055169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 00:21:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U7LI3V055168; Wed, 30 Jul 2008 00:21:18 -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 m6U7LFPU055161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 00:21:16 -0700 (MST) (envelope-from [e-mail])
Received: from [10.0.42.42] ([130.129.65.45]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m6U7Ka3j065193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 07:20:39 GMT (envelope-from [e-mail])
Cc: Chris Newman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Peter Saint-Andre <[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: SASL to draft questionnaire
Date: Wed, 30 Jul 2008 00:11:19 +0100
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F> <[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 Jul 29, 2008, at 7:22 PM, Peter Saint-Andre wrote:

> Chris Newman wrote:
>
>> 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.

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



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 m6TIN34f001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 11:23:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TIN3Jw001695; Tue, 29 Jul 2008 11:23:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TIN16p001687 for <[e-mail]>; Tue, 29 Jul 2008 11:23:02 -0700 (MST) (envelope-from [e-mail])
Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 50D344039B; Tue, 29 Jul 2008 12:20:11 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2008 12:22:52 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.16) Gecko/20080707 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Re: SASL to draft questionnaire
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
In-Reply-To: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000003010901060101050709"
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>

This is a cryptographically signed message in MIME format.

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

Chris Newman wrote:

> 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


--------------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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MjkxODIyNTJaMCMGCSqG
SIb3DQEJBDEWBBRzE7RmoW8jsV9MGjp5TpQ6Nfa0ljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCRftMTGBlog4CRZSfsIX+bDQm/aXAeKhvn+G4uKNlJ3gFxmPMFz7m0yIuX8TF0vgy/v9B/
G3B3HKm2qlRoMD0QcGsdpiTw45shyUY0tc9QqSTeHw8RRg6hDt9GkJyulA5RNIn4SbfaWL8i
5n8ZFs2fXPoMGWWhBUj5D+jcEBePl1QZfkBGpHDXj6SEkN25QGXzDNdHFIanNDwliq15MvrP
6541E93L21NigcSOx7vdotCkgfcc2w5PmqQjEaIblcZnaAh4QcYHYrg9RucqBue5RQQuiqQE
mTwJhRJ/EvfexOa9X55UuFpMbxwbwtzqcTx566OR7NcYPtDvGDdWQm0yAAAAAAAA
--------------ms000003010901060101050709--



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 m6TGGBBr092045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 09:16:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TGGBtC092044; Tue, 29 Jul 2008 09:16:11 -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 m6TGGBUs092038 for <[e-mail]>; Tue, 29 Jul 2008 09:16:11 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 872C13A6BA5; Tue, 29 Jul 2008 09:15:03 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-digest-to-historic-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 29 Jul 2008 09:15:03 -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           : 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
[e-mail].

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:     <[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 m6TGEf3V091924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 09:14:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TGEfB8091923; Tue, 29 Jul 2008 09:14:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TGEe2f091916 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 09:14:41 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6TGEa5f010412 for <[e-mail]>; Tue, 29 Jul 2008 09:14:40 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 29 Jul 2008 09:14:36 -0700 (PDT)
Received: from nifty-silver.meeting.ietf.org ([130.129.23.144]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 29 Jul 2008 09:14:35 -0700 (PDT)
Date: Tue, 29 Jul 2008 17:14:32 +0100
From: Chris Newman <[e-mail]>
Subject: SASL to draft questionnaire
To: [e-mail]
Message-id: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
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>

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:




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 m6TEX3h5082283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 07:33:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TEX3T4082282; Tue, 29 Jul 2008 07:33:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TEX2W3082272 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 07:33:03 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6TEX2YP025326 for <[e-mail]>; Tue, 29 Jul 2008 07:33:02 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 29 Jul 2008 07:33:02 -0700 (PDT)
Received: from nifty-silver.meeting.ietf.org ([130.129.23.144]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 29 Jul 2008 07:33:01 -0700 (PDT)
Date: Tue, 29 Jul 2008 15:32:56 +0100
From: Chris Newman <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
In-reply-to: <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Message-id: <40D4C41EE804D399BB07A397@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]>
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>

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 <[e-mail]> wrote:

> Chris Newman <[e-mail]> 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?
>






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 m6TCja4N071448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 05:45:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TCjaEw071447; Tue, 29 Jul 2008 05:45:36 -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 ([130.129.18.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TCjYOG071438 for <[e-mail]>; Tue, 29 Jul 2008 05:45:35 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 26D3847CC; Tue, 29 Jul 2008 08:45:34 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
References: <[e-mail]>
Date: Tue, 29 Jul 2008 08:45:34 -0400
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Tue, 29 Jul 2008 08:12:40 -0400")
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>

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



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 m6TCCgT4068258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 05:12:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TCCgsm068257; Tue, 29 Jul 2008 05:12:42 -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 ([130.129.18.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TCCewA068248 for <[e-mail]>; Tue, 29 Jul 2008 05:12:41 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1ED0147CC; Tue, 29 Jul 2008 08:12:40 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: Scram as a gs2 mechanism ABNF
Date: Tue, 29 Jul 2008 08:12:40 -0400
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>

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



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 m6T8qd5a048564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 01:52:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6T8qdIf048563; Tue, 29 Jul 2008 01:52:39 -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 m6T8qcJw048554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 01:52:39 -0700 (MST) (envelope-from [e-mail])
Received: from nomad.meeting.ietf.org ([130.129.21.36]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m6T8q3sX052197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jul 2008 08:52:05 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: <g6lqo4$l11$[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: Updating SASLprep
Date: Tue, 29 Jul 2008 09:52:02 +0100
References: <[e-mail]> <g6lqo4$l11$[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 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



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 m6T8c6ki046670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 01:38:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6T8c6ZK046669; Tue, 29 Jul 2008 01:38:06 -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 m6T8bsxY046651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 01:38:05 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.36] ([130.129.21.36]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m6T8bKX4049326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 08:37:23 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: Channel binding for HTTP Digest Authentication
Date: Tue, 29 Jul 2008 09:37:15 +0100
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>

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



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 m6T1F9ta014900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 18:15:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6T1F9C7014899; Mon, 28 Jul 2008 18:15:09 -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 m6T1F6KH014891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 18:15:08 -0700 (MST) (envelope-from [e-mail])
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1KNdnq-0001Fw-P9 for [e-mail]; Tue, 29 Jul 2008 01:15:02 +0000
Received: from 212.82.251.180 ([212.82.251.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 29 Jul 2008 01:15:02 +0000
Received: from nobody by 212.82.251.180 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 29 Jul 2008 01:15:02 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Updating SASLprep
Date:  Tue, 29 Jul 2008 03:12:46 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 10
Message-ID: <g6lqo4$l11$[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.180
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
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:

> 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



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 m6SMteDn006783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 15:55:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SMteWg006782; Mon, 28 Jul 2008 15:55:40 -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 m6SMtWnB006771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 15:55:39 -0700 (MST) (envelope-from [e-mail])
Received: from [10.0.42.42] ([130.129.65.65]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m6SMsurk013799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 22:55:01 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: Updating SASLprep
Date: Mon, 28 Jul 2008 23:54:34 +0100
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 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



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 m6SAZRIc043716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 03:35:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SAZRCZ043715; Mon, 28 Jul 2008 03:35:27 -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 m6SAZJm2043697 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 03:35:25 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KNQ4R-0003bA-Gc for [e-mail]; Mon, 28 Jul 2008 10:35:15 +0000
Received: from 212.82.251.180 ([212.82.251.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 28 Jul 2008 10:35:15 +0000
Received: from nobody by 212.82.251.180 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 28 Jul 2008 10:35:15 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
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
Message-ID: <g6k7cq$3iv$[e-mail]>
References:  <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[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.180
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
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>

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






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 m6S9TgTj036436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 02:29:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6S9Tgb1036435; Mon, 28 Jul 2008 02:29:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6S9TdOw036427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 02:29:41 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m6S9TbCw029735; Mon, 28 Jul 2008 05:29:37 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m6S9TauX026476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 05:29:37 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m6S9TaFo011582; Mon, 28 Jul 2008 05:29:36 -0400 (EDT)
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
References: <[e-mail]> <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F>
From: Tom Yu <[e-mail]>
Date: Mon, 28 Jul 2008 05:29:36 -0400
In-Reply-To: <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> (Chris Newman's message of "Fri, 18 Jul 2008 18:20:31 -0700")
Message-ID: <[e-mail]>
Lines: 6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
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>

Chris Newman <[e-mail]> 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?



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 m6J1KZdr016736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 18:20:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6J1KZa6016735; Fri, 18 Jul 2008 18:20:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6J1KY6N016729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 18 Jul 2008 18:20:34 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6J1KXCa004588 for <[e-mail]>; Fri, 18 Jul 2008 18:20:33 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 18 Jul 2008 18:20:33 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 18 Jul 2008 18:20:33 -0700 (PDT)
Date: Fri, 18 Jul 2008 18:20:31 -0700
From: Chris Newman <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
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>

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

		- Chris

--On July 14, 2008 11:45:02 -0700 [e-mail] 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.
>






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 m6EIjWkr035019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:45:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIjWMD035018; Mon, 14 Jul 2008 11:45:32 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIjVkM035009 for <[e-mail]>; Mon, 14 Jul 2008 11:45:32 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 5761D28C158; Mon, 14 Jul 2008 11:45:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-10.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 14 Jul 2008 11:45:02 -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		: 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:	<[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 m6DHjSg2022350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jul 2008 10:45:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6DHjS4E022349; Sun, 13 Jul 2008 10:45:28 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6DHjRmC022343 for <[e-mail]>; Sun, 13 Jul 2008 10:45:27 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 6D54A3A69B6; Sun, 13 Jul 2008 10:45:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-10.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun, 13 Jul 2008 10:45:02 -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           : 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:     <[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 m6BMYcIs064823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 15:34:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BMYcom064822; Fri, 11 Jul 2008 15:34:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BMYaVY064814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Jul 2008 15:34:37 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m6BMYYsO021484 for <[e-mail]>; Fri, 11 Jul 2008 18:34:34 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m6BMYXvW018367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 11 Jul 2008 18:34:34 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m6BMYXka000959; Fri, 11 Jul 2008 18:34:33 -0400 (EDT)
To: [e-mail]
Subject: SASL agenda items for IETF72
From: Tom Yu <[e-mail]>
Date: Fri, 11 Jul 2008 18:34:33 -0400
Message-ID: <[e-mail]>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
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>

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?



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 m6AGACC6003754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 09:10:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6AGACrY003753; Thu, 10 Jul 2008 09:10:12 -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 m6AGA9tt003738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 10 Jul 2008 09:10:11 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KGyif-00051a-14 for [e-mail]; Thu, 10 Jul 2008 16:10:09 +0000
Received: from hmbg-d9b88e1e.pool.mediaways.net ([217.184.142.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 10 Jul 2008 16:10:09 +0000
Received: from nobody by hmbg-d9b88e1e.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 10 Jul 2008 16:10:09 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
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
Message-ID: <g55c8o$2as$[e-mail]>
References:  <[e-mail]> <p0624081ec49814b228f9@[10.20.30.162]> <[e-mail]> <p06240813c499318d3eac@[10.20.30.162]> <[e-mail]> <p06240826c49971f15611@[10.20.30.162]> <[e-mail]> <p06240805c49bd2c0834d@[10.20.30.162]>
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: hmbg-d9b88e1e.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
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>

JFTR, Paul Hoffman <[e-mail]> 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.




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 m67A2HVm098594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 03:02:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67A2H3f098593; Mon, 7 Jul 2008 03:02:17 -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 m67A2E83098583 for <[e-mail]>; Mon, 7 Jul 2008 03:02:14 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 7 Jul 2008 11:02:13 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 06 Jul 2008 15:29:22 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[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>

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.
>  
>