August 7 13.00-14.00
CHAIRS: Kurt Zeilenga (email@example.com)
Alexey Melnikov (firstname.lastname@example.org)
Notes taken by Roland Hedberg (email@example.com)
Minor editorial changes by Alexey Melnikov (firstname.lastname@example.org)
+ 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.
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.
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.