Subject: Draft Minutes for SASL working group meeting

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:08:52 -0500

Please comment; I'll submit at the end of the week or the proceedings
deadline, whichever is sooner.

From: Philip Guenther <[email-masked]>

               Minutes  for IETF 58 SASL Working Group

scribe: Philip Guenther
[email-masked]

chairs: Sam Hartman <[email-masked]>, Kurt Zeilenga <[email-masked]>

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-masked]> 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 list