Subject: WG Action: RECHARTER: Simple Authentication and Security Layer (sasl)

From: IESG Secretary <[email-masked]>
Date: Tue, 28 Oct 2008 13:58:32 -0700 (PDT)

The Simple Authentication and Security Layer (sasl) working group in the
Security Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Simple Authentication and Security Layer (sasl)
================================================

Last Revision 10/3/2008

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/sasl

Chair(s):
Kurt Zeilenga [[email-masked]]
Tom Yu [[email-masked]]

Security Area Director(s):
Tim Polk [[email-masked]]
Pasi Eronen [[email-masked]] 

Security Area Advisor:
Pasi Eronen [[email-masked]]

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe
Archive: http://www.imc.org/ietf-sasl/mail-archive/

Description of Working Group:

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

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

The group has determined that DIGEST-MD5 [RFC2831] is not suitable for
progression on the Standards Track due to interoperability,
internationalization, and security concerns. The group will deliver a
technical specification for a suitable password-based challenge/
response replacement mechanism for Standard Track consideration.

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

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

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

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

- new features,

- SASL Mechanisms not specifically mentioned above, and

- SASL "profiles".

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

Milestones:

Done Initial I-D for RFC4422bis
Done Initial I-D for DIGEST-MD5 to Historic
Done WGLC I-D for DIGEST-MD5 to Historic
Done Initial DIGEST-MD5 replacement I-D
Done Initial GS2 I-D
Nov 08 initial RFC4422bis implementation report
Nov 08 Reach consensus on CRAM-MD5 successor approach (and update
milestones accordingly)
Dec 08 WGLC RFC4422bis and implementation report I-D
Jan 09 WGLC DIGEST-MD5 replacement I-D
Jan 09 WGLC GS2 I-D

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Oct 2008 15:17:39 -0600

IESG Secretary wrote:

> draft-newman-auth-scam 

I hope that's not a Freudian slip. :)

/psa

Date: Tue, 28 Oct 2008 15:17:39 -0600
From: Peter Saint-Andre <[email-masked]>
To: IESG Secretary <[email-masked]>
CC: IETF Announcement list <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: WG Action: RECHARTER: Simple Authentication and Security Layer (sasl)
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

IESG Secretary wrote:

> draft-newman-auth-scam 

I hope that's not a Freudian slip. :)

/psa

From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Action: RECHARTER: Simple Authentication and Security Layer  (sasl) 
Date: Tue, 28 Oct 2008 13:58:32 -0700 (PDT)
Sender: [email-masked]

Last Revision 10/3/2008

Chair(s):

Security Area Advisor:

Mailing Lists:

- new features,

- SASL "profiles".

Milestones:

Date: Wed, 15 Oct 2008 17:01:29 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL WG status, 10/15
Sender: [email-masked]

On Wed, Oct 15, 2008 at 05:01:52PM +0100, Alexey Melnikov wrote:
> Tom Yu wrote:
> > * channel binding - Nico?
> 
> Nico, can you please review draft-newman-auth-scram-06.txt and tell us 
> if the text on channel binding use is correct/complete?

I think it's correct, but there's a slight disconnect between the BNF
and the text (e.g., "verifier" is defined but never referenced in the
text).

> > * LDAP storage of auth info
> >	text needed for WG consideration - Chris? - 9/30
> > 
> >
> I will post a separate draft on this.
> 
> > * make equivalent to a GS2 mech
> >	text needed for WG consideration - Sam/Nico?- 9/30

IIRC there was one undecided issue left.  Can we please decide it?

Date: Wed, 15 Oct 2008 13:53:09 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL WG status, 10/15
Sender: [email-masked]

On Wed, Oct 15, 2008 at 06:57:40PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Is this I-D supposed to take into account the SCRAM-as-GS2-mech
> >discussion?
> >
> No, the draft predates GS2 discussion.

Hmm.  Perhaps then it would be better to suggest changes to make it
match the discussion.

IIRC we never selected one particular choice w.r.t. what to
base64-encode, ...  However, the natural choice would be to
base64-encode the first binary token and leave the second one unencoded.

Date: Wed, 15 Oct 2008 18:57:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG status, 10/15
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Oct 15, 2008 at 05:01:52PM +0100, Alexey Melnikov wrote:
>  
>
>>>* channel binding - Nico?
>>>      
>>>
>>Nico, can you please review draft-newman-auth-scram-06.txt and tell us 
>>if the text on channel binding use is correct/complete?
>>    
>>
>Will do.
>
>Is this I-D supposed to take into account the SCRAM-as-GS2-mech
>discussion?
>  
>
No, the draft predates GS2 discussion.

Date: Wed, 15 Oct 2008 12:41:04 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL WG status, 10/15
Sender: [email-masked]

On Wed, Oct 15, 2008 at 05:01:52PM +0100, Alexey Melnikov wrote:
> Tom Yu wrote:
> 
> >SCRAM:
> > * PBKDF2 iteration counts - Nico?
> > 
> >
> I took care of this, Nico doesn't need to do anything.

Thanks :)

> > * channel binding - Nico?
> > 
> >
> Nico, can you please review draft-newman-auth-scram-06.txt and tell us 
> if the text on channel binding use is correct/complete?

Will do.

Is this I-D supposed to take into account the SCRAM-as-GS2-mech
discussion?

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Tom Yu <[email-masked]>
Subject: Re: SASL WG status, 10/15
Date: Wed, 15 Oct 2008 09:33:04 -0700
Sender: [email-masked]

On Oct 15, 2008, at 8:49 AM, Tom Yu wrote:

> RFC 4422 implementation reports - need response summary - Kurt
>  - Due 9/30

Now that I have Alexey's response, I'll put this together.   I likely  
will be able to consider any additional responses submitted to the  
list (or directly to me) by week's end...

-- Kurt

Date: Wed, 15 Oct 2008 17:01:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG status, 10/15
Sender: [email-masked]

Tom Yu wrote:

>SCRAM:
>  * PBKDF2 iteration counts - Nico?
>  
>
I took care of this, Nico doesn't need to do anything.

>  * channel binding - Nico?
>  
>
Nico, can you please review draft-newman-auth-scram-06.txt and tell us 
if the text on channel binding use is correct/complete?

>  * LDAP storage of auth info
>	text needed for WG consideration - Chris? - 9/30
>  
>
I will post a separate draft on this.

>  * make equivalent to a GS2 mech
>	text needed for WG consideration - Sam/Nico?- 9/30
>  
>

To: [email-masked]
Subject: SASL WG status, 10/15
From: Tom Yu <[email-masked]>
Date: Wed, 15 Oct 2008 11:49:46 -0400
Lines: 28
Sender: [email-masked]

I think we need new due dates on some of these items.

Nico, Chris, and Sam, has there been any progress on the items with
your names on them?  Can you estimate when they will be done?  Thanks.

WG Charter - milestones needed - DONE (in IETF review)

RFC 4422bis - review needed - WG

RFC 4422 implementation reports - need response summary - Kurt
  - Due 9/30

RFC 4013bis - I-D needed - Kurt - 9/30 - dropped from WG

CRAM-MD5 - resolve pending items from Frank: adding Simon's PLAIN/CRAM
  comparison and tying to saslprep revision; track resolution - WG

digest-to-historic - mostly done, awaiting SCRAM

GS2 - Awaiting SCRAM issue resolution

SCRAM:
  * PBKDF2 iteration counts - Nico?
  * channel binding - Nico?
  * LDAP storage of auth info
	text needed for WG consideration - Chris? - 9/30
  * make equivalent to a GS2 mech
	text needed for WG consideration - Sam/Nico?- 9/30

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: WG Review: Recharter of Simple Authentication and Security Layer  (sasl)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 15 Oct 2008 15:36:28 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> --On Wednesday, October 15, 2008 09:50:20 AM +0200 Simon Josefsson
> <[email-masked]> wrote:
>
>>
>> IESG Secretary <[email-masked]> writes:
>>
>>> Done initial I-D for RFC4422bis
>>> Done initial I-D for DIGEST-MD5 to Historic
>>> Done initial DIGEST-MD5 replacement I-D
>>> Done initial GS2 I-D
>> Given that GS2 is apparently stalled pending decisions on the CRAM-MD5
>> successor, either that decisions needs to be revisited, or these
>> milestones appears backwards.
>
> No, the milestones look right, if a bit agressive.
> They are just not sorted.

Ah.  Then let me alter my comment into a request to sort the entries. ;)

/Simon

Date: Wed, 15 Oct 2008 09:14:54 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: WG Review: Recharter of Simple Authentication and Security Layer  (sasl)
Sender: [email-masked]

--On Wednesday, October 15, 2008 09:50:20 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

>
> IESG Secretary <[email-masked]> writes:
>
>> Done initial I-D for RFC4422bis
>> Done initial I-D for DIGEST-MD5 to Historic
>> Done initial DIGEST-MD5 replacement I-D
>> Done initial GS2 I-D
> Given that GS2 is apparently stalled pending decisions on the CRAM-MD5
> successor, either that decisions needs to be revisited, or these
> milestones appears backwards.

No, the milestones look right, if a bit agressive.
They are just not sorted.

From: Simon Josefsson <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: WG Review: Recharter of Simple Authentication and Security Layer  (sasl)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 15 Oct 2008 09:50:20 +0200
Sender: [email-masked]

IESG Secretary <[email-masked]> writes:

> Done initial I-D for RFC4422bis
> Done initial I-D for DIGEST-MD5 to Historic
> Done initial DIGEST-MD5 replacement I-D
> Done initial GS2 I-D

Given that GS2 is apparently stalled pending decisions on the CRAM-MD5
successor, either that decisions needs to be revisited, or these
milestones appears backwards.

/Simon

From: IESG Secretary <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Review: Recharter of Simple Authentication and Security Layer  (sasl) 
reply-to: [email-masked]
Date: Tue, 14 Oct 2008 17:00:01 -0700 (PDT)
Sender: [email-masked]

A modified charter has been submitted for the Simple Authentication and
Security Layer (sasl) working group in the Security Area of the IETF.  The
IESG has not made any determination as yet.  The modified charter is
provided below for informational purposes only.  Please send your comments
to the IESG mailing list ([email-masked]) by Tuesday, October 21, 2008.

===============================================

Last Revision 10/3/2008

Chair(s):

Security Area Advisor:

Mailing Lists:

- new features,

- SASL "profiles".

Milestones:

Done initial I-D for RFC4422bis
Nov 08 initial RFC4422bis implementation report
Dec 08 WGLC RFC4422bis and implementation report I-D
Done initial I-D for DIGEST-MD5 to Historic
Done WGLC I-D for DIGEST-MD5 to Historic
Done initial DIGEST-MD5 replacement I-D
Jan 09 WGLC DIGEST-MD5 replacement I-D
Done initial GS2 I-D
Jan 09 WGLC GS2 I-D
Nov 08 Reach consensus on CRAM-MD5 successor approach (and update
milestones accordingly)

Date: Sat, 11 Oct 2008 12:46:01 -0600
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: SASL (RFC 4422) to draft questionnaire
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Alexey Melnikov wrote:

> SASL EXTERNAL is implemented in server-to-server XMPP, but it is not
> clear if other XMPP servers are actually using it.

SASL EXTERNAL is implemented in other XMPP servers but AFAIK has not yet
been widely tested. The XMPP Standards Foundation plans to organize some
testing of this feature in the next few months as we work to improve the
security of the XMPP network.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Date: Sat, 11 Oct 2008 11:35:55 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: SASL (RFC 4422) to draft questionnaire
Sender: [email-masked]

Chris Newman wrote:

> 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

Ok, here are my responses (shamelessly copied from Chris' response and 
modified accordingly).

> ---
> RFC 4422 Implementation Questionnaire
> ===============================================
> 0. Contact and Description
> Organization Name:

Isode Limited (implementation A - plugin based generic SASL implementation)
MessagingDirect (implementation B - plugin based generic SASL 
implementation)
Epsylon Technologies (implementation C)

> Implementation (Software or Service) Name:

CMU SASL (implementation A)

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

Yes. I've implemented CRAM-MD5 in Epsylon Technologies' SMTP servers 
(implementation C) and IDK mail client library (both written in Delphi).

I've implemented/maintained client and server DIGEST-MD5 plugin in CMU 
SASL (implementations A) and implementation B [variants of the same 
implementation].
I've updated/maintained GSSAPI client and server side plugin in 
implementation B and maintained implementation B in general.

I've integrated CMU SASL into SMTP, IMAP, POP, ManageSieve and LDAP 
servers (with some help from my Isode co-workers).
I've integrated CMU SASL into an IMAP client.
My co-worker Dave Cridland implemented hardcoded SASL EXTERNAL client 
and server implementation in Isode's XMPP server (for server-to-server 
traffic).

I am also a co-editor of the latest SMTP AUTH document revision and 
reviewed use of SASL in XMPP.

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

Isode is using a fork (around 2004) of CMU SASL with some changes.

> 2. Which SASL mechanisms have you implemented?

The following SASL mechanism included in CMU SASL (implementation A) are 
used by Isode:
PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, NTLM, GSSAPI, EXTERNAL.

Isode also has a standalone SASL EXTERNAL implementation.

Implementation B had:
PLAIN, CRAM-MD5, DIGEST-MD5, GSSAPI

Implementation C:
CRAM-MD5

All implementations included both client side and server side 
implementations of various SASL mechanisms.

> 3. For how long has it been deployed?

CMU SASL is older than 10 years.
MessagingDirect SASL library is also older than 10 years.

For Isode products:
SMTP AUTH is available since early 2003.
LDAP authentication is available since late 2003.
IMAP/POP/ManageSieve authentication is available since around 2005.

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

SASLPrep - this requires quire a bit of effort to build various tables, etc.

SASL security layers *are* implemented in Isode's IMAP/POP server. Some 
mail clients (in particular Apple Mail) can use GSSAPI security layer.
Also note that Isode's IMAP/POP servers implement stacking of SASL 
security layers with TLS, even though it doesn't look like this is used 
by any clients.

The IMAP client doesn't check for a mechanism list modified by an 
attacker, so it doesn't close the connection (a SHOULD in RFC 4422).

Isode's ManageSieve server never emits "additional data with success". 
But Isode's LDAP server uses this feature.

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

See answers to question 4.

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

Isode's IMAP server also implements SASL-IR (SASL initial response 
extension).

We have not implemented SASLprep because we have no customer demand for it.

SASL EXTERNAL is implemented in server-to-server XMPP, but it is not 
clear if other XMPP servers are actually using it.

We continue to advertise the non-standard LOGIN mechanism in SMTP as it 
is used by Outlook Express (and probably Outlook).
This mechanism is also advertised in all other Isode servers, whenever 
PLAIN is also advertised.

SASL proxy authentication feature is used for management of user's mail 
over IMAP.

We had some minor problems with DIGEST-MD5 interoperability. We disable 
DIGEST-MD5 reauthentication due to code thread safety concerns. It is 
not clear if any clients are using this feature. DIGEST-MD5 security 
layer doesn't seem to be interoperable/used.

"Additional data with success" used to cause problems in LDAP: an older 
version of OpenLDAP (client side) was unable to cope with this (fixed in 
a later version), while LDAP Administrator were unable to work without 
this feature. (LDAP Administrator we've tested in Isode was using 
Microsoft LDAP API, so it might have been a problem with the Microsoft 
LDAP library.)

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: draft-brusilovsky-pak-07
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 09 Oct 2008 21:43:12 +0200
Sender: [email-masked]

This draft looks like interesting input for the design of a
password-based SASL mechanism.

Personally, I prefer the simplicity of a HMAC-SHA256 design over PAK
though.

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Password-Authenticated Diffie-Hellman Exchange (PAK)
> 	Author(s)	: I. Faynberg, Z. Zeltsan, A. Brusilovsky
> 	Filename	: draft-brusilovsky-pak-07.txt
> 	Pages		: 8
> 	Date		: 2008-10-9
> 	
> This document proposes to add mutual authentication, based on
>    human-memorizable password, to the basic unauthenticated Diffie-Hellman
>    key exchange. The proposed algorithm is called Password-authenticated
>    Key exchange (PAK). PAK allows two parties to authenticate themselves
>    while performing the Diffie-Hellman exchange.
>    The protocol is secure against all passive and active attacks.
>    In particular, it does not allow either type of attackers to obtain any
>    information that would enable an off-line dictionary attack on the
>    password. The use of Diffie-Hellman exchange ensures Forward Secrecy.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-brusilovsky-pak-07.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.
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Re: Proposed SASL WG charter description
Date: Thu, 2 Oct 2008 16:46:20 -0700
Sender: [email-masked]

Below is the revised SASL WG charter, with milestones.   While it  
likely that the milestones might need some minor adjustment, such  
adjustment can be done post rechartering.   I have sent this proposal  
to our AD to bring to the IESG as soon as possible.

-- Kurt

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

- new features,

- SASL "profiles".

Milestones:

Done    initial I-D for RFC4422bis
Nov 08  initial RFC4422bis implementation report
Dec 08  WGLC RFC4422bis and implementation report I-D
Done	initial I-D for DIGEST-MD5 to Historic
Done	WGLC I-D for DIGEST-MD5 to Historic
Done	initial DIGEST-MD5 replacement I-D
Jan 09  WGLC DIGEST-MD5 replacement I-D
Done	initial GS2 I-D
Jan 09  WGLC GS2 I-D
Nov 08  Reach consensus on CRAM-MD5 successor approach (and update
         milestones accordingly)

Date: Thu, 02 Oct 2008 12:36:01 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: SASL WG status, 10/1
Sender: [email-masked]

Kurt Zeilenga wrote:

> On Oct 1, 2008, at 5:45 PM, Tom Yu wrote:
>
>> RFC 4422 implementation reports - need response summary - Kurt
>>  - Due 9/30
>
> I should have something here in the next few days.

I've started writing my response, but got distracted by work related 
things. I should finish that, but I can't promise I will do this this week.

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Tom Yu <[email-masked]>
Subject: Re: SASL WG status, 10/1
Date: Wed, 1 Oct 2008 18:52:30 -0700
Sender: [email-masked]

On Oct 1, 2008, at 5:45 PM, Tom Yu wrote:

>
> WG Charter - milestones needed - Chairs - 10/3
>
> RFC 4422bis - review needed - WG
>
> RFC 4422 implementation reports - need response summary - Kurt
>  - Due 9/30

I should have something here in the next few days.

>
>
> RFC 4013bis - I-D needed - Kurt - 9/30 (assuming we choose to do this)

Per my recent post, this will not be a WG item.

> CRAM-MD5 - resolve pending items from Frank: adding Simon's PLAIN/CRAM
>  comparison and tying to saslprep revision - WG

This is also pending determination of consensus regarding track and  
approach to be taken.

> digest-to-historic - mostly done, awaiting SCRAM
>
> GS2 - Awaiting SCRAM issue resolution
>
> SCRAM:
>  * PBKDF2 iteration counts - Nico?
>  * channel binding - Nico?
>  * LDAP storage of auth info
> 	text needed for WG consideration - Chris? - 9/30
>  * make equivalent to a GS2 mech
> 	text needed for WG consideration - Sam/Nico?- 9/30
>

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: Proposed SASL WG charter description
Date: Wed, 1 Oct 2008 18:48:38 -0700
Sender: [email-masked]

On Sep 4, 2008, at 8:36 AM, Kurt Zeilenga wrote:

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

It appears that there is insufficient support to take on this work  
item.  Hence, the chairs intend to drop this text from the charter  
proposal.

-- Kurt

To: [email-masked]
Subject: SASL WG status, 10/1
From: Tom Yu <[email-masked]>
Date: Wed, 01 Oct 2008 20:45:15 -0400
Lines: 23
Sender: [email-masked]

WG Charter - milestones needed - Chairs - 10/3

RFC 4422bis - review needed - WG

RFC 4422 implementation reports - need response summary - Kurt
  - Due 9/30

RFC 4013bis - I-D needed - Kurt - 9/30 (assuming we choose to do this)

CRAM-MD5 - resolve pending items from Frank: adding Simon's PLAIN/CRAM
  comparison and tying to saslprep revision - WG

digest-to-historic - mostly done, awaiting SCRAM

GS2 - Awaiting SCRAM issue resolution

SCRAM:
  * PBKDF2 iteration counts - Nico?
  * channel binding - Nico?
  * LDAP storage of auth info
	text needed for WG consideration - Chris? - 9/30
  * make equivalent to a GS2 mech
	text needed for WG consideration - Sam/Nico?- 9/30