Subject: Proposed SASL WG charter description

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 4 Sep 2008 08:36:04 -0700

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

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

A revised milestone proposal will be posted separately.

-- Kurt

Simple Authentication and Security Layer (sasl)

Description of Working Group:

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

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

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

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

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

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

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

- new features,

- SASL Mechanisms not specifically mentioned above, and

- SASL "profiles".

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 7 Sep 2008 06:35:15 +0200

Kurt Zeilenga wrote:

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

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

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

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

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

 Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Sep 2008 13:39:56 +0100

>Does that allow for "abandon SASLprep in favour of net-UTF8" ?
A very good question indeed.

>to minimize the SASL-specific restrictions x vs. y, and to get
I am not sure NFC is better than KFKC for usernames/passwords.
But the idea of using NET-Unicode as the base seems interesting to me.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Sep 2008 13:26:51 +0200

Alexey Melnikov <[email-masked]> writes:

>>> The outcome of this work will be a Standards Track RFC replacing
>>> RFC 4013.
>>>    
>>>

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

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

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

> But the idea of using NET-Unicode as the base seems interesting to me.

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

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Sep 2008 06:57:54 -0700

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

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

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Sep 2008 07:13:51 -0700

> compatibility with it has to be an absolute mandate in the SASL WG

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

> not be something to strive for anyway.

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

> NFKC removes more entropy from passwords than NFC.

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

> Even though NFKC was

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Sep 2008 16:56:08 +0200

> == SASLprep(x) for all x (where x is well formed Unicode 3.2 text).

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

> PR-29 issues were limited to characters which do not occur in practice.

That would work.

> for user names and passwords".

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

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Sep 2008 08:23:52 -0700

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

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

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

-- Kurt

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 8 Sep 2008 22:14:33 +0200

Kurt Zeilenga wrote:

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

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

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

 Frank