Subject: Re: SASL Initial Response?

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

I am moving this discussion to the ietf-sasl list, since it seems to have
wandered somewhat from a discussion of IMAP's specific case.

Background for members of the IETF SASL list:  This was part of a
discussion in the IMAPEXT working group about the creation of an initial
client response extention for IMAP.  Currently, the argument against
creating such an extention is that "implementors get client-initial-send
wrong" (Specifically, servers get it wrong when clients choose to not
perform the optional initial send).  Mark, as this is your argument,
please correct me if I have summarized it incorrectly.

On Mon, 6 Oct 2003, Mark Crispin wrote:

> On Mon, 6 Oct 2003, Ken Murchison wrote:
> > > The most common offense is to implement PLAIN and LOGIN as the same thing,
> > > thus giving LOGIN challenges to PLAIN with no initial response.
> > That's inexcusable, since they are clearly NOT the same thing, and PLAIN
> > has always had a standardized SPEC.  Obviously we can't make people read
> > the specs correctly, all we can do is make them clear and unambiguous.
>
> Agreed completely.  However, multiple commercial implementations have done
> this blunder.
>
> > > The second most common offense is "334 ok, go on" or "+ ok, go on".
> > > Somtimes you also find extra CRLFs in the responses.
> > This might be an ambiguous/incomplete specification for SMTP AUTH.  I'll
> > take a look.
>
> It's not ambiguous, but you have to read three separate documents (RFCs
> 2222, 2554, and 2595) to work out how to handle an AUTH PLAIN command in
> SMTP.  For POP3, you just need to read 2222 and 2595.
>
> There is no single document, and *NO* examples, that explains this.  RFC
> 2554 is a bit better in talking about empty challenges than 2595 (see
> first paragraph of page 3, RFC 2554) but without the context of RFC 2222
> it makes no sense.

Isn't it typical that a SASL implementor should need to look at 3
documents however?  The one for their protocol, the one for the mechanism
that interests them, and RFC2222 or its replacement.

My personal reading of 2554 is that it could use a lot of rework anyway,
and I'm toying with writing an update to it right now.  Such an update
would include examples.

> > > Over and over again, I get told "just make Pine send the initial
> > > challenge"; in other words, that the initial challenge is mandatory.  But
> > > the SASL specification does not say that; and the idea of inflicting the
> > > non-interoperable brokenness of POP/SMTP on IMAP repels me.
> > So, you would like to see section 6.1 of RFC 2222bis use a MUST instead
> > of SHOULD?  For some mechs (e.g. DIGEST-MD5) this could become
> > problematic because the initial response truely is optional.
>
> Actually, I would like the SHOULD to become a MAY, and it be emphasized
> that servers MUST implement the correct empty challenge behavior.
>
> However, a MUST is preferable to the status quo, which is a de jure SHOULD
> but (at least according to certain individuals) a de facto MUST.

I don't see a strong technical reason for reducing the requirement for
SHOULD to MAY (reducing the round trips used should be encouraged).  I do
see a strong argument for making it abundantly clear that servers MUST
implement the correct omitted-challenge behavior (to be distinguished from
an empty challenge -- "" is not the same as NIL)

> > I will do this.  Just to be clear, we are only talking about
> > client-first mechanisms in which the client chooses to not send an
> > initial response, correct?
>
> Correct.  SMTP is the worst case, since you have to read three RFCs to
> work out how to implement PLAIN in SMTP.
>
> Note that there are no examples.

The examples situation should be fixed.  I don't think that we can expect
SASL implementors to (in the general case) have to read only two RFCs,
especially as we are breaking all of the mechanisms into their own
documents.

I will be forwarding your other message along to the SASL list
momentarily.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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-----

---

From: Mark Crispin <[email-masked]>
Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time)

On Mon, 6 Oct 2003, Rob Siemborski wrote:
> Currently, the argument against

Yes, that is an incorrect summary.

The argument against creating such an extension is that the current
specifications for SASL in POP3 and SMTP (which permit
client-initial-send) are complex, and as a result many POP3/SMTP servers
are not handling client-initial-send properly when the client does not
provide an initial response.

Consequently, I do not believe that IMAP should be extended to provide
client-initial-send until after the specifications are clarified.  This is
especially the case because IMAP will be a *more* complex case than
POP3/SMTP because client-initial-send is mandatory to implement in
POP3/SMTP servers but must be optional (due to compatibility with the
installed base) in IMAP servers.  Thus, the interoperability matrix with
IMAP is 4 possible configurations instead of 2 with POP3/SMTP.

The one-line summary:
	Before making it more complex, fix the existing complexity

> that interests them, and RFC2222 or its replacement.

Empirical data suggests that this requires considerably more care than
currently exists among implementors.  An understanding of the correct
server behavior for "AUTH PLAIN<CRLF>" in SMTP requires reading three
documents.

> and I'm toying with writing an update to it right now.  Such an update

Excellent; I'll be glad to help you.

> an empty challenge -- "" is not the same as NIL)

I see it as a matter of semantics.  Too many people see a SHOULD as an
excuse to overlook a MUST.

> especially as we are breaking all of the mechanisms into their own

I fear that it is a lot to expect them to read *one* RFC, much less grasp
concepts that only come through by reading three.  We seem to be in a
world where protocol engines are written by empirical tests and a cursory
glance at the examples in RFCs.

It is a helpful exercise to go through the steps to figure out what is the
correct server response to "AUTH PLAIN<CRLF>" in SMTP.  You have to start
with 2554, then 2595, then 2222, then back to 2554, then back to 2595.
You have to remember certain statements in each of these documents which
make no apparent sense until you read certain equally-obscure statements
in the other documents.  And you have to put this all together.

I went through this exercise with someone who I knew to be of
above-average intelligence.  It took some time before he grasped it.
That told me that the documents have a problem.

-- 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:15:41 -0400 (EDT)

-Rob

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 6 Oct 2003 16:49:14 -0700 (Pacific Daylight Time)

The one-line summary:

-- Mark --