Last Modified: 2004-02-02
This group will deliver a revised SASL Technical Specification suitable for consideration as a Draft Standard. This work will be based upon RFC 2222 and draft-myers-saslrev.
This group will deliver revised Technical Specifications suitable for consideration as Draft Standards for the following SASL mechanisms: ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon, draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt.
This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSSAPI family of SASL mechanisms. This work will be based upon RFC 2222 and draft-ietf-cat-sasl-gssapi.
The following areas are not within the scope of work of this WG:
- new features,
- SASL Mechanisms not specifically mentioned above, and
- SASL "profiles".
However, the SASL WG is an acceptable forum for review of SASL-related submissions produced by others as long as such review does not impede progress on the WG objectives listed above.
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 | |
Jan 04 | Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG for consideration as Proposed Standards | |
Feb 04 | Submit CRAM-MD5 to IESG for consideration as a Proposed Standard | |
Mar 04 | Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard | |
May 04 | Submit GSSAPI to IESG for consideration as a Proposed Standard | |
Jun 04 | Provide implementation report plan (with milestones) | |
Aug 04 | Revise charter or conclude |
Sasl Working Group IETF 59 Minutes Chairs: Sam Hartman <hartmans@mit.edu> Kurt Zeilenga <kurt@openLDAP.org> The SASL working group met for an hour at IETF 59. The primary objective of the meeting was to determine next steps for RFC 2222bis. The chairs are concerned that the document has not received sufficient review. The chairs will contact the apps and security areas and ask for review of the specification before last call. Kurt Zeilenga raised several issues on the mailing list. Most of these were resolved before the meeting; Kurt will check future versions of the draft to confirm resolution. One of Kurt's issues that is not resolved is the handling of security layers for multiple reauthentications. At IETF 58, we decided not to change the protocol because of this threat, but Kurt raised concerns about the wording of the security consideration. During this discussion Sam Hartman realized this attack is apparently an instance of a more general attack. Sam will confirm this and propose text on the list. Bob Morgan described his concerns about the confusion between authentication identity and authorization ID. The sense of the room was that while we want to be as clear as possible, both concepts are important and we need to keep both terms. This discussion is still open on the list. A new document will be published shortly after the meeting. There will be a need for at least one more revision, slated for early April before a last call. We hope to have the base spec to the IESG by May; this is a milestone slip. Bob raised concerns about how RFC 2119 language such as MUST and MAY are used in this document. He is concerned that some keywords are addressed to implementations and others to future specifications. He is not sure that RFC 2119 language should be used for requirements on future specifications. Kurt believes that it is important to make sure readers know what keywords apply to. Examples of ways to do this include separating language for profile requirements from language for implementation imperatives. No resolution was reached on the appropriateness of RFC 2119 language for purposes other than implementation imperatives. ALexey Melnikov still needs input on use of stringprep and saslprep in digest-md5. There was discussion of dropping support for ISO 8859-1 and claiming that all strings are UTF8. This will be resolved on the list. Sam agreed to review the AES mode for digest-md5. The working group previously agreed to use explicit IVs to avoid adaptive chosen plaintext attacks, but ALexey has two alternative wire formats for explicit IVs. We hope to have digest-md5 last called by July. Alexey thinks this is very op |