Subject: Call for volunteers: Moving SASL to draft status

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 10:30:01 -0800 (PST)

By IETF procedure, it will be possible to move SASL to draft status in
April.  In order to make it that soon, we need to complete some work in
the next 3 months to identify interoperable implementations.  (Personally,
I'd like to see SASL become the first IETF standard security protocol
other than APOP). 

IETF procedure gives the WG chair responsibility to document interoperable
implementations.  As SASL was an individual submission by John Myers, I'll
volunteer to document interoperable implementations.

So what does it mean to have two independent interoperable implementations
of SASL?

Here's my concept:

We need to demonstrate interoperability of SASL profiles (including
optional portions), SASL mechanisms, SASL authorization identity and SASL 
security layers.  So we need to identify at least two clients and two
servers for each of the following which provide interoperable
authentication via SASL (send me email to volunteer for any of these or
for any other protocols):
 * IMAP
   -> _____ server  [[email-masked]]
   -> CMU Cyrus server
   -> CMU Cyrus imtest client
   -> ESYS Simeon client
 * LDAPv3
   -> _____ server
   -> _____ server
   -> _____ client
   -> _____ client
 * ACAP
   -> CMU Cyrus server
   -> _____ server  [[email-masked]]
   -> _____ client  [[email-masked]]
   -> _____ client
 * KERBEROS_V4 mechanism (including security layer)
   -> _____ server
   -> CMU Cyrus server
   -> CMU Cyrus imtest client
   -> _____ client
 * CRAM-MD5 mechanism
   -> _____ server
   -> _____ server  [[email-masked]]
   -> _____ client  [[email-masked]]
   -> _____ client
 * EXTERNAL mechanism
   -> _____ server
   -> _____ server
   -> _____ client
   -> _____ client

Names in [] are people who intend to participate in an interoperability
demonstration.  Please volunteer for any of these, including ones which
already have volunteers!

I propose we drop the SKEY mechanism from the draft status revision -- it
should be obsoleted by an OTP mechanism anyway.  I propose we split the
GSSAPI mechanism into a separate spec, as I think it will be much harder
to demonstrate interoperable implementations of it due to its complexity.

		- Chris

---

From: Mark Wahl <[email-masked]>
Date: Thu, 15 Jan 1998 19:09:20 -0600

> So we need to identify at least two clients and two

The Critical Angle LDAPv3 Client Library and Standalone Directory Server 
support negotiation via SASL of the CRAM-MD5 mechanism as described for use in 
LDAPv3.  They also support negotiation via SASL of the EXTERNAL mechanism 
when Start TLS has been used to negotiate SSL 3.0 with client authentication. 

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

---

From: Steve Hole <[email-masked]>
Date: Fri, 16 Jan 1998 10:24:07 -0700

On Thu, 15 Jan 1998 10:30:01 -0800 (PST) Chris Newman 
<[email-masked]> wrote:

>    -> ESYS Simeon client [[email-masked]]
>  * LDAPv3
>    -> _____ server
>    -> _____ server
>    -> _____ client
>    -> _____ client
>  * ACAP
>    -> CMU Cyrus server
>    -> ESYS Simeon client [[email-masked]] (IMSP now, ACAP in 
                                                development)
   * SMTP
     -> _____ server
     -> _____ server
     -> Esys Simeon Client [[email-masked]]          
     -> _____ client

Hmm ... something to think about Chris.   We implement all of the above 
protocols with the same SASL infrastructure.   I'm sure that most 
multiprotocol clients will do it that way.  I'm not sure how this 
"qualifies".

>    -> Esys Simeon client [[email-masked]]
>  * CRAM-MD5 mechanism
>    -> _____ server
>    -> Esys Simeon client [[email-masked]]
>  * EXTERNAL mechanism
>    -> _____ server
>    -> _____ server
>    -> _____ client
>    -> _____ client

Not sure what you mean by EXTERNAL mechanism Chris.   Is this for the 
"plugin" stuff that we talked about in relationship to the API?   The 
Simeon clients and servers support 3 more mechanisms not listed here, 
with a couple of others in experimental development.   How do they fit?

> to demonstrate interoperable implementations of it due to its complexity.

I mostly concur.   SKEY should be replaced with an OTP version.  
GSSAPI is the most difficult to implement, but not by order of magnitudes 
or anything.   The biggest problem is the differences between GSSAPI v1 and
v2, and implementors playing fast and loose with mandatory GSSAPI 
"extensions".   These are interoperability problems in GSSAPI, not in SASL
though.

I would recommend splitting each of the mechanism definitions into separate 
documents, all subsidiary to a framework and mechanism registration document.

---  
Steve

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Jan 1998 10:08:05 -0800 (PST)

> multiprotocol clients will do it that way.  I'm not sure how this 

I don't see that as a problem.  The point of testing SASL profiles is to
make sure that if a profile follows the rules it will interoperate.

> with a couple of others in experimental development.   How do they fit?

Nope.  The "EXTERNAL" mechanism in section 7.4 of RFC 2222.

> documents, all subsidiary to a framework and mechanism registration document.

I'd like to see KERBEROS_V4 and EXTERNAL remain in the SASL base spec, if
possible.  I don't see how we can keep GSSAPI in the SASL base spec at
draft status since GSSAPI has interoperability problems so it's stuck at
proposed status.

		- Chris

---

From: Mark Wahl <[email-masked]>
Date: Thu, 15 Jan 1998 19:09:20 -0600

---

From: Steve Hole <[email-masked]>
Date: Fri, 16 Jan 1998 10:24:07 -0700

development)
   * SMTP
     -> _____ server
     -> _____ server

---  
Steve

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Jan 1998 10:08:05 -0800 (PST)

- Chris