[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Authmeth/DIGEST-MD5
David
(Apologies for delayed response; was away from email)
>The text below uses authentication and authorisation identity almost
>interchangeably, and I believe this is wrong. A client first
>authenticates and if successful is then authorised. Does anyone
>disagree with this?
At the grossest level, no. A more detailed view would be:
The client identifies itself
The server/acceptor challenges the client to authenticate its
identification
The client responds to the challenge, authenticating the identification
The server/acceptor determines the client's privileges, using the client's
authenticated identification as a key to retrieve or
synthesize said privileges
The server/acceptor authoriz(s)es the client by comparing the client's
privileges
against an authorization policy rule for the client's access
request.
Notice I've carefully avoided the use of the term "identity" here; it causes
way
too many problems, including semantics, privacy policy, etc...., to be of real
use.
The client does have an "identification" which it authenticates, and it does
have
a set of privilege attributes (not necessarily including any "identifying"
information)
which are used to authorize its access to resources. Hence I'd rewrite your
summary
as follows (my amendments are upcased):
>A client binds as a DN, and presents an
>authentication token to prove THE AUTHENTICITY OF HIS CLAIM TO BE IDENTIFIED
BY THIS DN.
>There then has to be some
>internal mapping in the server between the AUTHENTICATED DN
>and SOME authorisation PRIVILEGE ATTRIBUTES. This mapping is beyond the scope
of
>the LDAP work, but in the simplest case is null. (In other cases it will
>be to map a LDAP DN into AN ACCESS-ID as present in an ACI.)
--bob
Bob Blakley (blakley@dascom.com)
Chief Scientist, Dascom
-----Original Message-----
From: David Chadwick <d.w.chadwick@salford.ac.uk>
To: RL 'Bob' Morgan <rlmorgan@cac.washington.edu>; ietf-ldapext@netscape.com
<ietf-ldapext@netscape.com>
Date: Thursday, July 22, 1999 6:57 PM
Subject: Re: Authmeth/DIGEST-MD5
Bob said:
> A client binds as some authorization identity so as to exercise the
> privileges associated with that identity. The client asserts an
> identity that it wants to use via any or all of:
>
Can I clarify my understanding of this please.
A client binds as an authentication identity, and presents an
authentication token to prove his identity. There then has to be some
internal mapping in the server between the authenticated identity
and the authorisation identity. This mapping is beyond the scope of
the LDAP work, but in the simplest case is null. (In other cases it will
be to map a LDAPDN into a username as present in an ACI.)
The text below uses authentication and authorisation identity almost
interchangeably, and I believe this is wrong. A client first
authenticates and if successful is then authorised. Does anyone
disagree with this?
David
> * the Bind Request name field, or
>
> * the identity used in the authentication credentials it supplies via
> the SASL mechanism it uses, if any (in Digest,
> draft-leach-digest-sasl-03.txt, this is the "username-value" in the
> digest-response structure in section 2.1.2), or
>
> * the authorization id field in the SASL mechanism (in Digest, this
> is the "authzid-value" in digest-response); not all SASL mechanisms
> support this field.
>
> The server is free to use any of this info however it wants as part of
> making its access-control decisions; it can use other info too such as the
> request's source network address, time of day, load, etc (these are called
> Access Control Factors in section 5.2 of authmeth). For the sake of
> simplicity we'd expect a reasonable server to use the three fields above
> to determine a single client identity (the authorization identity, in
> authmeth terms) which it associates with the bound connection. Further it
> would be useful to specify how the server SHOULD do this for each of the
> several authentication mechanisms, which is, I think, what your questions
> are about regarding Digest.
>
> A central question is whether the authorization identity asserted by
> the client MUST take the form of a DN, and hence be a directory object on
> some DSA somewhere. This was the subject of much debate as we were
> developing the authmeth document. The conclusion that we (the ldapext
> working group) came to at that time (about a year ago) was that the
> authorization identity does NOT have to be a DN, that it can be whatever
> sort of identity the client and server agree on to express their security
> principals. This decision is reflected in the text of authmeth, in
> particular in section 11, which describes both DN and non-DN syntax for
> the authorization id field.
>
> This decision permits LDAP-based directory services to be integrated, when
> desired, with existing authentication infrastructures such as Kerberos,
> and allows the existence of LDAP servers that don't happen to maintain or
> have access to user entries. The alternative view, that every LDAP
> deployment must implement an authentication infrastructure using
> DN-labelled principals in addition to managing whatever info it has been
> set up to manage, IMHO unnecessarily restricts the applicability of the
> protocol.
>
> Note that if a DSA chooses to use DNs to represent client entities for
> access control purposes, it can still allow clients to bind using other
> forms of authorization ID by having an internal mapping between these
> other forms and a set of DNs. In fact even DSAs that accept DNs supplied,
> eg, in client certs via TLS, have found it necessary to provide a mapping
> function between the client-supplied DNs, which are likely to come from
> all over the place, to the more controlled space of DNs that the DSA uses
> internally (as mentioned in authmeth, section 9.1). I think that for some
> common non-DN-based authentication methods (Kerberos in particular) it
> would be useful to standardize how this mapping might be done, but that's
> a topic for another rant.
>
> So, given all this, the question remains as to how servers SHOULD
> handle the various pieces of authentication/authorization data in the
> various authentication mechanisms, and hence what clients should put into
> them.
>
> Regarding the Bind Request name, RFC 2251, section 4.2, says:
>
> - name: The name of the directory object that the client wishes to
> bind as. This field may take on a null value (a zero length
> string) for the purposes of anonymous binds, when authentication has
> been performed at a lower layer, or when using SASL credentials with
> a mechanism that includes the LDAPDN in the credentials.
>
> This permits a null name if the entity-to-bind-as is conveyed via the SASL
> mechanism, though the implication is that it has to be a DN in any case.
> But as I mention above, in fact a DN is not required; any form of user
> name expressed by the client via SASL is acceptable from a protocol point
> of view. Since any SASL mechanism will include transmission of
> credentials including user name, this means that the "name" field is only
> required in the Bind Request for the "simple" option.
>
> In the case of a SASL mechanism that supports reasonably strong
> authentication and an authorization ID field that is protected from
> tampering (eg, GSS/Kerberos and Digest), the name field is superfluous at
> best. In fact it is worse, because unless the datastream is protected by
> TLS or IPSec or similar, it can be modified by an active attacker. So:
> the Bind Request name field SHOULD be null when used with these
> mechanisms, and SHOULD (or MUST?) be ignored by the server. If it is
> non-null, the server might find it useful as a hint for doing the mapping
> I mention above, but should be sure not to rely on it as part of its
> access control decision.
>
> In the case of SASL EXTERNAL, when used with TLS or IPSec, the client
> requests an authorization ID via the SaslCredentials sequence
> (draft-ietf-ldapext-ldapv3-tls-05.txt, section 7.1.2.2); the Bind Request
> name field is not used. I suggest that the client SHOULD transmit it as
> null; and the server SHOULD (or MUST?) ignore it. This clarification
> should be made to the LDAPv3-TLS document; at this point, probably not
> until it goes to Draft Standard.
>
> You ask if the Bind Request name field DN should have a role in
> Digest in helping the client and server agree on what realm to
> authenticate in. draft-leach-digest-sasl-03.txt says that the initial
> server challenge can contain multiple realm directives; the client chooses
> one to respond about. There would be a small optimization, in the
> particular case where the server deals with multiple realms and the client
> knows ahead of time which it wants, for the client to put this into the
> Bind Request name field. It's hard to know whether this will be a common
> case or not; it seems unlikely to me that it would be worth optimizing.
> In any case the client can still authenticate successfully if it uses a
> null name in its Bind Request and chooses one of the realms the server
> offers.
>
> > What should the value of the DN field be for second request?
> >
> > If value differs from initial request, what should the server's
> > response be?
>
> If by "second request" you mean subsequent authentication as described in
> section 2.2 of digest-sasl-03, then I suggest that in this case the Bind
> Request name field be null when sent by the client and ignored by the
> server. Subsequent authentication reuses all the info (username, realm,
> etc) from the initial authentication, so the name field can't add anything
> useful.
>
> - RL "Bob"
>
>
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:+1 (512) 458-4037 x 5012
TEL;WORK;FAX:+1 (512) 458-2377
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Plaza Balcones=0D=0A5515 Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Plaza Balcones=0D=0A5515 Balcones Drive=0D=0AAustin, TX 78731=0D=0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:blakley@dascom.com
REV:19990802T023955Z
END:VCARD