Subject: Re: draft-murchison-sasl-login-00 Last Call

From: Ken Murchison <[email-masked]>
Date: Tue, 07 Oct 2003 14:38:55 -0400

Steven F Siirila wrote:

> In reading section 2.2:
> 
> 2.2.  Server side of authentication protocol exchange
> 
>     The server issues the string "User Name" in challenge, and receives a
>     client response.  This response is recorded as the authorization
>     identity.  The server then issues the string "Password" in challenge,
>     and receives a client response.  This response is recorded as the
>     authorization authenticator.  The server must verify that the
>     authorization authenticator permits login as the authorization
>     identity.
> 
>     Note: There is at least one widely deployed client which requires
>     that the challenge strings transmitted by the server be "Username:"
>     and "Password:" respectively.  For this reason, server
>     implementations MAY send these challenge strings instead of those
>     listed above.
> 
> Why is the string "User name" chosen as the suggested challenge to be sent
> by the server instead of "Username:", considering that second paragraph?
> Are there other clients out there that expect "User name" as a challenge
> string?  Note that the current Cyrus SASL (V2) returns "Username:" and
> "Password:".

The former describes the original intended specification, the latter 
describes an existing deployed implementation which requires these 
challenge strings (think large monopoly in Redmond, WA).

The wording in the draft is a compromise between the authors.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 03:04:05 -0700

Ken,

This use of MAY is a bit problematic.  MAY items are suppose to be
truly optional (see RFC 2119).  As servers using the
alternative protocol tokens won't interoperate with client not
expecting those alternatives, this item isn't.

Likely this can be addressed by (more explicitly) limiting the
applicability of the option.

Kurt

At 11:38 AM 10/7/2003, Ken Murchison wrote:

>The former describes the original intended specification, the latter describes an existing deployed implementation which requires these challenge strings (think large monopoly in Redmond, WA).
>

---

From: Ken Murchison <[email-masked]>
Date: Tue, 07 Oct 2003 19:12:32 -0400

> applicability of the option.

I'll let Mark argue for the continued use of MAY.

FWIW, I wanted to make the challenge strings used by M$ products a 
SHOULD and those originally intended by c-client a MAY.  Mark is against 
making c-client [semi-]uncompliant, which I can also agree with.

Cyrus SASL uses the M$ challenges and we are not aware of any products 
which fail to work with these strings, since clients other than M$ 
correctly ignore the contents of the challenges.

Mark, Rob and myself struggled with this issue a lot.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT)

> making c-client [semi-]uncompliant, which I can also agree with.

Especially since c-client is the first, reference, and most widely
deployed implementation of the LOGIN mechanism; and was written by its
inventor.

I think that c-client's needs are more important that the evil empire's,
and that it would be reprehensible to change specifications to match a
broken implementation in evil empireware.

I have never encountered the reported problems with evil empireware.

-- Mark --

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Oct 2003 09:46:51 -0400

> deployed implementation of the LOGIN mechanism; and was written by its

I'm not going to argue numbers, but I'm guessing that there are a 
significant number of deployed Outlook clients.  ;)

> broken implementation in evil empireware.

Your comment seems somewhat self serving, but I also find it distasteful 
to have to cater to M$.  The problem is that LOGIN was never a standard, 
and M$ took it and did their (incorrect) own thing.  Since the cat is 
already out of the bag, and I don't think we can get M$ to change their 
code, we have to deal with it.

> I have never encountered the reported problems with evil empireware.

This is probably because c-client isn't used in any SMTP server code (at 
least AFAIK).  AFAIK, the challenge strings are only an issue with 
Outlook's SMTP AUTH code, so perhaps we can make the M$ strings a 
SHOULD/MUST for SMTP server code only.  I don't think this will make 
c-client noncompliant, will it?

We probably need more input from others on the list, since Mark and I 
are just rehashing discussions that we've already had.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT)

> significant number of deployed Outlook clients.  ;)

Even if Outlook may be more widespread, there are millions of deployed
Pine clients (we have the numbers).

c-client is more than just client code; it's also the engine behind UW
imapd and ipop3d.  UW imapd is the most widely deployed IMAP server.

> Your comment seems somewhat self serving,

Well, I could say the same for many comments from ...

Let's not go here.

> but I also find it distasteful
> to have to cater to M$.

> The problem is that LOGIN was never a standard,
> and M$ took it and did their (incorrect) own thing.

LOGIN was not documented because I followed the rules.  IESG said "no more
plaintext password authentication mechanisms."  IESG didn't offer any
wiggle room the way.  Politics allowed PLAIN to be snuck through but not
LOGIN (which preceeded PLAIN by 3 1/2 years).

If you're going to cater to Microsoft's bugs, then much of IMAP needs to
be thrown out because of broken behavior in their software.  Microsoft
should be made to fix their bugs instead.

I would like to see the security people redefine TLS so that that the
maximum payload is 5 bytes less than 16K (rather than 16K), since
Microsoft requires that.

> c-client noncompliant, will it?

I am working an an SMTP server.  I don't think that an SMTP-only kludge
to accomodate a bug is appropriate when there is another alternative (that
is, PLAIN).

The correct answer is that if Outlook has problems using LOGIN, then it
can always use PLAIN.

-- Mark --

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 13:49:38 -0400

It seems like you may want to document clearly the interoperability
concern.  Mention specific products as examples if it makes your text
more clear.  Just make sure your claims are accurate.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 07 Oct 2003 14:38:55 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 03:04:05 -0700

Ken,

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Tue, 07 Oct 2003 19:12:32 -0400

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Oct 2003 18:24:30 -0700 (PDT)

-- Mark --

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Oct 2003 09:46:51 -0400

---

From: Mark Crispin <[email-masked]>
Date: Wed, 8 Oct 2003 08:35:11 -0700 (PDT)

Let's not go here.

-- Mark --

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 13:49:38 -0400