RE: Compromise Authentication Proposal

[Jonathan Trostle <jtrostle@cisco.com>]

> X-SMAP-Received-From: outside
> Resent-Date: Mon, 5 Oct 1998 17:02:39 -0700 (PDT)
> From: Paul Leach <paulle@microsoft.com>
> To: IETF LDAP Extensions WG <ietf-ldapext@netscape.com>
> Subject: RE: Compromise Authentication Proposal
> Date: Mon, 5 Oct 1998 17:02:23 -0700 
> Resent-Message-ID: <"wBd1m1.0.Zl6.SuL6s"@glacier>
> Resent-From: ietf-ldapext@netscape.com
> X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/840
> X-Loop: ietf-ldapext@netscape.com
> Resent-Sender: ietf-ldapext-request@netscape.com
> 
> At Chicago, there was conditional concensus about using Digest as the MTI.
> It was conditional upon a digest/SASL spec being delivered "in a couple of
> weeks". It took a little longer than that, but I believe the precondition
> has now been met, and still seems to be relevant.
> 
> After a private conversation with Tim Howes, he suggested I "call the
> question". So here goes:
> 
> Are there any objections to making Digest/SASL the Mandatory-to-Implement
> non-plaintext password mechanism? If so, what are they?
> 
> Are there any objections to making Digest/SASL the only
> Mandatory-to-Implement mechanism? If so, what are they?
> 
> Paul
> 

Answer to 1st question: No. (Chris and Paul have done a nice job with the 
Digest spec.)
Answer to 2nd question: Yes.

Here are some issues with making Digest Auth MTI. It has been stated that
making an algorithm MTI does not make it mandatory to use. But if one
is not going to use it, why would they implement it on memory constrained 
network devices?

Issues with Digest as A General Purpose Mechanism

(1) We need delegation functionality. Digest does not appear to have it, 
but Kerberos has it (TLS is working on it). So Digest does not meet our
requirements.

(2) There are some scaling issues with digest. Without a password 
policy, users will choose weak passwords. Different realms will 
implement different password policies leaving users with multiple 
passwords. In enforcing the password policy, realms will need access 
to the cleartext password, a malicious realm (the existence of which 
becomes inevitable as you scale Digest up) can impersonate the
user to other realms.

(3) On server side, pull model implies additional work for the server
as opposed to the client.

Issues with Kerberos

(1) Does not scale. Invalid criticism; scales fine within an organization. 
Use public key extensions (pkinit Internet draft) or islands of 
trust for scaling outside the organization.

(2) Can't find the KDC from outside the Kerberos trust hierarchy. 
Valid criticism (Paul Leach); a little work is needed here. There are 
also a couple of alternatives. There is a draft for adding functionality 
to Kerberos to allow the server to contact the KDC. Or the pkinit 
extension (pktapp draft) can be used to do direct authentication 
without the KDC.

(3) Too much work to implement. Can purchase GSSAPI toolkit, Kerberos
libraries and integrate into LDAP server. No need to do your own 
Kerberos implementation. There are also freeware versions. On NT5,
it will only require using SSPI calls; Kerberos is already there.

(4) Not deployed and never will be. It has significant deployment
in financial companies who are some of the most security conscious 
customers. Is is the primary authentication mechanism in NT5.


Issues with TLS

(1) Slow performance which does matter for network devices and servers.

(2) Management overhead of certificates (will diminish with time
as more infrastructure and tools are deployed). But additional 
spec's will be required for full interoperability.

(3) Spec's still evolving (authorization spec's).


Since we must have MTI for interoperability, let clients implement either
Digest or Kerberos. Servers MUST implement both. Adding TLS as a third MTI 
algorithm for servers and an option for clients probably makes sense too.

Jonathan