Subject: Re: AUTH method and MUST's

From: [email-masked]
Date: Sun, 27 Feb 2000 23:54:34 -0500

This may sound like a dumb question, but is DES-MD5 (which I believe is 
also called CRAM-MD5??) in use in corporations and companies.  I know that 
Kerberos is an issue and is not in wide a use as we may like.  Does this 
security requirement ensure that we will have softtware companies who can 
build tools that can interoperate.  Does it ensure we will have 
corporations and companies capable of running those productgs.  I know 
security is key - being a former administrator and Director of security, 
it's what I look at first.  It seems like this security piece could end up 
being a show-stopper.  Am I wrong? Can someone make me comfortable that if 
we set this security rule, we will have companies implement this draft??
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Lawrence Greenfield <[email-masked]>
Sent by: [email-masked]
02/27/00 11:01 PM

        To:     IETF CALSCH WG <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: AUTH method and MUST's

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.)

   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.

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.

   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?

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.

   2) What ANONYMOUS SASL mechanism? I thought it expired?

RFC 2245, C. Newman, Innosoft.

Larry

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 28 Feb 2000 23:01:04 -0500 (EST)

From: [email-masked]

   This may sound like a dumb question, but is DES-MD5 (which I
   believe is also called CRAM-MD5??) in use in corporations and
   companies.  I know that Kerberos is an issue and is not in wide a
   use as we may like.  Does this security requirement ensure that we
   will have softtware companies who can build tools that can
   interoperate.  Does it ensure we will have corporations and
   companies capable of running those productgs.  I know security is
   key - being a former administrator and Director of security, it's
   what I look at first.  It seems like this security piece could end
   up being a show-stopper.  Am I wrong? Can someone make me
   comfortable that if we set this security rule, we will have
   companies implement this draft??

I've never heard "CRAM-MD5" called "DES-MD5".  CRAM-MD5 can be
fully implemented without any implementation of DES.

From a Unix point of view, CRAM-MD5 and DIGEST-MD5 both suffer from
needing the plaintext password to transition users to them.  They
also suffer from scalability problems that Kerberos doesn't; every
service that uses CRAM-MD5 or DIGEST-MD5 must be able to access a copy
of their secrets.  

They are only slightly harder to implement than plaintext passwords,
so I don't see an interoperability problem, if that's what you're
asking.

Larry