Re: authmeth: EXTERNAL vs. TLS

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I generally concur with Hallvard here.  Below are some
additional comments I felt appropriate to inject into
this thread.

At 08:29 AM 9/27/2004, Hallvard B Furuseth wrote:
>[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.

Yes, it seems this sentence could simply be deleted.


>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:

I suggest deleting all of this.... and adding a more general
discussion (in Security Considerations) about identity/security
state management issues that implementors need to consider.

>  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?

 From the above paragraph (which, IIRC, came from RFC 2830).

>Are the terms Implicit and Explicit
>Assertion specific to EXTERNAL, or maybe authentication through
>certificates?

The general discussion is not specific to EXTERNAL, but
the terms used are specific to RFC 2830.  It would be
better if the SASL identity discussion was separate from
any particular mechanism discussion, and that identity
discussion used terms consistent with RFC2222bis.

Also, I note, an application protocols handling of SASL
identities should be part of its SASL profile.  So,
it seems most of 10 belongs as a subsection of 9.
An appropriate subsection heading might be
"SASL Identities".

Then any LDAP specific discussion of EXTERNAL could be
made placed in a section (below the DIGEST-MD5 section).
It should be a very short section as I don't there is
much we should say here.

>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.

Right, SASL/EXTERNAL is not special. 

>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).

Correct, SASL/EXTERNAL does not request the "certificate
exchanged during TLS establishment be utilized to determine
the authorization identity" but only requests that the
server use external information to establish an appropriate
authorization identity for the client.


>========
>
>> 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.

Please do.

Kurt