[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: draft minutes from Chicago meeting

We are not creating an RFC just to satisfy the IESG.
We are creating an RFC to solve the problem pointed
out by the IESG, which is one of interoperability.

The CRAM-MD5-like solution will specify a minimum level
of security that is better than clear-text passwords.
This is a step in the right direction that will raise
the minimum level of security available to LDAP clients
and servers. It is not the be-all end-all solution to
every application's security needs. Nobody is claiming
that it is. Maybe it is enough to stop the rampant use
of clear-text passwords, which is clearly a Bad Thing.
That is our hope.

There exist many applications which require much
higher security, such as that provided by TLS. This
has less to do with the size of the directory involved
than it does with the character of the information the
directory contains, the requirements of the application,
and the environment in which the whole thing runs.

But regardless of how I might disagree with how you came
up with your categories, the answer is yes, we intend
to solve both problems. A bad way to do that would be
to ask "who's got the most stringent requirements?" and
then require eveybody to implement that. Another bad
way would be to tie together solutions to these
clearly separate problems.

A good way to approach the problem, and the approach
that this group will take, is to separate problems
that can be separated and solve them one at a time.
That's all I am saying. You and others should feel
free to continue discussing the merits of requiring
TLS or kerberos or foobaz. Just realize that it's a
separate discussion from selecting the cram-md5-like
non-clear-text authentication mechanism.   -- Tim

Erik Skovgaard wrote:
> 
> Tim,
> 
> OTOH, just creating an RFC to satisfy the IESG is not really serving the
> general good.  This issue is real.  I vote for taking a practical view and
> it sounds to me as if we have two factions here:
> 
> 1. Those implementing small and medium sized directories.  They are happy
> with CRAM-MD5.
> 
> 2. Those implementing large enterprise directories that may even have to
> interoperate with other organizations' directories.  CRAM-MD5 will not work
> for this category of people.
> 
> So I think the *real* question to ask is whether this group intends to
> address both categories of users or only one of them?
> 
> I currently work mostly with people belonging to the second category and so
> my view is biased, so I won't mention my preference :-)
> 
> The question still remains to be answered, however.
> 
> Cheers,                 ....Erik.
> ---------------------------------------
> Erik Skovgaard
> GeoTrain Corp.
> LDAP/X.500 Consulting and Training.
> http://www.geotrain.com
> 
> At 09:58 29/09/98 -0700, Tim Howes wrote:
> >Yep. Let's not lose sight of our goal here. Our goal is
> >to decide on a mandatory-to-implement non-clear-text-
> >password authentication scheme for LDAP clients and
> >servers, to address the IESG's interoperability
> >concerns with LDAPv3. We will achieve this goal with
> >the minimum acceptable solution.
> >
> >All this talk of other authentication methods and
> >security measures that we might want to make mandatory
> >is fine, but none of it is going to happen until we
> >get job one accomplished. So let's keep focused on
> >job one until it's done, and avoid confusing an already
> >confused discussion.                    -- Tim
> >
> >Chris Newman wrote:
> >>
> >> [don't forget to trim the recipients -- I'm sure minutes@ietf.org isn't
> >>  interested in this conversation]
> >>
> >> On Mon, 28 Sep 1998, Jonathan Trostle wrote:
> >> > How about the following for mandatory to implement: Servers must
> implement TLS,
> >> > SASL GSS Kerberos V5, and CRAM-MD5/digest auth. Clients must implement
> one of
> >> > these three protocols.
> >>
> >> This is getting ridiculous.  There's no justification for such a
> >> requirement given how little Kerberos deployment there is after 10? years.
> >> Kerberos has proven to be too difficult to deploy so far.  Microsoft might
> >> change that by adding some things to simplify Kerberos operationally, but
> >> it's certainly premature to promote it so heavily (I say this despite
> >> having written a Kerberos-enabled telnet client).
> >>
> >> Personally, I don't think the stronger authentication technologies need to
> >> be promoted at all by the standard.  The people who _really_ need them
> >> usually have enough money and clout to make sure they happen.
> >>
> >> What needs to be promoted is the baseline mechanism which guarantees
> >> interoperability, and perhaps a clear-text password under encryption
> >> mechanism which provides backward compatibility with arbitrary password
> >> databases.
> >>
> >>                 - Chris
> >
> >
> >