Subject: Draft minutes for IETf 60 meeting

From: [email-masked] (Sam Hartman)
Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT)

[Review and comment; these will  be sent in mid next week]

Simple Authentication and Security Layer WG (SASL)

Tuesday, August 3 at 1300-1400
==============================

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

scribe: Wyllys Ingersoll <[email-masked]>

Summary (Kurt):
	* 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. 

Alexey Melnikov:
	* 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

Digest-MD5 (Alexey)
	* 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.

GSSAPI:
	* 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 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.

CRAM-MD5:
	* needs attention once the base spec is complete

Misc:
	* 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.  

Announcements:
	* Sam H - Liberty Alliance needs input on their document.
	* Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS

End - 13:45PM