[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft minutes from Chicago meeting
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
>
>
>