Last Modified: 2004-06-15
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|
Simple Authentication and Security Layer WG (SASL)
Tuesday, August 3 at 1300-1400
CHAIRS: Sam Hartman <email@example.com>
Kurt Zeilenga <firstname.lastname@example.org>
scribe: Wyllys Ingersoll <email@example.com>
* Done with anonymous SASLPREP, working on base spec, in WG last call.
* more attention to digest-md5, GSSAPI, cram-md5
* base spec needs more reviewers. Without review, document cannot progress.
* not many comments in base spec WG last call.
* clarification on how re-keying is done - needs new text for security considerations or recommendations section
* not much work done yet.
* open issues at end of doc
* needs comments on CBC mode, Sam H. replied, discussion to follow on mailing list
* testing of LDAP-aware client and server revealed an interop issue - digest server advertises realms that it supports, client SHOULD pick up realm from a list, but client is not obeying the "SHOULD" and chooses something else. Server assumes that the client MUST choose a listed realm. Is server broken or just interpreting the spec differently?
(Kurt) - needs further revision and engineering tests before last call.
(Alexey) - more than 1 revision needed.
* CBC mode attack to be resolved at next meeting.
(Kurt) - possible to get into WG last call by end of year?
(Alexey) - "I will try". - no co-author needed
(Kurt) - December will be earliest last-call.
* non-NULL channel bindings issue - original doc and new draft says you MUST provide NULL bindings. Simon wanted to be able to use channel bindings. It would be nice to use mechanisms like CCM or other mechanisms discussed at the KITTEN BOF.
* Multiple GSS implementations of the krb5 mechanism already working together.
* Suggestions - split draft and document GSS-KRB5 as existing, define new GSS draft to deal with new mechanisms, channel binding issue to be addressed in newer draft.
* Sam H. issue - new GSSAPI mechanism should be designed to save round-trips, existing one requires 2 or more.
* We could address this in a new draft if we think it is worth solving; discussion on list.
* Nico Williams issue - fix re-keying problems in new draft.
* Sam H. - 2 comments from Jabber (Simon J) - The original motivation for wanting channel bindings was to avoid a per-message token from one context being used with another context. Strong desire to maintain compatibility with existing GSSAPI mechanisms.
* Sam (not as chair) - WG must decide that current GSSAPI mech is adequate for future needs and wont be used as a reason for preferring to make SASL mechs instead of GSSAPI mechs - or - FIX IT. Compatiblity with existing KRB5 mech is requirement.
* Currently, 1 SASL mech for each GSSAPI mech. In future, this may not be true.
* Kurt - we WILL preserve existing SASL-GSS mechanisms.
* Sam H - GSS-SPNEGO will likely need to be deprecated because of existing security problems.
* Larry G - are there existing deployments of SASL-GSS mechs other than KRB5 and SPNEGO (eg. GSS-xxxxx)? - no
* Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands)
* Kurt - reluctant to take on new work for WG, encourage an individual draft.
* Larry G - argues against lightweight, not much need for it yet.
* Kurt - 2 proposals would be good for WG so there is choice.
* needs attention once the base spec is complete
* Kurt and Sam to revamp the list of WG milestones and send to list.
* Kurt - base spec needs to get done ASAP. Needs more comments and reviewers.
* Nico - re-keying issue again.
* Kurt - don't make assumptions about security layers that are available.
* Sam H. - no requirement for bi-directional exchange once established, re-keying is not always going to be possible.
* Nico - Still need an API for implementations that want to use it.
* Sam H. - mech designer can't know whether or not bi-directional flow will be possible.
* Nico - The mech needs a way to determine if re-key is even possible so it can make the decision on whether or not to do it. An API would make this possible.
* Kurt - add new text to draft for security considerations?
* Chris Newman - is anyone going to be negatively impacted by changing the generic SASL-GSSAPI spec at this time? Nico says he needs to check.
* Sam H - Liberty Alliance needs input on their document.
* Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS
End - 13:45PM