Subject: Re: SASL Initial Response? (fwd)

From: Rob Siemborski <[email-masked]>
Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT)

Here are some of Mark's comments on RFC2222bis:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

---------- Forwarded message ----------
Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: RL 'Bob' Morgan <[email-masked]>,
     IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> I agree.  I also suspect an example or two could help the appropriate
> sections of 2222bis.  But further discussion of this should probably move
> to the ietf-sasl list.

I'm not on the ietf-sasl list, so would appreciate this being passed on.
I guess that I should be at the SASL session in Minneapolis (assuming I go
there which seems likely).

Examples are always helpful.  Section 6.1 of 2222bis should give examples
of AUTH PLAIN in SMTP both with and without initial client data.

Similar examples should appear in the specification for the PLAIN
mechanism (which currently is hidden in the IMAP/POP3/ACAP TLS spec!)
*and* in the specifications for POP3 SASL and SMTP SASL.

> Obviously.  But currently it seems that the primary reason that we don't
> have an initial SASL response in IMAP is concerns over clarity of the
> SASL specification.

Actually, the primary reason was compatibility with the past; IMAP SASL is
older than SASL.  I'm willing to go along with it as a server-optional
extension *IF* the problems with the current client-optional
server-mandatory initial client data POP3/SMTP SASL are fixed.

Since implementation of initial client data will be server-optional in
IMAP, it will be more complex than in POP3/SMTP.  This is because it's
mandatory to implement in POP3/SMTP servers.

> If fixing *that* specification still isn't good enough, I'm totally
> willing to supply text in the draft for the IMAP extention to the effect
> of "pay careful attention to the fact that initial responses are
> *optional*," even to the point of making it a Security Consideration.

We will need that text, and much more.

> And indeed, any IMAP server that didn't get this right would immediately
> have a large number of old-style clients fail to work against it anyway,
> since it is an extention and not part of the base protocol.

It's not just IMAP servers we have to worry about.  It's also IMAP
clients.

We already have clients which fail to interoperate with a server that does
not have a particular extension and/or declare such servers to be
"broken."  The offenders know who they are.

We have to concern ourselves about the possibility of clients that think
that initial data is mandatory to implement in the server (since it is
mandatory in POP3 and SMTP).

Thus, the situation is *worse* with IMAP than with POP3 or SMTP.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 6 Oct 2003 19:16:30 -0400 (EDT)

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---------- Forwarded message ----------
Date: Mon, 6 Oct 2003 16:12:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: RL 'Bob' Morgan <[email-masked]>,
     IMAP Extensions WG <[email-masked]>
Subject: Re: SASL Initial Response?

-- Mark --