Subject: Thoughts on SASL

From: Keith Burdis <[email-masked]>
Date: Sun, 18 Mar 2001 13:20:33 +0200

Hi everyone

I\'d like to share some of my thoughts on SASL and the working group,
for what they\'re worth.

---

I believe that it would make sense to remove section 7 from RFC 2222 
(or rather its successor) and put it into one or more separate 
documents. The core of SASL should be distinct from individual SASL 
mechanisms and should evolve differently. Changes in mechanisms (say 
from S/KEY to OTP) should not require a revision of the core standard. 
This will also make it easier to progress RFC 2222 to Draft Standard.

On this list suggestions have been individually made to split out GSS-API, 
KERBEROS 4 and CRAM-MD5. Why not the rest too?

---

Too often I have seen it recommended that SASL mechanisms be used with
TLS providing the underlying security because the SASL mechanisms are
not able to provide sufficient security themselves.
In future, SASL should be a possible alternative to TLS. In order for
this to happen, mechanisms with strong security and a security layer
that provides protection against known attacks must be available for
use with SASL. To compete, other features that TLS has, such as session
reuse, also become important.

---

I think that the work done by the CAT working group on low infrastructure
GSS-API mechanisms (such as LIPKEY) fits nicely with SASL, so I think it
would be important to work on a means of using these mechanisms with SASL.

---

Is John Myers still listening on this list and involved with SASL?
Being the original architect of SASL, I think that it is important
that we get his input on this topic.

  - Keith
--
Keith Burdis                        
---

---

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

> This will also make it easier to progress RFC 2222 to Draft Standard.

My draft revision of RFC 2222 removes all mechanisms except EXTERNAL. 
GSSAPI goes to a separate document to recycle at Proposed and the other
two are marked OBSOLETE.

EXTERNAL belongs in the core specification as it is necessary for
integrating SASL and TLS.  Besides, it is too trivial to justify a
separate document.

---

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