2.6.11 Simple Authentication and Security Layer (sasl)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-29

Chair(s):
Sam Hartman <hartmans@mit.edu>
Kurt Zeilenga <kurt@openLDAP.org>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: ietf-sasl@imc.org
To Subscribe: ietf-sasl-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-sasl/mail-archive/
Description of Working Group:
The Simple Authentication and Security Layer [RFC2222] provides key security services to a number of application protocols including BEEP, IMAP, LDAP, POP, and SMTP. The purpose of this working group is to shepherd SASL, including select SASL mechanisms, through the Internet Standards process.

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.

Goals and Milestones:
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
Internet-Drafts:
  • - draft-ietf-sasl-anon-02.txt
  • - draft-ietf-sasl-plain-03.txt
  • - draft-ietf-sasl-rfc2831bis-02.txt
  • - draft-ietf-sasl-saslprep-04.txt
  • - draft-ietf-sasl-rfc2222bis-03.txt
  • - draft-ietf-sasl-crammd5-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes  for IETF 58 SASL Working Group
    
    
    scribe: Philip Guenther
    guenther@sendmail.com
    
    
    chairs: Sam Hartman <hartmans@mit.edu>, 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 <is@sun.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 

    Slides

    SMTP Initial Response SASL Issues
    Ideographic Full Stops & U+002E