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