Simple Authentication and Security Layer (SASL) WG
IETF 64
Tuesday, November 8, 2005
09:00-11:30

Chairs:
Tom Yu 
Kurt Zeilenga 

Thanks to Bob Morgan for scribing.

Document Status:
================

SASL base spec (rfc2222bis) is delayed; hopefully back on track in a
few weeks.  CRAM-MD5 direction less certain after list discussion.  No
objections to WGLC for GSSAPI mech, but Sam Hartman reinforces that
silence is not assent for this particular WGLC.  PLAIN mechanism is
waiting for Sam to talk with Kurt, but this will wait until after SASL
base spec is done.  DIGEST-MD5 is making progress.

CRAM-MD5:
=========

We appeared to have prior consensus at IETF63 to take CRAM-MD5 off the
standards track.  Recent list discussion calls that consensus into
question.  People seem to be leaning in favor of Informational in
preference to Historic.  A show of hands indicates a few people remain
in favor of standards track for CRAM-MD5.  Kurt notes that remaining
on the standards track requires fixing problems, not just publishing
current practice, e.g., fixing internationalization, and security
problems.  Simon Josefsson asks what the security problems are.
Answer: integrity protection, etc.  Simon asks why we can't just
recommend mandatory TLS.  Chris Newman thinks Informational is a
reasonable compromise.  Simon can live with Informational.  A poll of
people wanting CRAM-MD5 to remain on the standards track shows no
objections to moving CRAM-MD5 to Informational.

Kurt would like to see document describe existing practice, but should
also describe shortcomings of the mechanism, not only the security
issues, but also the internationalization issues.  Cyrus Daboo [via
jabber] asks if any of proposed changes to CRAM-MD5 effectively
require vendors to re-implement.  Kurt replies that fixing
internationalization requires SASLprep, which is a change.  Tony
Hansen suggests that we document why CRAM-MD5 is no longer on the
standards track.  Chris Newman suggests that the person who is pushing
for CRAM-MD5 to be taken off the standards track be the one to write
that text.

DIGEST-MD5:
===========

Alexey Melnikov talks about DIGEST-MD5.  Removed AES-CBC proposal with
explicit separate IV block.  Added text about channel bindings to TLS.
Started replacing ABNF, referencing new ABNF RFC; ran out of time.
Perhaps split specification of extended ABNF syntax to separate
document to HTTP people can use it?

AES counter mode -- started to write text; needs answers regarding IV
construction for counter.  Sam notes followup discussion in IETF63
SAAG in response to WG summary.  You could use combined
integrity/encryption mode instead.  Not much support on mailing list
for counter mode.  A poll of the room shows a few people in favor of
adding AES counter mode to DIGEST-MD5, and no objections.  No
volunteers for writing text.  Sam is willing to answer questions and
do review.

Simon says we should do security layers right or not at all.  (He
doesn't believe they're widely used.)  Kurt opposes working on
DIGEST-MD5 without security layers due to application protocol
requirements for supporting strong authentication and integrity.  Sam
agrees with both Simon and Kurt; existing CBC proposal meets security
layer requirements, but possibly not certain performance requirments.
Document likely won't be approved without security layer.  No
volunteers obvious for counter mode.  Sam will help find someone to
work on counter mode.  Tom asks if people are willing to delay the
document for AES counter mode.

Alexey notes that AES isn't mandatory to implement.  Sam suggests that
the issue of RC4 as mandatory cipher be considered to be re-opened.
Kurt suggests that we postpone discussion of mandatory cipher until
text is produced describing the cipher suites.

Issues remain with ISO8859-1 compatibility (backwards compat with HTTP
servers).  Some HTTP people declare that UTF-8 is the character set
for HTTP.  Desire for DIGEST-MD5 to share authentication database with
HTTP-DIGEST.  Simon's implementation uses UTF-8.  Kurt will talk to
Applications Area people about the problem.  Next revision before end
of 2005.

SASL Base:
==========

Kurt will write next revision during IETF64.  Chris Newman has
suggested text on how to handle certain errors; no objections.  Also,
empty server challenge requirement could break things; proposal to
delete text requiring that challenge be empty.  No objections.  Simon
has proposed "SHOULD close connection" on detection of mechanism
downgrade; no objections.  Pekka has raised issues against the
security considerations section, primarily regarding intermixed
discussions of multiple security considerations.  Kurt proposes
splitting discussions; no objections.

Discussion about IANA considerations, particularly regarding families
of mechanisms.  Sam asks that if we require IESG approval, to give the
IESG explicity guidance.  Simon suggests delegation of namespace to
registrant of mechanism family; no objections.

Milestone Review:
=================

[see Action Items below]

Open Mic:
=========

Simon asks if GSS includes the family of mechanisms.  Sam says no,
asks if Simon wants to work on it; Simon agrees.  Initial draft in Feb
2006.  Note base-32 encoding needs checking with DNSEXT.  To IESG
around Sep 2006.

Sam notes that there was a dinner meeting discussion SASL for HTTP.
There will most likely be a discussion of channel bindings in that
context, so people should be prepared.  Kurt wants to make sure we
don't break compatibility, so either new mechansisms, or use
extensibility features of existing ones.

Action Items:
=============

Kurt will talk with Apps Area people about HTTP DIGEST 8859-1 issue

GSS (krb5 & SPNEGO) WGLC nowish

SASL base to IESG Dec 2005

DIGEST-MD5 next rev before Dec 2005

GSS mech family initial draft Feb 2006

CRAM-MD5 WGLC around Mar 2006

DIGEST-MD5 WGLC around Mar 2006

implementation plan Summer 2006

GSS mech family to IESG Sep 2006