Subject: a dedicated SASL WG

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 11 Mar 2001 06:39:55 +1100

hi there,

There are currently many SASL-related drafts other than the one (SASL 
GSS-API mechanisms 
<http://search.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-02.txt>) 
listed under the Common Authentication Technology WG drafts, namely:

A. new SASL mechanisms:

    1. Secure Remote Password SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-04.txt>

    2. SM2 -- A Session Management Capable SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-naffah-cat-sasl-sm2-00.txt>

    3. X.509 Authentication SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt>

    4. ISO/IEC 9798-3 Authentication SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-02.txt>

B. Java SASL API:

    5. The Java SASL Application Program Interface
    <http://search.ietf.org/internet-drafts/draft-weltman-java-sasl-04.txt>

C. Using SASL with other protocols:

    6. Upgrading to SASL Within HTTP/1.1
    <http://search.ietf.org/internet-drafts/draft-burdis-http-sasl-00.txt>

    7. SASL in HTTP/1.1
    <http://search.ietf.org/internet-drafts/draft-nystrom-http-sasl-00.txt>

    8. LDAP Authentication Response Control
    <http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-auth-response-03.txt>

As clarified by the Common Authentication Technology (CAT) WG Chair, John 
Linn, SASL mechanisms, APIs, and SASL/protocol integration documents have 
not been work items of the CAT-WG, and CAT has itself been placed in an 
idle state, pending on possible advancement of its existing RFCs but not 
undertaking new work.

My question to the list is: how ready, and/or willing, is the SASL 
community to charter a new WG dedicated to SASL?

TIA + cheers;
rsn

cc: John Linn, Jeffrey Schiller, Marcus Leech.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 13:53:03 -0800

I actually intended to chat with JeffS and JohnM regarding
rechartering of the (concluded) SASL WG at IETF#50...  here
are my thoughts.

I believe the IETF needs to undertake the revision of
SASL [RFC2222] and select SASL mechanisms to Draft
Standard status as soon as possible so as not to
impede the progress of IETF work dependent on RFC2222.
I firmly believe that SASL itself and select mechanisms
are suitable for publication as a Draft Standard.

Hence, I would be supportive of chartering the
a working group to take SASL and a few select mechanisms
to Draft Standard status, in particular EXTERNAL, PLAIN,
and DIGEST-MD5.

Though this WG could also take on engineering of new
mechanisms (including a replacement for GSSAPI), I believe
this should be viewed as secondary to the above objective.
I believe specification of many mechanisms should be done
by other working groups or on an individual basis.

I would recommend against taking on the Java SASL API work.
The Java Community Program is working in this area and the
IETF should avoid competing with the JCP.

I also believe the use of SASL by application protocol
should be left to Application Area working groups.

        Kurt

At 06:39 AM 3/11/01 +1100, Raif S. Naffah wrote:
>hi there,
>
>There are currently many SASL-related drafts other than the one (SASL GSS-API mechanisms <http://search.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-02.txt>) listed under the Common Authentication Technology WG drafts, namely:
>
>A. new SASL mechanisms:
>
>As clarified by the Common Authentication Technology (CAT) WG Chair, John Linn, SASL mechanisms, APIs, and SASL/protocol integration documents have not been work items of the CAT-WG, and CAT has itself been placed in an idle state, pending on possible advancement of its existing RFCs but not undertaking new work.
>
>My question to the list is: how ready, and/or willing, is the SASL community to charter a new WG dedicated to SASL?
>
>
>TIA + cheers;
>rsn
>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Mar 2001 15:23:30 +0100

I hate to say this (imagine me taking cover at this point :-) but 
I would actually like (imho!) to see the sasl c api get done in the wg. 
Yes I know all the arguments against doing apis in the ietf but I 
believe that this _may_ be one of those times, much like the gssapi, 
when it  is apropriate. For the java api I absolutely agree with Kurt 
that it should go into the JCP.

However I am not sure why other mechanisms beyond the basic ones
would not be suitable for a sasl wg... What are your arguments for
that Kurt?

	Cheers Leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Mar 2001 08:53:59 -0800

>would not be suitable for a sasl wg... What are your arguments for

I was primarily attempting to narrow focus so that we could
better assure the critical work was completed in a timely
manner.  I would prefer initially that a SASL WG avoided
(re)designing mechanisms and focused on getting the "core"
of SASL to Draft Standard.  This is not to say that other work
should not continue (as it does today), but I believe we
really need to focus on getting SASL and a select set of
mechanisms to Draft Standard (so as not to impede other
IETF work).

Besides DIGEST-MD5, EXTERNAL, and PLAIN, there may be others
which are suitable for progression and appropriate for
inclusion in a "select set of mechanisms".  In particular,
ANONYMOUS and OTP may also be suitable for progression.

The fact that the GSSAPI mechanism is being redesigned
implies it is not suitable for progression. 

KERBEROS_V4 has it own set of issues which make it not
suitable for progression to Draft Standard... namely its
dependency upon Kerberos IV.

SKEY was replaced by OTP, so it likely shouldn't be
progressed.  CRAM-MD5 should be viewed as deprecated by
DIGEST-MD5 and likely shouldn't be progressed.

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 16 Mar 2001 06:50:49 +1100

At 03:23 PM 3/12/01 +0100, Leif Johansson wrote:

>...For the java api I absolutely agree with Kurt

the JCP and the IETF use two different processes for elaborating what would 
eventually become a "standard."  most notably, the specifications 
life-cycle, the access of the public at large to those specifications, and 
the make+cost of participation.

one does not preclude the other.  the Java API for SASL is an excellent 
example.  the API is subject of a JSR (Java Specification Request): 
JSR-28.  the jsr itself makes reference to the I-D listed in the original 
message of this thread (at least to an earlier version of it).

a programming language, or programming-language neutral (e.g. IDL) API, is 
an engineering solution (implementation) of a (for lack of a better word) 
abstract or algorithmic problem.  one place to discuss, at least the 
correctness and completness of the solution, is where the algorithm/method 
is being shredded to pieces (read scrutinised).

i am for including SASL APIs in a SASL WG when one is created.

[Later, at 08:53 AM 3/12/01 -0800, Kurt D. Zeilenga wrote:

>...I believe we
>IETF work)...

i agree that the first item on the SASL WG when it is created should be the 
advancement of RFC-2222 to standard status.

the reference to "select" mechanism(s), on the other hand, begs the following:

1. should the SASL WG publish a list of criteria for mechanisms worthy of 
consideration?

2. even if the answer to the previous question is no, is it worth 
publishing some "guidelines" for designers to consider before submitting a 
new mechanism?

3. in any case it may be beneficial to include a statment on the (SASL) 
WG's position with regard to new mechanisms in a SASL WG Mission Statement.

[Earlier, at 01:53 PM 3/10/01 -0800, Kurt D. Zeilenga wrote:
>...

this is a situation where overlap between WGs may, and probably should, 
occur.  the rationale, considering for example SASL/HTTP, being that it's 
an area where Domain Knowledge of both SASL and HTTP is required.

since i do not know if the ietf has, or not, such a collaboration mechanism 
in place, i'll stop here.

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 13:01:52 -0800

At 06:50 AM 3/16/01 +1100, Raif S. Naffah wrote:
>the JCP and the IETF use two different processes for elaborating what would eventually become a "standard."

There should only be one standard and since the JCP is
already working in this area and is the recognized standards
area for Java and Java Extensions, I feel the IETF should
avoid competing with it.

>jsr itself makes reference to the I-D listed in the original

Which one of the reasons we have RFC 2026, 7.1.  Luckily, it
this conflict is only between a JSR and an I-D... and not
between a Java Standard Extension and a Standard Track RFC.

>i agree that the first item on the SASL WG when it is created should be the advancement of RFC-2222 to standard status.

Noted.

>1. should the SASL WG publish a list of criteria for mechanisms worthy of consideration?

I think it would be appropriate for a revised SASL specification
to include security considerations for a SASL profile author to
take into account when it selects mechanisms.  I note that currently
it's the SASL profile author who selects the mechanisms which
are required, recommended, or optional to implement to provide
the desired security services for the protocol.

>2. even if the answer to the previous question is no, is it worth publishing some "guidelines" for designers to consider before submitting a new mechanism?

I would think it appropriate for the revised specification to
at least provide security issues which a developer should
consider.

>3. in any case it may be beneficial to include a statment on the (SASL) WG's position with regard to new mechanisms in a SASL WG Mission Statement.

I would think it appropriate for the charter to say what was in
scope and wasn't.

>this is a situation where overlap between WGs may, and probably should, occur.  the rationale, considering for example SASL/HTTP, being that it's an area where Domain Knowledge of both SASL and HTTP is required.

As I have little knowledge as to the particulars of HTTP's SASL
profile, so I'll comment in general.

I would assume that application area WG will have or obtain
appropriate security expertise needed.  The application area WG
"owns" the application protocol including specification of use
of SASL or other security frameworks.

>since i do not know if the ietf has, or not, such a collaboration mechanism in place, i'll stop here.

I would say there are established processes in place to
promote development of suitable specifications.

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Mar 2001 20:15:17 -0800

> impede the progress of IETF work dependent on RFC2222.

Benefits of a SASL WG:
* Chair or appointee has task to document feature interoperability for
  advancement
* Chair to nag document editors so work gets done
* Some engineering concensus needed on GSSAPI update and SASL C API issues.

I'd say it just worth it for those reasons.  But we need a volunteer (or 
volunteers) for chair (or co-chairs).

I suggest we try to get it chartered as joint security and apps area WG 
(one AD from each area as area advisor).

> to Draft Standard status, in particular EXTERNAL, PLAIN,

I'd be inclined to drop PLAIN from that list.  I don't think it needs 
formal WG attention, and the normative reference to TLS is likely the 
gating factor on advancement.

> this should be viewed as secondary to the above objective.

draft-ietf-cat-sasl-gssapi-02.txt work needs to be done in parallel to 
advancing 2222 since 2222 includes GSSAPI mechanism.

> ANONYMOUS and OTP may also be suitable for progression.

I wouldn't include any mechanisms other than EXTERNAL, GSSAPI (from 2222) 
and DIGEST-MD5 in WG charter.

> dependency upon Kerberos IV.

I suggest we just take it out of the revision, so when 2222 is obsoleted by 
revision, KERBv4 goes historic.  Other option is to split it out into 
informational RFC with explicit "LIMITED USE" label on the mechanism.

> progressed.

Yup.  I wrote the OTP SASL spec so we wouldn't have to worry about SKEY 
when advancing 2222.

> CRAM-MD5 should be viewed as deprecated by

I disagree.  CRAM-MD5 has wide implementation in the email community. 
There's no reason not to advance it to full standard with an appropriate 
caveat about the relative security, interoperability and complexity issues 
with respect to DIGEST-MD5.  But the WG shouldn't spend time on CRAM-MD5, 
since DIGEST-MD5 is the better choice for mandatory-to-implement mechanism.

> I would actually like (imho!) to see the sasl c api get done in the wg.

I volunteer to be document editor or co-editor for C API.  The caveat is 
that I believe APIs hold a different place in the world from protocols. 
Protocols provide interoperability, while APIs provide depolyment.  Having 
a publically documented API with an open-source implementation is 
sufficiently beneficial to deployment of a protocol that I think it is well 
worth WG effort.  But there's nothing wrong with multiple APIs, so I'd 
prefer to see the SASL C API as an informational RFC.

		- Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 21:05:34 -0800

Chris,

>I suggest we try to get it chartered as joint security and apps area WG (one AD from each area as area advisor).

That a good suggestion.  We should chat with the ADs at IETF#50.

>I'd be inclined to drop PLAIN from that list.  I don't think it needs formal WG attention, and the normative reference to TLS is likely the gating factor on advancement.

A very good point.

>draft-ietf-cat-sasl-gssapi-02.txt work needs to be done in parallel to advancing 2222 since 2222 includes GSSAPI mechanism.

GSSAPI is PS and that might be gate.  I was thinking of
splitting it out from the "core" SASL specification.

>I wouldn't include any mechanisms other than EXTERNAL, GSSAPI (from 2222) and DIGEST-MD5 in WG charter.

DIGEST-MD5 is the mandatory-to-implement SASL mechanism for LDAP.
LDAPbis currently has it on their charter, but they do not have
the expertise.  Hence, I'd prefer it shift to a SASL WG.

>I suggest we just take it out of the revision, so when 2222 is obsoleted by revision, KERBv4 goes historic.

I concur.

>I disagree.  CRAM-MD5 has wide implementation in the email community. There's no reason not to advance it to full standard with an appropriate caveat about the relative security, interoperability and complexity issues with respect to DIGEST-MD5.

I have no objection to this approach.

>I volunteer to be document editor or co-editor for C API.  The caveat is that I believe APIs hold a different place in the world from protocols. 

I concur.  I'd prefer such be done as individual effort and
published as an Informational RFC.  I note that Informational
RFCs can have a significant unifying effect upon the community,
evidence RFC 1823 (the LDAPv2 C API).

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 16 Mar 2001 14:15:11 -0500

Date: Thu, 15 Mar 2001 20:15:17 -0800
   From: Chris Newman <[email-masked]>

   [...]

I think this is a really good idea.

   [...]

It would be nice to get a document that actually refers to CRAM-MD5
as it's used in SASL, but this doesn't have to be done in a working
group.

Yes, having an informational document would be nice.  We've already
seen some convergence in the SASL APIs available (we'd see even more
if CMU had more programmer resources) and it would be nice to
encourage others, too.

Larry

---

From: Chris Newman <[email-masked]>
Date: Sat, 17 Mar 2001 01:09:34 -0800

> splitting it out from the "core" SASL specification.

Yes.  I propose charter include task to recycle separate sasl-gssapi spec 
at proposed and drop gssapi text from SASL base spec.  This should be done 
at the same time as moving base spec to draft, since we want to continue 
forward with gssapi in the future.

		- Chris

---

From: [email-masked]
Date: Sat, 17 Mar 2001 16:49:50 -0800

I think forming a SASL working group is the right way to get it progressed to 
Draft Standard.

It seems to me from this thread, tho, that there's still an open question as 
to whether we're forming one working group to (a) take SASL and selected SASL 
mechanisms to Draft Standard maturity level, (b) progress other existing SASL 
mechanisms to Draft Standard (or recycle at Proposed, as needed), and (C) 
develop new SASL mechanisms. Or whether we're forming one working group now to 
exclusively do (a), and then figure out later (or maybe in parallel if someone 
has the cycles) to do (b) and/or (c).

What's your thoughts on this Kurt'n'Chris?

thanks,

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Mar 2001 22:59:58 -0600

>What's your thoughts on this Kurt'n'Chris?

I suggest we focus on critical work for now.

I believe there is consensus that the primary objective
should be to take SASL and a few select mechanisms to Draft
Standard (without any recycling at Proposed).  There is some
debate as to which mechanisms are suitable, but I think we
will converge upon the specific list of select mechanisms
soon.

I note that while GSSAPI cannot be immediately progressed
to Draft Standard, this should likely be a charter item as
well.

Beyond this, I would prefer not to take on additional work
items until the primary objective (SASL to DS) is completed.
This, of course, would not preclude individual work nor the
WG from review other works.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 13:53:03 -0800

Kurt

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Mar 2001 15:23:30 +0100

Cheers Leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Mar 2001 08:53:59 -0800

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 16 Mar 2001 06:50:49 +1100

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 13:01:52 -0800

Noted.

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Mar 2001 20:15:17 -0800

Benefits of a SASL WG:

		- Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Mar 2001 21:05:34 -0800

Chris,

A very good point.

I concur.

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 16 Mar 2001 14:15:11 -0500

[...]

   [...]

Larry

---

From: Chris Newman <[email-masked]>
Date: Sat, 17 Mar 2001 01:09:34 -0800

- Chris

---

From: [email-masked]
Date: Sat, 17 Mar 2001 16:49:50 -0800

thanks,

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Mar 2001 22:59:58 -0600

Kurt