Subject: authmeth: EXTERNAL vs. TLS

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 17:29:54 +0200

[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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 13:16:08 -0700

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

>association.  Bind/EXTERNAL has effect, but Bind is not StartTLS.

Yes, it seems this sentence could simply be deleted.

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

>Where do these terms come from?

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

>Are the terms Implicit and Explicit
>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

>see what is so interesting about SASL/EXTERNAL.

Right, SASL/EXTERNAL is not special. 

>It would be more

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.

>wording now.  I'll chew on it.

Please do.

Kurt