[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft minutes from Chicago meeting
Tim,
Well, don't worry, you won't get me to suggest Kerberos :-) But clearly we
need some form of stronger authentication method.
However, my large directory problem is how I make a mandatory solution
scale across multiple servers from different vendors operated by different
organizations. That is my real requirement and providing a minimal solution
to satisfy the IESG's interoperability issue is not going to make me happy.
It seems to me that we are stuck between two fundamental different
requirements and I was merely trying to identify them clearly. The various
LDAP discussion groups get struck on the same issue all the time.
If we can solve the problem for both environments, that's great. If not,
we should at least make it clear what we are doing.
I think some of the suggestions re. dividing the problem into one for the
server and one for the client were good. Perhaps we should consider
defining a minimal client (which some people seem to desire) and a full
client that can be used in a large-scale environment? Would this progress
the discussion?
We need to move forward on this.
Cheers, ....Erik.
------------------------------------
Erik Skovgaard
GeoTrain Corp
LDAP/X.500 Consulting and Training
http://www.geotrain.com
At 13:46 30/09/98 -0700, Tim Howes wrote:
>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
>> >
>> >
>> >
>
>
>