[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
authmeth: EXTERNAL vs. TLS
[Authmeth] says:
> 3.1. Sequencing of the StartTLS Operation
> Note that the precise effects, on a client's authorization identity,
> of establishing TLS on an LDAP connection are described in detail in
> section 3.2.
I don't remember if anyone has replied to this, but:
I still think it has no effect except that it may invalidate the
association. Bind/EXTERNAL has effect, but Bind is not StartTLS.
The same applies to this text, of course:
> 3.2. Effects of TLS on a Client's Authorization Identity
> This section describes the effects on a client's authorization
> identity brought about by establishing TLS on an LDAP connection.
> The default effects are described first, and next the facilities for
> client assertion of authorization identity are discussed including
> error conditions. Finally, the effects of closing the TLS connection
> are described.
Besides, that introductory text is now >60% of the text it introduces,
which is a bit much. I suggest to delete most of this text; maybe even
all of it and just keep a revised header:
3.2. TLS and the Client's Authorization Identity
========
> 10. SASL EXTERNAL Mechanism
> A client may either implicitly request that its LDAP authorization
> identity be derived from its authentication credentials exchanged at
> a lower security layer or it may explicitly provide an authorization
> identity and assert that it be used in combination with those
> authentication credentials. The former is known as an implicit
> assertion, and the latter as an explicit assertion.
>
> 10.1. Implicit Assertion
> 10.2. Explicit Assertion
Where do these terms come from? Are the terms Implicit and Explicit
Assertion specific to EXTERNAL, or maybe authentication through
certificates? In LDAP terms, I don't see any difference between
SASL/EXTERNAL and other mechanisms that allow the authz id to be
specified, so I don't see why they are about EXTERNAL only.
In any case, at least this:
> 10.1. Implicit Assertion
> (...)
> The server will derive the client's authorization identity
> from the authentication identity supplied by the security layer
> (e.g., a public key certificate used during TLS establishment)
> according to local policy. The underlying mechanics of how this is
> accomplished are implementation specific.
is not specific to EXTERNAL.
> 10.3. SASL Authorization Identity
>
> When the EXTERNAL SASL mechanism is being negotiated, if the
> SaslCredentials credentials field is present, it contains an
> authorization identity.
The rest of the paragraph, and section 10.4, belong under SASL and not
under Section 10 (EXTERNAL):
> Other mechanisms define the location of the
> authorization identity in the credentials field. In either case, the
> authorization identity is represented in the authzId form described
> below.
>
> 10.4. SASL Authorization Identity Syntax
========
> A.1. LDAP Association States
> S3 Authenticated SASL EXTERNAL, implicit authorization ID
> Authentication ID = J
> Authorization ID = Y
> S4 Authenticated SASL EXTERNAL, explicit authorization ID Z
> Authentication ID = J
> Authorization ID = Z
S3 and S4 can be merged. In the context of association states, the
difference between 'Y was derived from J' and 'the bind specified Y,
which was allowed by J' does not seem interesting. In both cases, the
interesting point is that we end up with an authentication ID and an
authorization ID, both of which resulted from the last Bind.
Also, now that the TLS identities are gone from the table, I do not
see what is so interesting about SASL/EXTERNAL. It would be more
interesting to distinguish between implicit and explicit assertion
regardless of bind method: Merge states S2 and S3 as well, and merge
actions A4 and A5. Decision D1 ("Are lower-layer credentials
available?") would then be deleted; SASL/EXTERNAL with D1="no" would
just be a case of a failed bind.
For that matter, D2="no" could also just be classified as a failed bind
and deleted, depending on what you want to show with this table.
> A.3. Decisions Used in Making LDAP Association State Changes
> D2 Can lower-layer credentials for Auth ID "K" be mapped to
> asserted AuthZID "L"?
This decision is based on K itself, not on its credentials.
Also the names K and L do not match the state table.
D2 Can Authentication ID "J" be mapped to the asserted
Authorization ID "Z"?
Though you could put '(from lower layers)' after 'ID "J"'.
========
> 3.2.2. Client Assertion of Authorization Identity
> After successfully establishing a TLS session, a client may request
> that its certificate exchanged during the TLS establishment be
> utilized to determine the authorization identity of the LDAP
> association. The client accomplishes this via an LDAP Bind request
> specifying a SASL mechanism of EXTERNAL [SASL] (section 9).
This statement (about SASL/EXTERNAL) is false. [SASL] section 7 says:
the client can make no assumptions as to what
information the server can use in determining client authorization.
E.g., just because TLS was established, doesn't mean that the server
will use the information provided by TLS.
Imagine TLS over IPSec, which I believe also can provide client
certificates - I believe the server may use either of the certificates.
(It has been fixed in Section 10 - SASL EXTERNAL Mechanism, which also
had this mistake).
========
> 3.1.4. Client Certificate
> If the client provides a certificate that can be validated,
> information in the certificate may be used by the server in
> establishing the client's authorization identity by use of the SASL
> external mechanism as discussed in Section 9.
This paragraph looks like it describes a server-initiated action, if one
does not yet know what SASL/EXTERNAL is. It should be rewritten, but
without implying that an EXTERNAL bind requests to use the TLS-provided
credentials; only that the server may make use of it - the current
wording is right in that respect. Sorry, I can't come up with a good
wording now. I'll chew on it.
--
Hallvard