[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: draft minutes from Chicago meeting
I like the idea of separating clients into the general user category and
the "administrative" user category, with associated additional
capabilities. I appreciate the efforts in designing and deploying a
basic functional client, which in most environments (mine included) will
be the largest installed base. And, I look forward to seeing the
solution set for the Admin user evolve.
Sandi
>----------
>From: Erik Skovgaard[SMTP:eskovgaard@geotrain.com]
>Sent: Wednesday, September 30, 1998 8:39 PM
>To: Tim Howes
>Cc: IETF LDAP Extensions WG
>Subject: 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
>>> >
>>> >
>>> >
>>
>>
>>
>
>