RE: http-digest authentication comments...

[Bruce Greenblatt <bruceg@innetix.com>]

At 02:05 PM 11/19/98 -0800, Paul Leach wrote:
>
>
>> -----Original Message-----
>> From: Bruce Greenblatt [mailto:bruceg@innetix.com]
>> Sent: Thursday, November 19, 1998 8:45 AM
>> To: chris.newman@innosoft.com; Paul Leach
>> Cc: ietf-ldapext@netscape.com
>> Subject: http-digest authentication comments...
>> 
>> 
>> I've (finally) read the draft 
>> (draft-leach-digest-sasl-00.txt) that was
>> submitted back in September.  I think that it is the latest 
>> one out there.
>> I've got some minor comments.  
>> 
>> In section 2.1.1, the BNF doesn't appear to define what a token is.
>
>Same as in HTTP.
>

But, it doesn't say what a token is in the http digest draft either.  Is it
just binary data?
>> 
>> In section 2.1.2, why would the client send back the server's 
>> nonce in its
>> digest response?  Is the serv-type value to be used in LDAP "ldap",
>> "ldapv3", .... or what?
>
>To be defined in ldap SASL profile. Mark Wahl has done so.
>
>> 
>> In section 2.1.3, first paragraph, third sentence, shouldn't 
>> the server
>> save the cnonce provided by the client?
>
>No -- when a subsequent authentication is done, the client will provide a
>cnonce.
>
>> 
>> If I understand things right, the client's response created in Step 2,
>> could also be a request for the server to authenticate itself 
>> to the client
>> in Step 3.  This is one reason why it might include a cnonce in its
>> response.  Can you include more details on this option?
>
>I don't understand this question.
>

As an LDAP client, I want to authenticate the LDAP server.  So, I send the
server a challenge, and it has to responde appropriately.  There doesn't
seem to be any obvious reason that http-digest would not support two way
authentication.  Normally, the client would authenticate the server prior
to authenticating itself back to the server.

Bruce

>Paul
>
>
================================================
Bruce Greenblatt              bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================

Disposition-notification-to: k.richardson@man05t1.wins.icl.co.uk
Received: from threadgill.austin.innosoft.com ([207.8.108.5])
 by INNOSOFT.COM (PMDF V5.2-29 #30494)
 with ESMTP id <01J4H418IG8M94FNXN@INNOSOFT.COM> for
 ldapext-archive@pipe.thor.innosoft.com; Sun, 22 Nov 1998 12:57:35 PST
Received: from glacier.mcom.com (h-205-217-233-39.netscape.com)
 by austin.innosoft.com (PMDF V5.1-10 #13579)
 with ESMTP id <0F2U00E0XCVXRJ@austin.innosoft.com> for
 ldapext-archive@pipe.thor.innosoft.com; Sun, 22 Nov 1998 14:57:34 -0600 (CST)
Received: (from list@localhost) by glacier.mcom.com (8.7.3/8.7.3)
 id MAA28126; Sun, 22 Nov 1998 12:42:52 -0800 (PST)
Resent-date: Sun, 22 Nov 1998 12:42:52 -0800 (PST)
Date: Sun, 22 Nov 1998 20:38:00 +0000
Resent-from: ietf-ldapext@netscape.com
From: Richardson K <k.richardson@man05t1.wins.icl.co.uk>
Subject: Re: Clarification of RootDSE information retriev al required
Resent-sender: ietf-ldapext-request@netscape.com
To: ietf-ldapext@netscape.com
Resent-message-id: <"SDWVT3.0.Pt6.AT7Ms"@glacier>
Message-id: <JA8AAAAAAKJbCQABYQACiMOLwb9U@man05t1.wg.icl.co.uk>
MIME-version: 1.0
X-Mailer: TeamWARE Connector for MIME
Content-type: text/plain; charset=iso-8859-1
Content-disposition: inline
Content-transfer-encoding: quoted-printable
Precedence: list
X-Loop: ietf-ldapext@netscape.com
Envelope-ID: JA8AAAAAAKJbCQABYQACiMOLwb9U@man05t1.wg.icl.co.uk
X-Map-MIXER-Originators: false
X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/1091

>... I would like to lobby for a change to the RFCs to relax this
>for the root DSE.  I think it is useful and not harmful to return all
>root DSE attributes even when they are not named explicitly.  This makes
>it easier for client implementors to discover what server meta
>information is available, is easier to debug, and so on.  In the
>interest of full and fair disclosure, I will admit that Netscape's LDAP
>server implementation already behaves this way.

Hmm... I generally agree with this proposal but it raises a fundamental
question about the IETF 'standards' process. Specifically, how can a
change as proposed above=20actually be applied to an IETF standard RFC=3F

In the LDAPv3 case we now have a set of published 'standard' RFCs
and an increasing number of products available which claim to support
them. However, no standard will be perfect first time through, i.e.
errors or inconsistencies will occur (such as the LDAPv3 printable
string character set being different from that defined by ISO/ITU-T)
or operational experience will show changes may be desirable (as in
the above example).

Now as I understand it (and I'm happy to be corrected) an RFC cannot
be changed but only superseded by a further RFC - presumably for
a 'standard' RFC this means going through a complete IETF working
group consensus/IESG approval cycle again=3F

If this is the case then IMHO we need some sort of fast-track
process to identify, agree and document definitive changes which
are to apply to a base IETF standard such as LDAPv3 (call it an
Implementor's Guide=3F) - new RFCs should only be necessary to cover
major changes, e.g. introduction of LDAPv4.

Without such a process it is going to become increasingly difficult
to achieve the IETF aim (and customer requirement) of full product
interoperability - as the above example shows, different products
are already implementing the base IETF LDAPv3 'standard' differently.
This situation will only be exacerbated as further, more complex
standards such as LDAPv3 access control and multi-master replication
are published.

I appreciate this comment goes beyond the scope of the LDAPext group
only - is the IESG looking at ways to expedite the maintenance of
IETF standards=3F

Keith Richardson,
ICL, Manchester,=20UK