Subject: AUTH method and MUST's

From: Doug Royer <[email-masked]>
Date: Sun, 27 Feb 2000 17:23:29 -0800

7.1.3.  AUTHENTICATE Command

   <SASL mechanism name> is a registered SASL authentication mechanism.
   (Refer to [SASL] for information on obtaining a list of currently
   registered mechanisms.) CS Supported authentication mechanisms can be
   discovered using the CAPABILITY command. All implementations MUST
   support Digest-MD5 authentication using DES and 3DES, as well as DES-56
   for link level encryption. Implementations MUST support the SASL
   Anonymous mechanism, although this may be disabled in installations.
   Implementations SHOULD implement the External SASL mechanism and the
   command STARTTLS.

1) Is DES-56 the TLS encryption?

   If yes - why is it a MUST and STARTTLS a SHOULD? I would think
   they both are SHOULDs?

2) What ANONYMOUS SASL mechanism? I thought it expired?
  
   If there is one, lets state what it is in CAP.

-Doug

---

From: Lawrence Greenfield <[email-masked]>
Date: Sun, 27 Feb 2000 23:01:18 -0500 (EST)

This is speaking as someone who has participated in implementing
multiple SASL mechanisms, but I'm not familiar with any calendar
work.  (In fact, I haven't even read the draft except for what is
being quoted.)

The sentence "All implementations MUST support Digest-MD5
authentication using DES and 3DES" makes no sense; DIGEST-MD5 uses MD5
for its authentication security, not DES.  It's possible to implement
DIGEST-MD5 without any DES implementation---in fact, the Cyrus SASL
library can be compiled without any encryption support.

DIGEST-MD5 supports both integrity and privacy SASL layers.  This
operates at a different level from TLS.  The base DIGEST spec supports
DES, 3DES, and three different modes of RC4.  It would be possible for
a connection to run STARTTLS, and then do a DIGEST authentication and
negotiate _another_ encryption layer (though it would be somewhat
silly, and a server could disallow it).

Implementing DIGEST-MD5 with encryption layer support is somewhat
easier (and more lightweight) than implementing the public key
operations required by STARTTLS, thus the rational for requiring
DIGEST-MD5 encryption support but not STARTTLS support.

RFC 2245, C. Newman, Innosoft.

Larry

---

From: John Stracke <[email-masked]>
Date: Mon, 28 Feb 2000 10:49:43 -0500

Doug Royer wrote:

> [...]
>    Implementations MUST support the SASL

I'm not comfortable with this requirement.  The purpose of a standard is to
ensure interop.  From the interop point of view, there is no difference
between a disabled feature and an unimplemented one; if it's safe to disable
it, it's safe not to implement it.  Safer, in fact, because the only
guaranteed bug-free feature is the one you don't implement.  :-)

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |No matter how tempting the prospect of unlimited|
[email-masked]|power, I will not consume any energy field      |
|                |bigger than my head.                            |
\=================================================================/

---

From: David Madeo <[email-masked]>
Date: Mon, 28 Feb 2000 11:47:02 -0500

> guaranteed bug-free feature is the one you don't implement.  :-)

I read this to mean

"The programmer must implement this, but they may choose to let the
administrator of an installed system disable it in a config file."

If I choose not to allow anonymous access on the server that I purchase,
then I don't care which client I use to connect, I don't want to allow
it.  On the other hand, if I do allow anonymous access, then again, I
don't care which client I use, I want it supported.

Perhaps it would be better to write this as....

> >    Anonymous mechanism, although individual installations may choose either 
> >    to not allow anonymous connections or to not grant any rights to the 
> >    anonymous UPN's.

dmadeo

---

From: John Stracke <[email-masked]>
Date: Mon, 28 Feb 2000 12:00:19 -0500

> administrator of an installed system disable it in a config file."

Yes, that's how I read it, too.  This is a difference in opinion, not a
misunderstanding: I maintain that this is an improper requirement to put in an
interop spec.

I do agree with you that clients MUST support anonymity.  The problem is on the
server side.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"Hastur was paranoid, which was simply a      |
[email-masked]|sensible...well-adjusted reaction to living in|
|                |Hell." --_Good Omens_                         |
\===============================================================/