Subject: Draft charter of the SASL Working Group

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Mar 2001 13:36:39 -0600

In the next few days, I would like to recommend a
charter for the SASL WG to the ADs.  I propose the
following charter for your review and comment.  In
particular, I ask those who intend to serve as
document editors to check the milestones.

 -- Kurt

Simple Authentication and Security Layer (SASL)

Chair(s):
  Kurt Zeilenga <[email-masked]>
  Alexey Melnikov <[email-masked]>

Security Area AD: TBD
Applications Area AD: <[email-masked]>

Mailing Lists:
  General Discussions: <[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 [RFC2222] 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, though the Internet Standard process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222.

  This group will deliver revised Technical Specifications
  suitable considerations as Draft Standards for the following
  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
  will be based upon RFC 2195, 2222, and 2831.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.

  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.

Goals and Milestones
  Apr 01  Submit revised SASL (+ EXTERNAL) I-D
  May 01  Submit revised SASL CRAM-MD5 I-D
  May 01  Submit revised SASL DIGEST-MD5 I-D
  May 01  Submit revised SASL GSSAPI I-D
  Jul 01  Submit Implementation Report as I-D
  Aug 01  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
          Implementation Report to IESG for consideration as
          a Draft Standard
  Nov 01  Submit revised GSSAPI I-D to IESG for consideration
          as a Proposed Standard
  Dec 01  Revise charter or conclude

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 20 Mar 2001 19:33:29 -0800

"Kurt D. Zeilenga" wrote:
> In

I believe the GSSAPI I-D to be done, it just needs to go through IETF
Last Call.  I think it would be best to do that at the same time as the
base spec.

I have written a first draft of the revised base specification and will
post it as my next message.  I'll submit it as an I-D as soon as the
IETF is over.

I've recently heard reports of our passing the two independent
implementations requirement for security layers.  I've asked Lawrence
Greenfield to start compiling an implementation report.  I don't believe
the implementation report needs to be an I-D.

Assuming there is no great controversy with my revised base
specification, we could get both that and GSSAPI submitted for IETF Last
Call by the time the working group could get formed.  In that case, the
question becomes whether we would want to hold up those two documents
until we can finish CRAM-MD5 and DIGEST-MD5.  I know there are
substantive problems with DIGEST-MD5, namely with the 3DES security
layer.

Do we have a document editor for CRAM-MD5?

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Mar 2001 23:45:49 -0700

> Do we have a document editor for CRAM-MD5?

I'll volunteer for this if Chris doesn't want it.

--lyndon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Mar 2001 00:09:46 -0700

> I'll volunteer for this if Chris doesn't want it.

Chris didn't write it. You should ask John Klensin.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 21 Mar 2001 10:38:38 -0800

John Klensin referred me to a potential CRAM-MD5 document editor.  I'm
following up on this.

---

From: Keith Burdis <[email-masked]>
Date: Thu, 22 Mar 2001 01:10:58 +0200

On Tue 2001-03-20 (13:36), Kurt D. Zeilenga wrote:
>[SNIP]

I understand that it is important that the core SASL specification be
advanced to Draft Standard as soon as possible. However, since all SASL
mechanisms besides EXTERNAL are being removed from the core specification,
what is the motivation for not including additional mechanisms other than
those listed in the Working Group's charter? Working on these mechanisms
will not impede the advancement of the core standard or any of the listed
mechanisms.

  - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 23 Mar 2001 07:12:17 +1100

i still don't understand the principle, if there is one, behind the 
"select" mechanisms included in the proposed charter.  surely a mechanism 
based on SRP (Secure Remote Password) is more useful than EXTERNAL included 
among those "select" mechanisms.

if this charter is approved as it is, where would designers of new 
mechanisms go to get their work discussed, adopted and promoted?

cheers;
rsn

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Mar 2001 13:42:56 -0700

> mechanisms go to get their work discussed, adopted and promoted?

SASL working group is THE RIGHT place to discuss all SASL mechanism. But we
can't include ALL of them in the Charter, because in this case WG will never
conclude. After all milestones are achieved WG will review milestones and will
decide whether the charter should be updated or not.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 22 Mar 2001 13:45:45 -0800

"Raif S. Naffah" wrote:
> "select" mechanisms included in the proposed charter.

The principle is that these are existing mechanisms, with existing
deployment, which need to be advanced along the standards track.

---

From: Keith Burdis <[email-masked]>
Date: Fri, 23 Mar 2001 11:43:24 +0200

Quoting Alexey Melnikov <[email-masked]>:

> \"Raif S. Naffah\" wrote:
> 
> > i still don\'t understand the principle, if there is one, behind the
> > \"select\" mechanisms included in the proposed charter.  surely a mechanism
> > among those \"select\" mechanisms.
> >
> SASL working group is THE RIGHT place to discuss all SASL mechanism. But
> we can\'t include ALL of them in the Charter, because in this case WG will
> never conclude. After all milestones are achieved WG will review milestones
> and will decide whether the charter should be updated or not.

We are not talking about an infinite number of SASL mechanisms here. Since we
are starting a new working group it makes sense to include the EXISTING set of
proposed mechanisms that are likely to have common usage in its charter. Any 
mechanisms proposed after the charter has been set can wait until the charter
is updated.

 - Keith
--
Keith Burdis                        
---

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 23 Mar 2001 04:12:34 -0800 (PST)

> mechanisms go to get their work discussed, adopted and promoted?

It is important to understand that it is quite reasonable and quite common
for documents to become Proposed Standard RFCs without being the product
of a Working Group.  RFC 2222 itself is an example of this.  There are
many protocols now that have extensibility provisions, and new extensions
come along all the time.  Documents specifying them can be created as
individual submissions and move forward without having a Working Group
active in that protocol area at the time.  Typically this involves review
of the document, to the satisfaction of the IESG, by folks who
participated in the original protocol standardization.  Some veterans of
the WG process would say that the individual-submission approach is better
than going through a WG.  This is all covered in section 6.1 of RFC 2026.

That said, I for one think it's reasonable to include WG charter items for
SASL mechanisms that currently have internet-drafts in place (and whose
authors want this to happen).  The perceived urgency of moving things to
Draft Standard shouldn't preclude orderly progression of useful new work.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Mar 2001 09:32:01 -0600

At 11:43 AM 3/23/01 +0200, Keith Burdis wrote:
>Any mechanisms proposed after the charter has been set can
>wait until the charter is updated.

Nothing has to wait!  Just because a work item is not a charter
item does not preclude the work from getting done... nor from
being discussed on the list and at WG sessions.  What a charter
does is give the WG a tool to focus the attention on critical
issues if this work were to become a distraction.

I note we are trying to balance here the concerns of the
Applications folks who really need SASL and EXTERNAL, CRAM,
DIGEST mechanisms progressed to Draft Standard as soon as
possible and the concerns of the Security folks who would
like refine existing mechanisms and introduce new mechanisms.
The current proposal reflects a comprise between these
factions in our community.

To move this discussion forward, I suggest that instead of
discussing generalities, we talk specifics.  That is, please
state which mechanism you believe the IETF should produce
and why.

Thanks, Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 04:52:43 +1100

>decide whether the charter should be updated or not.

why not then include all currently proposed mechanisms then? there are at 
least two other mechanisms: SRP and SM2 that, even if i say so myself, are 
more useful than EXTERNAL.  why aren't these included?

cheers;
rsn

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 04:55:02 +1100

>deployment, which need to be advanced along the standards track.

existing deployment?  SRP and SM2 mechanisms are currently used in 
commercial products being developed!  does that constitute existing deployment?

cheers;
rsn

---

From: Keith Burdis <[email-masked]>
Date: Fri, 23 Mar 2001 20:44:42 +0200

> state which mechanism you believe the IETF should produce

SM2

>From one point of view you can see SM2 as a generalisation of the \"Subsequent 
Authentication\" described in section 2.2 of RFC 2831 (Digest SASL mechanism). 
Session reuse is beneficial when used with any SASL mechanism that provides a 
security layer or spends a relatively long time generating and exchanging 
session parameters. Currently this is applicable to the Digest, SRP and GSS-API 
mechanisms.

SRP

The SRP SASL mechanism is based on the Secure Remote Password protocol 
described in RFC2945. SRP is a password-based, zero-knowledge, authentication 
and key-exchange protocol developed by Thomas Wu. It has good performance, is 
not plaintext-equivalent and maintains perfect forward secrecy. It provides 
authentication (optionally mutual authentication) and the negotiation of a 
session key.

Personally I believe that it is important to have a strong password-based SASL 
mechanism. I don\'t think that the use of long-term public/private keypairs 
should be a requirement for having strong authentication, integrity protection 
and privacy protection. Currently the only password-based mechanism with a 
reasonable level of security is Digest.

Features shared with Digest authentication
 - protection against offline dictionary attacks and chosen plaintext attacks
 - password-based
 - mutual authentication
 - a security layer with protection against reply attacks and providing   
   integrity protection

Additional features compared to Digest authentication:
- forward secrecy
- protection against online dictionary attacks
- stored passwords are not plaintext-equivalent
- a security layer providing confidentiality protection
- security comparative to public-key based technology like TLS

Although GSS-API mechanisms may provide this functionality, they are 
comparitively more complex to implement (especially due to the use of ASN.1) or 
deploy (due to infrastructure requirements, LIPKEY excluded).

I don\'t think that this mechanism has yet undergone a sufficient level of 
community review for it to be taken to the IESG. Therefore I would like for 
this mechanism to be included in the working group\'s charter so that the SASL 
community can make a decision whether or not it has merits for progression 
along the standards track.

  - Keith
--
Keith Burdis                        
---

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 05:48:10 +1100

>Draft Standard shouldn't preclude orderly progression of useful new work.

thank you.  as co-author, i nominate the following two mechanisms to be 
included in the list of the new WG:

1. Secure Remote Password SASL Mechanism, described in 
draft-burdis-cat-srp-sasl-04
2. SM2 -- A Session Management Capable SASL Mechanism, described in 
draft-naffah-cat-sasl-sm2-00

the above mechanisms have already been implemented in Java (the Cryptix 
library; http://sourceforge.net/projects/cryptix-sasl) according to another 
proposed draft (The Java SASL Application Program Interface: 
draft-weltman-java-sasl-04.txt).

cheers;
rsn

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Mar 2001 14:35:20 -0700

> mechanisms proposed after the charter has been set can wait until the charter

I really scared that SASL WG will become one of the WGs that takes forever to
finish.
Have a look at the list of SASL mechanisms at
http://www.sendmail.org/~ca/email/mel/SASL_info.html
and you will understand why.

Just to make there is no misunderstanding: I am not judging the quality and
usefulness of the mechanism you are proposing to add to the Charter.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Fri, 23 Mar 2001 17:45:28 -0800

> commercial products being developed!  does that constitute existing deployment?

Not quite.  The other mechanisms have significant production use. 
EXTERNAL, CRAM-MD5, and DIGEST-MD5 have demonstrated interoperability
between multiple independent implementations, though there are issues
with them that need to be dealt with before they can move to Draft
Standard status.

I think you underestimate the value of EXTERNAL.  It provides an
important part in the use of TLS client certs in mail protocols and I
know of at least three different products which implement it.

That said, I don't have any objection to addressing SRP and SM2 in the
SASL WG.  It's just that the other documents (and the non-WG issue of
HTTP/SASL) take precedence.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Mar 2001 19:47:59 -0800

Assuming you and your co-authors are willing to relinquish
technical and editorial "control and ownership" to this work
to the IETF, I will not object to the addition of ONE additional
mechanism (currently published as either RFC or I-D) to the
proposed charter.  I will, however, continue to note my general
reservations regarding the broadening of the proposed charter.

In reviewing these,  I believe the SRP mechanism would be
most appropriate to add.  I offer the following text which
could be added to proposed charter (just above the
out-of-scope statement):

  This group will deliver a Technical Specification
  suitable for publication as Proposed Standard describing
  a family of SASL mechanisms using the Secure Remote
  Password [RFC2945] protocol.  This work will be based
  upon draft-burdis-cat-srp-sasl-04.txt.

While the SM2 proposal is intriguing, I believe it best to
leave it off the charter for now.  I encourage the authors
to continue on an individual basis and to seek review as
appropriate.

Comments?

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 18:59:22 +1100

>with them that need to be dealt with before they can move to Draft

noted.

>know of at least three different products which implement it.

i am not denigrating the EXTERNAL mechanism;  i am only trying to compare 
its potential application areas to those of a mechanism like SRP.  a SASL 
SRP mechanism offers as much functionalities as TLS, and thus is a 
replacement candidate.

my statement was in regard to perceived usefulness.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 19:27:16 +1100

>to continue on an individual basis and to seek review as

the goal of the SM2 mechanism is to further the decoupling of the 
authorization phase from the security layer services of an SASL mechanism, 
thus reducing, and hopefully eliminating altogether, the need for SASL 
mechanism designers to address security parameters re-use within their 
mechanism.

mechanisms like SRP which offer strong confidentiality services are based 
on a secret key generated during the authentication phase.  the generation 
task within the authentication phase is a lengthy operation.  when wired 
underneath SM2, the SRP, and similar mechanisms have improved efficiency.

in conclusion: the sooner SM2 or similar mechanism, or even a SASL 
specifications that cater for session re-use, is adopted, the less need 
will be for designers of new mechanisms to address this issue on individual 
mechanisms basis.

cheers;
rsn

---

From: Keith Burdis <[email-masked]>
Date: Sat, 24 Mar 2001 11:08:48 +0200

Quoting \"Kurt D. Zeilenga\" <[email-masked]>:

> technical and editorial \"control and ownership\" to this work
> most appropriate to add.

We have no problem with relinquishing technical and editorial control and 
ownership of the SRP mechanism to the working group. In fact we would encourage 
this to ensure that the resulting mechanism is the consensus of the community 
on what an SRP-based mechanism should be.

> I offer the following text which could be added to proposed charter
> (just above the out-of-scope statement):
> 

This sounds fine.

> to continue on an individual basis and to seek review as

Perhaps it would be appropriate to bring up this topic as part 
of the process of revising the Digest SASL mechanism.

  - Keith
--
Keith Burdis                        
---

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 20 Mar 2001 19:33:29 -0800

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Mar 2001 23:45:49 -0700

--lyndon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Mar 2001 00:09:46 -0700

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 21 Mar 2001 10:38:38 -0800

---

From: Keith Burdis <[email-masked]>
Date: Thu, 22 Mar 2001 01:10:58 +0200

- Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 23 Mar 2001 07:12:17 +1100

cheers;
rsn

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Mar 2001 13:42:56 -0700

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 22 Mar 2001 13:45:45 -0800

---

From: Keith Burdis <[email-masked]>
Date: Fri, 23 Mar 2001 11:43:24 +0200

- Keith
--
Keith Burdis                        
---

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 23 Mar 2001 04:12:34 -0800 (PST)

- RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Mar 2001 09:32:01 -0600

Thanks, Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 04:52:43 +1100

cheers;
rsn

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 04:55:02 +1100

cheers;
rsn

---

From: Keith Burdis <[email-masked]>
Date: Fri, 23 Mar 2001 20:44:42 +0200

SM2

SRP

 
  - Keith
--
Keith Burdis                        
---

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 05:48:10 +1100

cheers;
rsn

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Mar 2001 14:35:20 -0700

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Fri, 23 Mar 2001 17:45:28 -0800

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Mar 2001 19:47:59 -0800

Comments?

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 18:59:22 +1100

noted.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 24 Mar 2001 19:27:16 +1100

cheers;
rsn

---

From: Keith Burdis <[email-masked]>
Date: Sat, 24 Mar 2001 11:08:48 +0200

This sounds fine.

  - Keith
--
Keith Burdis                        
---