RE: Some Text on Security
Larry Osterman (Exchange <larryo <at> Exchange.Microsoft.com>
1999-04-01 18:57:14 GMT
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.
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5. Please notify the sender of any difficulties
From: Bob Mahoney [mailto:bobmah <at> mit.edu]
Sent: Thursday, April 01, 1999 8:19 AM
To: John Stracke
Cc: ietf-calendar <at> imc.org
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
>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:
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