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

Re: Authmeth/DIGEST-MD5



RL 'Bob' Morgan wrote:
> 
> > Let's say a server is hosting two trees "o=left" and "o=right"
> > and that bind target entries contain an attribute that holds
> > a hashed user:realm:password where the realm is specific to
> > the tree: "left" and "right" respectively).
> >
> > A server can not provide both realms to the client as only
> > the realm to which the person's stored hash contains would
> > produce a successful authentication.  It must provide the
> > realm that embedded in the stored hash within the target
> > entry.
> >
> > If the target (DN) is not provided up front, then you disallow
> > hosting of independent DITS where storing of clear text
> > passwords is forbidden.
> 
> I must be missing something.  In your example, the server, in its
> digest-challenge, would offer two realm directives, realm=left and
> realm=right.  An interactive client would pop up a menu so the user could
> choose which of the two to respond to.  The digest-response sent by the
> client would contain a single realm directive indicating which was
> selected, along with the response-value calculated as described in section
> 2.1.2.1 of the draft.  The server receives this, and uses the info in the
> tree indicated by the selected realm to do the check on the
> response-value.  If the client chooses the wrong realm, then
> authentication will fail, as it should.  Is there something wrong with
> this picture?

Yes, you are thinking in terms of an enterprise... I am thinking in terms
of a commerical hosting service.  If the services is hosting 1000s independent
DITs than 1000 or more realms would have to be sent to client.  Besides being a
long list, the server administrator may not want to expose all realms to all
users (because maybe he doen't want left to know about right and vica versa).
Without a target, you force the service provide to use multiple IP:port pairs
for each independent DIT they host.  Yuk!