Subject: Notes from the SASL BOF

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Aug 2001 12:29:13 -0600

I've cleaned up original notes a little bit. Any comments/corrections are
welcome.
==============
  SASL BOF
  August 7 13.00-14.00

  CHAIRS: Kurt Zeilenga <[email-masked]>
    Alexey Melnikov <[email-masked]>

  Notes taken by Roland Hedberg <[email-masked]>

  + Agenda bashing

  No changes where proposed

  + Formation Issues

  Waiting on the IESG for forming a working group, huge queue
  but there doesn't seem to be any unresolved issues with the
  Area Directors.
  Pending review we can keep on working.

  As clarification on the charter it was stated that new
  features of SASL is not within scope, this doesn't mean
  that new features can not be discussed on the mailing
  list it only means that has a lower precedence.

  It was also stated that the C API is not a work item.

  + Technical Issues
    - Base spec issues (Lawrence Greenfield)

  Current version is draft-myers-saslrev-01

   The only mechanism described in this draft is the external.

   Open issues

    Specify authorization identity (AuthID)?

     Currently it is not set. The application has to do this but it is
     further constrained by the mechanism.

     Long discussion on general constraint on AuthIDs. Proposed
     formats where 7-bit ascii without control characters,
     null terminated 8-bit strings, UTF-8 without nulls and control
     characters and unrestricted UTF-8.

     Agreement on that it would be nice to have one common format.
     The plain mechanism has problems with NULLs, CRAM-MD5 has not if
     done carefully.
     LDAP specifies UTF-8 but allows NULLs.

     Should there be a length limit ?

     The question was pushed to the list.

    Max. buffer size

     Plain buffer size or encoded buffer size ?
     The mechanism knows about the overhead of a encoding, hence either
     one can be used.
     The authors is to make a suggestion !

     Implementations also need a way to tell what buffersize is supported.

    Reauthentication

     The only mechanism that supports it is Digest-MD5.
     Should the base spec deal with this ?
     The only thing that could be done in the base spec is to give some guidance,

     otherwise there is a risk of recycling SASL spec to Draft again.

    No generic support for delegation ?

  - DIGEST-MD5 issues (Paul Leach)

   A Mechanism for HTTP originally that was modified to fit SASL framework.

   LDAPinterop has shown some wording problems in the documents, but
   no basic errors in the mechanism as such.

   There is no interoperable DES implementations yet.
   There exists at least three implementation (Microsoft, SUN, ... )
   Microsoft and SUN might have got it working between themselves.
   Happy to drop DES and only use 3DES.

   AES might be added, but not at the cost of slowing down the process
   IESG is not mandating AES yet! Paul agreed to write a separate
   document about using AES for DIGEST-MD5. He is looking for co-authors
   with good knowledge of AES.

   The is a reauth mechanism, SM2 is proposed as another mechanism.
   Microsoft has implementation LDAP client-server
   Messagingdirect does it for IMAP
   Since they have implemented it for different application spaces no
   interoperability testing has been done.
   There where some interest in trying to do some interoperability
   testing before the next meeting.

   Security AD raised issue about RC4 being weak if used without
   a hash function in front. The latter suggests that RC4 is Ok for
   DIGEST-MD5.

   Chris Newman has the editable text
   There is a list of subjects for cleaning up.
   Lawrence Greenfield will present a list of outstanding issues.

  - GSSAPI issues (Lawrence Greenfield)

   The method for using GSSAPI in SASL moved to separate document
    draft-ietf-cat-sasl-gssapi-05.txt

   The SASL mechanism name for the Kerberos V5 GSSAPI mechanism is "GSSAPI"
   and the SASL mechanism for the SPNEGO GSSAPI mechanism is "GSS-SPNEGO".
   The SASL mechanism name for any other GSSAPI mechanism is the concatenation
   of "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
   of the ASN.1 DER encoding of the GSSAPI mechanism's OID.

   Suggestions to move base32 description to separate document.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Aug 2001 12:29:13 -0600

+ Agenda bashing

  + Formation Issues

  + Technical Issues

   Open issues

    Max. buffer size

    Reauthentication