Subject: RE: Some Text on Security

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Thu, 1 Apr 1999 10:57:14 -0800

However the same statements made below can be made about ANY of the MTI
authentication mechanisms that have been discussed, and in general are the
same for every shared secret authentication mechanism.

I don't think that it is appropriate to discard http-digest simply because
it's a shared secret authentication mechanism, it's "good enough" to pass
IESG muster, and that should be sufficient.  HTTP-DIGEST does have
vulnerabilities, however the vulnerabilities derive directly from the fact
that it's simple to implement, and in reality the simple to implement
criteria is overwhelming in a MTI authentication mechanism.

There is nothing that prevents a more secure SASL mechanism from being
deployed by a vendor, neither is there a requirement that a CUSTOMER not be
allowed to turn off the MTI mechanism (if the customer percieves it as being
insufficiently secure).  The customer SHOULD be notified that disabling the
MTI mechanism may cause interoperability issues, however that's ultimately
the customers decision.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

-----Original Message-----
From: Bob Mahoney [mailto:[email-masked]]
Sent: Thursday, April 01, 1999 8:19 AM
To: John Stracke
Cc: [email-masked]
Subject: Re: Some Text on Security

At 4:15 PM +0000 4/1/99, John Stracke wrote:
>
>When I was at Netscape, Everyone Knew that http-digest was insufficiently
>secure.  I don't know details, unfortunately; it was something that
everyone
>said our security people had said, but I never heard it from our security
>people.  Anybody know more?

One snippet from Keith & Patrik's document:

----
2.3 Security

     Although HTTP appears at first glance to be one of the few "mature"
Internet protocols that  can  provide  good  security,  there  are  many
applications  for which neither HTTP's digest authentication nor TLS are
sufficient by themselves.

     Digest authentication requires a secret (e.g.  a  password)  to  be
shared  between  client  and  server.   This  further requires that each
client know the secret to be used with each  server,  but  it  does  not
provide  any  means  of  securely  transmitting such secrets between the
parties.  Shared secrets can work fine for small groups  where  everyone
is physically co-located; they don't work as well for large or dispersed
communities of users.  Further, if the server  is  compromised  a  large
number  of  secrets may be exposed, which is especially dangerous if the
same secret (or password) is used for several applications.

     TLS is  descended  from  SSL,  which  was  originally  designed  to
authenticate servers to clients - not the other way around.  Even though
TLS now provides mutual authentication, a client that needs to  talk  to
multiple  servers  must  still know which credentials to present to each
server before establishing a secure connection to  the  server.   Client
and  server  must  each  use  private keys that are trusted by the other
party - typically because they are signed  by  a  certificate  authority
(CA)  known  to  the  other.  As in the digest authentication case, both
client and server need  ways  to  protect  their  private  keys  against
exposure.
----

---

From: Paul Leach <[email-masked]>
Date: Wed, 31 Mar 1999 14:09:08 -0800

Digest/SASL is the MTI for LDAP and DAV, and is getting wide use in mail
protocols -- there were three independent implementations that interop
tested at the last IMC interop-a-thon.

The combination of mail (SMTP, IMAP, POP, NNTP, IMSP, ACAP), directory
(LDAP) and WEB (HTTP, DAV) use of Digest gives it powerful momentum.

For those who have to administer environments that support all three
families, and all 9 protocols, the attraction of not having 9 different
authentication protocol databases to administer should be obvious.

Today, the only authentication protocol that seems to have that potential is
Digest.

It's also easy to implement, and a public implementation exists. See
<ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/>.

> From: Larry Osterman (Exchange) 
> Sent: Wednesday, March 31, 1999 12:19 PM
> To: 'Doug Royer'; [email-masked]
> Cc: Paul Leach
> Subject: RE: Some Text on Security
> 
> 
> Ok, I'll try sell it.  HTTP-DIGEST is a SASL-ized version of 
> the HTTP DIGEST authentication mechanism.  As such, any 
> server/client software that has support for HTTP 
> authentication will already have logic in it that's suitable 
> for packaging up for HTTP-DIGEST.  It's my understanding that 
> a bunch of the IETF protocols are moving to DIGEST as their 
> must-implement authentication mechanism.  The only other 
> competing mechanisms that I'm aware of are:
> 
> 	PLAIN (but only under TLS due to IESG no plaintext rules)
> 	CRAM-MD5 (plain text equivilant, but cannot requires a 
> server-side authentication database that is NOT interoperable 
> with other server side databases)
> 	GSS-SPNEGO - Requires that the client and server use GSSAPI.
> 
> Paul's the author, he can speak much more eloquently than I 
> could about it.
> 
> From: Doug Royer [mailto:[email-masked]]
> Sent: Monday, March 29, 1999 6:46 PM
> To: [email-masked]
> Subject: RE: Some Text on Security
> 
> 
> 
> > From: "Larry Osterman (Exchange)" <[email-masked]>
> > Date: Mon, 29 Mar 1999 18:29:38 -0800
> > 
> > I suspect that SASL is a MUST implement for the calendering 
> protocols, the
> > only issue is really what SASL mechanisms are mandated as manditory,
> 
> I agree 'I' think that SASL is a MUST.
> 
> >    and I'd
> > guess that the HTTP-DIGEST authentication mechanism is the 
> most likely
> > choice for a must-implement mechanism.
> 
> Why? - as in "Sell it"
> 
> -Doug
> -------------------------------------------------------------------
> [email-masked]		http://playground.sun.com/~dougr
> 801 W. El Camino #131		Work:   (650)786-7599
> Mountain View, CA 94040		Ham Radio: N6AAW, 
> Aviation: PP-ASEL
>

---

From: Doug Royer <[email-masked]>
Date: Sat, 3 Apr 1999 13:04:41 -0800 (PST)

Thanks.

> From: "Larry Osterman (Exchange)" <[email-masked]>
> Date: Wed, 31 Mar 1999 12:18:55 -0800
> 
> Ok, I'll try sell it.  HTTP-DIGEST is a SASL-ized version of the HTTP DIGEST
> authentication mechanism.  As such, any server/client software that has
> support for HTTP authentication will already have logic in it that's
> suitable for packaging up for HTTP-DIGEST.  It's my understanding that a
> bunch of the IETF protocols are moving to DIGEST as their must-implement
> authentication mechanism.

Which ones ? - I'll read up on it.
 
> The only other competing mechanisms that I'm
> aware of are:
> 
> 	CRAM-MD5 (plain text equivilant, but cannot requires a server-side
> authentication database that is NOT interoperable with other server side
> databases)

> Paul's the author, he can speak much more eloquently than I could about it.
> 
> > I suspect that SASL is a MUST implement for the calendering protocols, the
> > guess that the HTTP-DIGEST authentication mechanism is the most likely
> Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL