Minutes  for IETF 58 SASL Working Group
<BR>

<BR>

<BR>
scribe: Philip Guenther
<BR>
guenther@sendmail.com
<BR>

<BR>

<BR>
chairs: Sam Hartman &lt;hartmans@mit.edu&gt;, Kurt Zeilenga &lt;kurt@openLDAP.org&gt;
<BR>

<BR>

<BR>
agenda change:
<BR>
- add short discussion of  private-use characters in saslprep
<BR>

<BR>

<BR>
status of drafts:
<BR>
- base-spec last call was not discussed in previous meeting, but it has been last called since then
<BR>
- saslprep has been last called, but generated no comments at that time. fullstop issue arose after that
<BR>
- Alexey taking on editorship of gssapi mech draft
<BR>
- digests and cram-md5 updated to support stringprep
<BR>
- plain mech to be clarified.  When applying saslprep, is a query string or a stored string, as that affects unassigned characters
<BR>
  - example to be added showing no initial first reply
<BR>
  - example to be added showing non-empty authorization ID
<BR>
  - example to be added showing failure vs success
<BR>
  - *not* to clarify SMTP usage or use SMTP instead of ACAP
<BR>

<BR>

<BR>
Rob Siemborski (speaking for Alexey):
<BR>
- 2222bis:
<BR>
  - discussion of attack if the security layer is *not* dropped on reauthentication:
<BR>
    - attack:
<BR>
      - client authenticates to realm A (monitored by B)
<BR>
      - reauthenticates to realm B w/o dropping the layer
<BR>
      - realm B server now has an oracle on the confidentiality layer
<BR>
    - the chairs noted that the risk of attack is related to the trust relationships in the server setup
<BR>
    - poll of room re: how to handle
<BR>
      - 15 to zero in favor of documenting in the security considerations and not altering the SASL requirement
<BR>
      - 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.
<BR>
    - will be taken to list for confirmation of consensus
<BR>
  - consider adding text: client should check to verify that a MITM attack
<BR>
    didn't remove mechanisms from the list by checking after 
<BR>
    - believed to be resolved with careful wording
<BR>

<BR>

<BR>

<BR>
Kurt:
<BR>
- last call on saslprep draft
<BR>
  - fullstop issue
<BR>
    - some discussion on list
<BR>
    - Ienup Sung &lt;is@sun.com&gt; presents: why fullstop != .
<BR>
      - defs from unicode:
<BR>
        - U+002E defined not just as period but also for decimals
<BR>
        - U+3002 has U+002E as reference, not equivalence
<BR>
        - U+FF0E (fullwidth period) *is* equivalent to U+002E
<BR>
        - NFKC reflects this
<BR>
      - ideographics stops are *only* used in text, not as decimal point (this is stricter in Japan and China than in Korea)
<BR>
      - ergo: they should only be in the same equivalence class for internet style domain names (IDNA) and *not* in saslprep
<BR>
      - &lt;demonstration of japanese input method showing how the same keystroke generates different characters cased oin context&gt;
<BR>
      - comments [confusing to follow]
<BR>
        - Jeff Altman:
<BR>
          - wording by Ienup seems to be that decimal *can* be used in text
<BR>
          - therefore, *should* do mapping because users might not be able to control it
<BR>
        - Marc Crispin:Please provide an example of a real world situation where this is a problem. 
<BR>
        - Paul Hoffman:
<BR>
          - 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
<BR>
        - Ienup:
<BR>
          - feels that parens vs bracket in english is an analogous situations
<BR>
        - Jeff Altman:
<BR>
          - 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
<BR>
        - Marc Crispin:
<BR>
          - does not seem credibile that the mapping is necessary
<BR>
          - wants credible example
<BR>
        - Nico Williams:
<BR>
          - felt that credible example was given, thinks that it may be a UI issue
<BR>
  - private-use characters
<BR>
    - suggestion by Jeff Altman that private-use char restriction should be removed and replaced with discussion of usages and lack of interoperability
<BR>
    - characters not yet in unicode from previous charsets including experimental and those in internal use in corps
<BR>
    - ?would require normalization of private-use characters?
<BR>
    - Ienup:
<BR>
      - saslprep prohibits them
<BR>
        - some text cannot be entered without these
<BR>
      - there is some need, understand problems and issues need to make clear that this is limited use
<BR>
    - Kurt:
<BR>
      - cannot just drop prohibition because too much is defined privately
<BR>
    - chair: show of hands to go forward with even considering
<BR>
      - 4 hands for
<BR>
      - 5 hands against
<BR>
    - Michel:
<BR>
      - extremely bad idea
<BR>
      - no semantic defined
<BR>
      - not stable
<BR>
        - even inside same organization, different usages may exist
<BR>
      - no temporal stability
<BR>
    - Paul Hoffman:
<BR>
      - all that, plus, this is for identifiers and password only
<BR>
        - name that requires private use character is  unlikely
<BR>
  - will be taken back to the list
<BR>
- Rob: SMTP AUTH
<BR>
  - proposal to add initial response to IMAP
<BR>
  - issue is in the rfcs, it's just not clear
<BR>
  - new pop3 and smtp profile drafts
<BR>
    - cleanup, add examples, fill in gaps
<BR>
    - especially cases showing failing to send initial response
<BR>
  - consensus on list was to *not* change examples in sasl plain from ACAP to SMTP 
<BR>
  - examples of initial client response and server last challenge *will* be added to rfc2222bis
<BR>
- WG wrap up
<BR>
  - milestones
<BR>
    - GSSAPI I-D is still missing, Alexey says new version should be out by end of November
<BR>
    - implementation report to be pushed out because recycling at proposed
<BR>
      - (or maybe not?  chairs to discuss); base may not need recycling
<BR>
    - base is ready for last call
<BR>
    - plain has minor tweaks, needs last call
<BR>
    - anonymous is ready
<BR>
    - saslprep has minor issues
<BR>
    - 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
<BR>
    - base, plain, anonymous, and saslprep before end of year
<BR>
    - digest + cram shortly thereafter
<BR>
    - gssapi by, say, May?
<BR>
  - Bob Morgan
<BR>
    - FYI: OASIS has interest in defining a SASL mech doing single-sign-on expect note to mailing list