Last Modified: 2003-09-29
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|
|Jan 03||Submit revised SASL GSSAPI I-D|
|Jun 03||Submit Implementation Report|
|Jul 03||Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with Implementation Report to IESG for consideration as a Draft Standard|
|Jul 03||Submit revised SASL GSSAPI I-D to IESG for consideration as a Proposed Standard|
|Aug 03||Revise charter or conclude|
Minutes for IETF 58 SASL Working Group scribe: Philip Guenther email@example.com chairs: Sam Hartman <firstname.lastname@example.org>, Kurt Zeilenga <kurt@openLDAP.org> agenda change: - add short discussion of private-use characters in saslprep status of drafts: - base-spec last call was not discussed in previous meeting, but it has been last called since then - saslprep has been last called, but generated no comments at that time. fullstop issue arose after that - Alexey taking on editorship of gssapi mech draft - digests and cram-md5 updated to support stringprep - plain mech to be clarified. When applying saslprep, is a query string or a stored string, as that affects unassigned characters - example to be added showing no initial first reply - example to be added showing non-empty authorization ID - example to be added showing failure vs success - *not* to clarify SMTP usage or use SMTP instead of ACAP Rob Siemborski (speaking for Alexey): - 2222bis: - discussion of attack if the security layer is *not* dropped on reauthentication: - attack: - client authenticates to realm A (monitored by B) - reauthenticates to realm B w/o dropping the layer - realm B server now has an oracle on the confidentiality layer - the chairs noted that the risk of attack is related to the trust relationships in the server setup - poll of room re: how to handle - 15 to zero in favor of documenting in the security considerations and not altering the SASL requirement - the option of leaving it up to the protocol profile was considered by some to be an even worse choice due to the extra complexity it introduces. - will be taken to list for confirmation of consensus - consider adding text: client should check to verify that a MITM attack didn't remove mechanisms from the list by checking after - believed to be resolved with careful wording Kurt: - last call on saslprep draft - fullstop issue - some discussion on list - Ienup Sung <email@example.com> presents: why fullstop != . - defs from unicode: - U+002E defined not just as period but also for decimals - U+3002 has U+002E as reference, not equivalence - U+FF0E (fullwidth period) *is* equivalent to U+002E - NFKC reflects this - ideographics stops are *only* used in text, not as decimal point (this is stricter in Japan and China than in Korea) - ergo: they should only be in the same equivalence class for internet style domain names (IDNA) and *not* in saslprep - <demonstration of japanese input method showing how the same keystroke generates different characters cased oin context> - comments [confusing to follow] - Jeff Altman: - wording by Ienup seems to be that decimal *can* be used in text - therefore, *should* do mapping because users might not be able to control it - Marc Crispin:Please provide an example of a real world situation where this is a problem. - Paul Hoffman: - if you believe that normal names that will be used in sasl will include periods that will be used in context-sensitive ways, then do not to the mapping - Ienup: - feels that parens vs bracket in english is an analogous situations - Jeff Altman: - no, saslprep shouldn't always do the mapping; but that mechs should overide that for saslprep usages that specify things like domain-name-like items - Marc Crispin: - does not seem credibile that the mapping is necessary - wants credible example - Nico Williams: - felt that credible example was given, thinks that it may be a UI issue - private-use characters - suggestion by Jeff Altman that private-use char restriction should be removed and replaced with discussion of usages and lack of interoperability - characters not yet in unicode from previous charsets including experimental and those in internal use in corps - ?would require normalization of private-use characters? - Ienup: - saslprep prohibits them - some text cannot be entered without these - there is some need, understand problems and issues need to make clear that this is limited use - Kurt: - cannot just drop prohibition because too much is defined privately - chair: show of hands to go forward with even considering - 4 hands for - 5 hands against - Michel: - extremely bad idea - no semantic defined - not stable - even inside same organization, different usages may exist - no temporal stability - Paul Hoffman: - all that, plus, this is for identifiers and password only - name that requires private use character is unlikely - will be taken back to the list - Rob: SMTP AUTH - proposal to add initial response to IMAP - issue is in the rfcs, it's just not clear - new pop3 and smtp profile drafts - cleanup, add examples, fill in gaps - especially cases showing failing to send initial response - consensus on list was to *not* change examples in sasl plain from ACAP to SMTP - examples of initial client response and server last challenge *will* be added to rfc2222bis - WG wrap up - milestones - GSSAPI I-D is still missing, Alexey says new version should be out by end of November - implementation report to be pushed out because recycling at proposed - (or maybe not? chairs to discuss); base may not need recycling - base is ready for last call - plain has minor tweaks, needs last call - anonymous is ready - saslprep has minor issues - cram-md5 and digest-md5 need a little more work before last call Alexey has dealt with CBC issues but missed cut-off before meeting - base, plain, anonymous, and saslprep before end of year - digest + cram shortly thereafter - gssapi by, say, May? - Bob Morgan - FYI: OASIS has interest in defining a SASL mech doing single-sign-on expect note to mailing