Last Modified: 2005-06-27
| Done | Submit revised SASL (+ EXTERNAL) I-D | |
| Done | Submit revised SASL ANONYMOUS I-D | |
| Done | Submit revised SASL PLAIN I-D | |
| Done | Submit revised SASL CRAM-MD5 I-D | |
| Done | Submit revised SASL DIGEST-MD5 I-D | |
| Done | Submit revised SASL GSSAPI I-D | |
| May 05 | Submit SASL (+ EXTERNAL) to the IESG for consideration as a Proposed Standard | |
| Jun 05 | Submit CRAM-MD5 to IESG for consideration as a Proposed Standard | |
| Jul 05 | Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard | |
| Aug 05 | Submit GSSAPI to IESG for consideration as a Proposed Standard | |
| Oct 05 | Provide implementation report plan (with milestones) | |
| Nov 05 | Revise charter or conclude |
| RFC | Status | Title |
|---|---|---|
| RFC4013 | Standard | SASLprep: Stringprep profile for user names and passwords |
|
Simple Authentication and Security Layer (SASL) WG
Tuesday, August 2, 2005 16:30-18:00 Chairs: Tom Yu <tlyu@mit.edu> Kurt Zeilenga <Kurt@OpenLDAP.org> Thanks to Love Hornquist-Astrand, Jeffrey Altman, and Jeffrey Hutzelman for scribing. Document status: Tom somehow forgets that anon was already approved. CRAM-MD5 expired. Sam Hartman desires to publish it as Historic. In any case, the document needs a better applicability statement. Some discussion ensues about whether Historic or Informational status is more appropriate. There is consensus to take the document off of the standards track. Simon Josefsson brings up the question of whether SASLprep can be added to the protocol (for migration support) and still have the document issued as Historic. Tony Hansen indicates that existing implementations already do SASLprep on CRAM-MD5, so adding saslprep support would be documenting existing practice. Sam thinks it needs to go Informational if internationalization support is added. Someone points out that we could publish as Informational and immediately move to Historic, whereupon Sam withdraws his comment. Alexey has updated the GSSAPI mech document. SASLprep needs to be addressed. Some discussion ensues about roundtrip optimization. It is pointed out that there are actually two specifications in the GSSAPI mech document: the legacy mechanisms krb5 and SPNEGO, and the family of mechansims whose names are produced by hashing. jhutz suggests removing the non-legacy mechanisms from this document. Consensus that optimization is important. Consensus for performing the document split. PLAIN mechanism revised; Kurt and Sam still need to talk about some issues. SASL base: SASL base specification (rfc2222bis) has been to WGLC. It received some responses, many editorial. Some misunderstandings about Stringprep remain. Kurt acknowledges that the text still has clarity issues. jhutz indicates that people reading the document, as well as other SASL documents, get really confused about the distinction between authentication and authorization names, and about whether responsibility for handling each of these names lies with the application implementation or with the mechanism implementation. A straw poll indicates that about 7 people find SASL names confusing, while about 2 don't. DIGEST-MD5: DIGEST-MD5 re-issued recently. Alexey sent mail to the list requesting comment on recent changes, and about where SASLprep is done. Discussion ensues about CBC mode vs counter mode. We believe counter mode is good. Alexey wants help with describing counter mode. Consensus exists to drop CBC that does not send random IV in every packet (proposal #2). Simon Josefsson proposes using a mode with combined integrity checking such as CCM/GCM. Sam recommends checking IPR carefully. Sam also suggests putting the combined mode in a separate document, and to just complete the work. Philip Guenther brings up Christian Huitema's presentation to the Applications Area about CRAM-MD5 and other challenge-response protocols being insecure due to offline attacks. Question of whether we should recommend running DIGEST-MD5 over TLS. Nico describes how channel bindings might be useful for this purpose. Some discussion of whether extending DIGEST-MD5 to use channel bindings is within our charter. Simon questions whether DIGEST-MD5 is secure compared to CRAM-MD5, considering that there is no formal security proof for the ad-hoc hash construction in DIGEST-MD5, while there is for HMAC, which CRAM-MD5 uses. Sam says he can't prove it, but believes DIGEST-MD5's construction to be similar to CRAM-MD5 in quality. Sam notes DIGEST-MD5 is relatively extensible. digest-md5 or digest-sha1? It's great if digest-md5 is done, but will it be secure? If digest-md5 is delayed, plain passwords may win. Roger Harrison indicates that LDAP community wants a strong mandatory-to-implement security mechanism, and that they have some uncertainty about whether algorithms are secure given recent discoveries about hashes. Sam points out that the challenge-response issues are separate from the hash issues, and the recent attacks are specifically against hash algorithms; we know how to protect against dictionary attacks. Kurt notes that Applications Area has had discussions whether it's time to deprecate challenge-response sent in the clear. ACTION ITEMS ============ SASL-base to iesg by end of Aug. discuss future of DIGEST-MD5 discuss future of CRAM-MD5 text for CRAM-MD5 applicability split GSSAPI SASL mech -> legacy (krb5 & spnego) vs other GSSAPI mechanisms GSSAPI SASL legacy mech ready by Oct. other revised milestones to be discussed on list |
None received.