Subject: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item

From: Tom Yu <[email-masked]>
Date: Wed, 25 May 2005 20:04:22 -0400

Kurt has offered draft-zeilenga-sasl-rfc2222bis as a replacement for
draft-ietf-sasl-rfc2222bis.  Kurt would like to re-submit the draft as
a WG draft.  I have heard a small number of comments, and no
objections to the proposed replacement.  Keeping in mind that we have
a milestone of submitting rfc2222bis by the end of May, I would like
to move forward on this issue.

If you support the working group adopting
draft-zeilenga-sasl-rfc2222bis as a replacement to
draft-ietf-sasl-rfc2222bis, please reply indicating this support.  If
you have other comments, please send them as well.

Otherwise, hearing no objections by the end of Friday, I will declare
that the consensus of the WG is to adopt Kurt's draft as a replacement
for the existing WG draft for rfc2222bis.

---Tom

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 May 2005 16:00:17 +0200

Tom Yu <[email-masked]> writes:

> draft-ietf-sasl-rfc2222bis, please reply indicating this support.

I read these two documents side by side today, and I didn't find any
major problems with Kurt's rewrite.  Actually, I found Kurt's version
more precise and generally easier to read.  Good work!

> If you have other comments, please send them as well.

I note that there is almost no SASLprep discussion in the new
document.

SASLprep is only mentioned once, and only in the context of
mechanisms:

  For simple user names and/or passwords in authentication credentials,
  SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
  algorithm), SHOULD be specified as the preparation algorithm.

Removing SASLprep discussions from the core document may be a good
thing.  Doing so will force the SASLprep discussions down into the
mechanism specification (for authid) and the protocol profile
specification (for authzid), where it may be easier to specify the
details.

On the other hand, removing SASLprep guidance from the core document
may lead to poorer SASLprep discussions in mechanism/profile
documents.  That is because the SASLprep discussion would have to be
duplicated and re-thought for each mechanism/profile.  At worst,
without proper co-ordination, some decisions made in one mechanism (or
profile) could become in conflict with decisions made in some profile
(or mechanism).

Generally, it seems that with this new document, authors of
mechanism/profile documents will have little guidance on how to use
SASLprep correctly within the SASL framework.

Finally, if the intention was to remove SASLprep discussions from the
core document, I think SASLprep could be removed completely.  I.e.,
rewrite the SHOULD paragraph, turning it into a suggestion, and make
SASLprep an informational reference.  That would make it possible to
make mechanisms use a future SASLprep2 without having to revise the
core document.

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 May 2005 13:59:10 -0700

Simon, thank you for your review and support.  A few comments
in regards to your SASLprep note...  -Kurt

>  algorithm), SHOULD be specified as the preparation algorithm.

Actually, it was also mentioned (indirectly through "simple
user names") in bullet 4 of section 4 (protocol requirements).
I didn't see a particular need to recommend use of SASLprep here.
But, if desirable, I wouldn't have any objection to adding to
   Protocols whose authorization identities are simple user names
   SHOULD use of SASLprep [RFC4013] (a profile of the StringPrep
   [RFC3454] preparation algorithm) as their preparation algorithm.

I would hesitate before saying more (see below).

>SASLprep correctly within the SASL framework.

It can be argued that "design guidance" and "implementation guidance"
(both of which tend to informational in nature) are better given
separately from technical specifications and applicability statements.
When you mix guidance and requirements, designers and implementors
are bound to confuse guidance as requirements and requirements as
guidance.

>core document, I think SASLprep could be removed completely.

Reducing the SASLprep discussions to requirements was intentional.

>I.e.,

I would rather removal ALL reference to SASLprep.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 May 2005 23:38:19 +0200

> are bound to confuse guidance as requirements and requirements as

I agree.  I read the current "SHOULD use SASLprep" text as design
guidance.  The pre-conditions for when the SHOULD apply is
sufficiently fuzzy to make the statement practically meaningless.  It
appear to be present only so that SASLprep is mentioned somewhere.

> I would rather removal ALL reference to SASLprep.

For the core document, I tend to agree.  It seems difficult to say
anything informative, that is generally valid, on how SASLprep should
be used.

If the WG want to force SASL mechanisms/profiles to use SASLprep in
some specific way, I believe that statement could be written down in a
separate document.  Similar to how support of Unicode is a strong
requirement when transporting human text in modern IETF protocols.
I'm not sure it is a good idea to write such a document, though,
writing it will be a delicate problem.  Without more practical
experience with SASLprep in SASL mechanisms/profiles, I suspect the
document might just end up being incorrect, too.

Regards,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 May 2005 18:38:41 -0400

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> It can be argued that "design guidance" and "implementation
    Kurt> guidance" (both of which tend to informational in nature)
    Kurt> are better given separately from technical specifications
    Kurt> and applicability statements.  When you mix guidance and
    Kurt> requirements, designers and implementors are bound to
    Kurt> confuse guidance as requirements and requirements as
    Kurt> guidance.

Speaking as an individual, I prefer IETF standards with significant
design guidance.  I think Kurt is more interested in separation of
material than I am but I don't actually object to separation--it's
just not something I care much about either way.

---

From: Tom Yu <[email-masked]>
Date: Tue, 31 May 2005 20:52:12 -0400

Hearing no objections, I declare that the consensus of the working
group is that Kurt's draft draft-zeilenga-sasl-rfc2222bis is a
suitable replacement for draft-ietf-sasl-rfc2222bis.

Kurt, please proceed to submit your draft as a replacement for
draft-ietf-sasl-rfc2222bis.

---Tom

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 May 2005 16:00:17 +0200

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 May 2005 13:59:10 -0700

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 May 2005 23:38:19 +0200

Regards,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 May 2005 18:38:41 -0400

---

From: Tom Yu <[email-masked]>
Date: Tue, 31 May 2005 20:52:12 -0400

---Tom

To: [email-masked]
Subject: Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
From: Tom Yu <[email-masked]>
Date: Tue, 31 May 2005 20:52:12 -0400
Lines: 8
Sender: [email-masked]

---Tom

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
From: Sam Hartman <[email-masked]>
Date: Tue, 31 May 2005 18:38:41 -0400
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 27 May 2005 23:38:19 +0200
Sender: [email-masked]

Regards,
Simon

Date: Fri, 27 May 2005 13:59:10 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
Cc: [email-masked]
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 26 May 2005 16:00:17 +0200
Sender: [email-masked]

Regards,
Simon

To: [email-masked]
Subject: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item
From: Tom Yu <[email-masked]>
Date: Wed, 25 May 2005 20:04:22 -0400
Lines: 17
Sender: [email-masked]

---Tom

Date: Wed, 25 May 2005 14:03:42 -0700
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL profile for NNTP
Cc: Alexey Melnikov <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

At 01:35 PM 5/25/2005, Ken Murchison wrote:
>Yes.  Given the fact that DIGEST-MD5 is currently in a state of flux, do you think that we should make CRAM-MD5 the mandatory to implement SASL mech? 

Personally, I do not think CRAM-MD5 provides adequate security
for NNTP, as NNTP session would be subject to hijacking
due to CRAM-MD5 failure to provide any data security layer.

> Alternatively, we could simply mandate TLS+PLAIN. 

That might be the best choice in balancing both security
and interoperability.

Kurt 

Date: Wed, 25 May 2005 16:35:02 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: SASL profile for NNTP
Sender: [email-masked]

Alexey Melnikov wrote:

> At 12:09 PM 5/23/2005, Ken Murchison wrote:
> 
>> I am a co-author of the I-D specifying the SASL profile for NNTP, 
>> which I have kept up to date with the current protocol profile 
>> guidelines specified in RFC 2222bis.  I was asked by the NNTPEXT Chair 
>> to get some feedback on the importance of two of the normative 
>> references in that draft.  I am currently referencing RFC 2222bis and 
>> RFC 2831bis (as a mandatory to implement mechanism), but neither of 
>> these is currently in last call, and the chair doesn't want to block 
>> the NNTP SASL profile (and the NNTP update draft as a result), if we 
>> don't have to.
>>
> If NNTP depends on RFC 2831, does it recommend to use confidentiality 
> protection?
> DES/3DES in RFC 2831 is broken. NNTP can't recommend AES, as there is no 
> RFC describing it. RC4 is the only thing left. Now, saying in an NNTP 
> document that implementations should implement RFC 2831 but shouldn't 
> use a particular cipher would be awkward at best.

Yes.  Given the fact that DIGEST-MD5 is currently in a state of flux, do 
you think that we should make CRAM-MD5 the mandatory to implement SASL 
mech?  Alternatively, we could simply mandate TLS+PLAIN.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 24 May 2005 22:16:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: SASL profile for NNTP
Sender: [email-masked]

At 12:09 PM 5/23/2005, Ken Murchison wrote:

>I am a co-author of the I-D specifying the SASL profile for NNTP, which I have kept up to date with the current protocol profile guidelines specified in RFC 2222bis.  I was asked by the NNTPEXT Chair to get some feedback on the importance of two of the normative references in that draft.  I am currently referencing RFC 2222bis and RFC 2831bis (as a mandatory to implement mechanism), but neither of these is currently in last call, and the chair doesn't want to block the NNTP SASL profile (and the NNTP update draft as a result), if we don't have to.
>
If NNTP depends on RFC 2831, does it recommend to use confidentiality 
protection?
DES/3DES in RFC 2831 is broken. NNTP can't recommend AES, as there is no 
RFC describing it. RC4 is the only thing left. Now, saying in an NNTP 
document that implementations should implement RFC 2831 but shouldn't 
use a particular cipher would be awkward at best.

To: SASL mailing list <[email-masked]>
Subject: Re: SASL profile for NNTP
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 24 May 2005 13:37:36 -0700
Sender: [email-masked]

Kurt D Zeilenga <[email-masked]> writes:

> Well, one question worth asking is whether NNTP'ers want to revise again
> to achieve Draft Standard status.

This will almost certainly be necessary regardless, since the current
internationalization mess in Usenet is probably going to need to be
clarified in other documents and then referenced in NNTP before Draft
Standard status.

> I note that SASLprep is also quite relevant to RFC 2831bis.

We do already reference SASLprep and require it, independent of what the
referenced SASL document requires.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 24 May 2005 12:56:16 -0700
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL profile for NNTP
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

At 12:09 PM 5/23/2005, Ken Murchison wrote:
>I am a co-author of the I-D specifying the SASL profile for NNTP, which I have kept up to date with the current protocol profile guidelines specified in RFC 2222bis.  I was asked by the NNTPEXT Chair to get some feedback on the importance of two of the normative references in that draft.  I am currently referencing RFC 2222bis and RFC 2831bis (as a mandatory to implement mechanism), but neither of these is currently in last call, and the chair doesn't want to block the NNTP SASL profile (and the NNTP update draft as a result), if we don't have to.

Well, one question worth asking is whether NNTP'ers want to
revise again to achieve Draft Standard status.  If NNTP docs
references 2222 & 2831, then some subsequent revision
becomes necessary for these NNTP docs to reach Draft
Standard status.  And, those docs would also have to deal
with any differences between 2222 & 2222bis and between
2831 & 2831bis in that revision that might ripple into
NNTP and its implementations.

>AFAICT, the two major changes in these docs which might be worth blocking on are the discussion of SASLprep in RFC 2222bis and the deprecation of 3DES in RFC 2831bis.

I note that SASLprep is also quite relevant to RFC 2831bis.

>So my question to the group is, do people feel that there are technical reasons why we *should* block on these updated SASL docs, or can we just use the existing RFCs as normative references?

Yes.  Technical reasons include internationalization and security
considerations.

>As a member of both WG, I'd like to wait for these updates (provided they get to Last Call soon), but I'll go with whatever the consensus is here.
>
>Thanks,
>Ken
>-- 
>Kenneth Murchison     Oceana Matrix Ltd.
>Software Engineer     21 Princeton Place
>716-662-8973 x26      Orchard Park, NY 14127
>--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 23 May 2005 15:09:40 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: SASL profile for NNTP
Sender: [email-masked]

I am a co-author of the I-D specifying the SASL profile for NNTP, which 
I have kept up to date with the current protocol profile guidelines 
specified in RFC 2222bis.  I was asked by the NNTPEXT Chair to get some 
feedback on the importance of two of the normative references in that 
draft.  I am currently referencing RFC 2222bis and RFC 2831bis (as a 
mandatory to implement mechanism), but neither of these is currently in 
last call, and the chair doesn't want to block the NNTP SASL profile 
(and the NNTP update draft as a result), if we don't have to.

AFAICT, the two major changes in these docs which might be worth 
blocking on are the discussion of SASLprep in RFC 2222bis and the 
deprecation of 3DES in RFC 2831bis.

So my question to the group is, do people feel that there are technical 
reasons why we *should* block on these updated SASL docs, or can we just 
use the existing RFCs as normative references?

As a member of both WG, I'd like to wait for these updates (provided 
they get to Last Call soon), but I'll go with whatever the consensus is 
here.

Thanks,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 23 May 2005 13:00:23 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-zeilenga-sasl-rfc2222bis-00.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:

> Please consider the following draft as a replacement for
> draft-ietf-sasl-rfc2222bis-xx.txt.

I don't have any major problems with the format or content of this 
rewrite.  I didn't spot any technical errors after a quick first read, 
but there are a number of spelling/grammatical nits which I can 
enumerate if we decide to move forward with this doc.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 17 May 2005 17:30:07 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Fwd: I-D ACTION:draft-zeilenga-sasl-rfc2222bis-00.txt
Sender: [email-masked]

Please consider the following draft as a replacement for
draft-ietf-sasl-rfc2222bis-xx.txt.

It became apparent to me some time ago that resolution of
the general readability issues (organization, terminology,
etc.) could only be resolved by significantly rewriting the
WG I-D, this I-D is one possible rewrite of the WG I-D.  And
that once rewritten, it would be easier to resolve any
lingering technical issues.  This I-D is a major rewrite
which attempts to resolve the general readability issues
as well as lingering technical issues.
 
As it is a major rewrite, it is best considered in whole.
Hence, with Tom's approval, we have individually submitted
this I-D and now request WG consideration.

As it is a major rewrite, it is difficult to enumerate
all of the differences between this I-D and the WG's I-D.
(The differences between this I-D and RFC 2222 are
summarized in the I-D.) I do note that security consideration
section undergone significant changes.  A lot of issues in
RFC2222 and/or WG I-D have been dealt with as security
considerations.  That is, this I-D is generally more
descriptive of security issues and possible approaches for
adding them than prescriptive to what approach protocols,
mechanisms, and/or implementations should use to address
security issues.  It is also noted that non-normative
"relationship to transport security" appendix has been
dropped.  This topic in at least one general Internet
security RFC.

I defer all chair action in regards the WG's RFC2222bis
deliverable, including this I-D, to Tom.

Kurt, as an individual contributor

>To: [email-masked]
>From: [email-masked]
>Date: Tue, 17 May 2005 15:45:30 -0400
>Subject: I-D ACTION:draft-zeilenga-sasl-rfc2222bis-00.txt
>Reply-To: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : Simple Authentication and Security Layer (SASL)
>        Author(s)       : A. Melnikov, K. Zeilenga
>        Filename        : draft-zeilenga-sasl-rfc2222bis-00.txt
>        Pages           : 29
>        Date            : 2005-5-17
>        
>The Simple Authentication and Security Layer (SASL) is a framework for
>  providing authentication and data security services in
>  connection-oriented protocols via replaceable mechanisms.  It provides
>  a structured interface between protocols and mechanisms.  The
>  resulting framework allows new protocols to reuse existing mechanisms
>  and allows old protocols to make use of new mechanisms.  The framework
>  also provides a protocol for securing subsequent protocol exchanges
>  within a data security layer.
>
>  This document describes how a SASL mechanism is structured, describes
>  how protocols include support for SASL, and defines the protocol for
>  carrying a data security layer over a connection.  Additionally, this
>  document defines one SASL mechanism, the EXTERNAL mechanism.
>
>  This document obsoletes RFC 2222.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zeilenga-sasl-rfc2222bis-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-zeilenga-sasl-rfc2222bis-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        [email-masked].
>In the body type:
>        "FILE /internet-drafts/draft-zeilenga-sasl-rfc2222bis-00.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>                
>                
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-zeilenga-sasl-rfc2222bis-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-zeilenga-sasl-rfc2222bis-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce