[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
authmeth-10 comments
I have included the few remaining outstanding Authmeth comments from my
previous messages.
What is an active-intermediary attack (sections 3.1.6, 10, 14.1)? It is
not defined in RFC 2828 (Internet Security Glossary). From the context
it seems to be a man-in-the-middle attack (sections 3.1.5, 13, 13.1, 14)
- if so, please use that term instead. Otherwise, please define it or
add a reference to something which defines it.
> 1. Introduction
> Threats (1), (4), (5) and (6) are due to hostile clients. Threats
> (2), (3) and (7) are due to hostile agents on the path between
> client and server or hostile agents posing as a server, e.g. IP
> spoofing.
Kurt has suggested to also distinguish between between active and
passive attacks. ('Re: authmeth-09 comments', 06 Jan 2004.)
> LDAP offers the following security mechanisms:
> (...)
After this list, I suggest to add:
LDAP may also be protected by means outside the LDAP protocol,
e.g. with IP-level security [SecArch].
> 3.1.1. Start TLS Request
> If the client did not establish a TLS connection before sending some
> other request, and the server requires the client to establish a TLS
> connection before performing that request, the server MUST reject
> that request by sending a resultCode of confidentialityRequired or
> strongAuthRequired.
Not strongAuthRequired. That requests authentication (Bind), not
StartTLS.
Though I'm not sure how strongAuthRequired is used.
May the server send strongAuthRequired in response to an unprotected
Simple Bind, indicating it will accept e.g. a DIGEST-MD5 Bind?
That's still not what the above paragraph is saying, though.
> 3.2.1. TLS Connection Establishment Effects
>
> The decision to keep or invalidate the established authentication
> and authorization identities in place after
I prefer:
The decision to keep or invalidate (see section 12) the established
association after
Since an 'invalidate association' is defined, but the effect of
invalidated identities is not. I.e. could a search still succeed if it
was not affected by access controls that checked the client's
authorization?
Come to think of it, someone might want to implement the equivalent
of 'invalidated associations' which worked just that way, but if we
are to address that, it should be addressed in section 12.
Also, do the same change in 3.2.3 (TLS Connection Closure Effects),
except the reference to section 12 need not be repeated.
> TLS closure is a matter
> of local server policy.
s/closure/connection establishment/.
> 3.2.2. Client Assertion of Authorization Identity
>
> After successfully establishing a TLS session, a client may request
> that its credentials exchanged during the TLS establishment be
> utilized to authenticate the LDAP association and thus determine the
> client's authorization status.
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.
The same mistake occurs in Section 9 (SASL EXTERNAL Mechanism).
Also, 'authenticate the LDAP association' sounds strange. An
association is already authenticated (or is anonymous or invalidated).
Finally, if you preserve mention of TLS credentials, I suggest
s/(client) credentials/(client) certificate/, which I think it what this
statement is talking about and is more informative.
> LDAP server implementations SHOULD support this
> authentication method.
This statement belongs in Section 9 (SASL EXTERNAL Mechanism),
or in Kurt's new section "2. Implementation Requirements"
from message "authmeth review notes [long]" of 27 Feb 2004:
<http://www.openldap.org/lists/ietf-ldapbis/200402/msg00083.html>.
> 5. Anonymous LDAP Association on Unbound Connections
>
> Prior to the successful completion of a Bind operation and during
> any subsequent authentication exchange, the session has an anonymous
> LDAP association.
Also after a failed Bind operation.
> 6. Anonymous Authentication
> An LDAP client may explicitly establish an anonymous association by
> sending a Bind Request with the simple authentication choice
> containing a value--construed as the password--of zero length.
s/containing.../and an zero-length password/.
The original text makes little sense. Either
- a zero length value means it is _not_ a password,
- or the Simple auth value _is_ a password (not just construed as one)
but a zero length password gives the operation a special meaning.
As you see I prefer the latter, since it is common to talk of empty
passwords for anonymous authentication. This very paragraph even does
that a bit later.
> 7. Simple Authentication
> LDAP implementations SHOULD NOT support authentication with the
> "simple" authentication choice unless the data on the connection is
> protected using TLS or other data confidentiality and data integrity
> protection.
Replace 'the "simple" authentication choice' with
'cleartext passwords, such as Simple Authentication,'.
> 8. SASL Authentication Profile
I think this section should be renamed 'SASL Protocol Profile', so
readers of [SASL] can _find_ the 'protocol profile' by searching the
authmeth document for that phrase.
According to [SASL]-04, the LDAP protocol profile MUST specify that
LDAP supports "multiple authentications".
> 9. SASL EXTERNAL Mechanism
> A client can use the EXTERNAL SASL [SASL] mechanism to request the
> LDAP server to make use of security credentials exchanged by a lower
> security layer
The text should specify what the credentials are used _for_:
s/make use of/fetch (or derive?) the authentication identity from/.
I also suggest s/use/Bind with/, as a brief reminder that EXTERNAL is
used via the Bind operation.
> A client may either implicitly request that its LDAP authorization
> identity be derived from a lower layer
s/from a lower layer/from the authentication identity/.
It is only the authentication identity which was derived from a lower
layer. (The same mistake appears in Section A.3; commented later.)
> 9.1. Implicit Assertion
> 9.2. Explicit Assertion
These do not apply just to SASL/EXTERNAL, but to Bind in general (though
not all Bind methods/mechanisms support client-specified authentication
ID and/or explicit assertion). Replace references to the identity
fetched from TLS with the authentication identity.
Well, that's assuming "implicit/explicit assertion" general terms, and
not just SASL/EXTERNAL terms or SASL terms. I don't know; I never heard
them before. Where do the come from?
But most of the info in these sections is general to Bind in any case.
> 9.4 Authorization Identity Syntax
> The dnAuthzId choice allows clients to assert authorization
> identities in the form of a distinguished name to be matched in
> accordance with the distinguishedNameMatch matching rule [Syntaxes].
Maybe s/allows clients to/is used to/ - that is, it is _only_ used for
this purpose, not for other forms of authorization identities?
> The value contained
> within a uAuthzId MUST be prepared using [SASLPrep] before being
> compared octet-wise. The format of userid is defined as only a
> sequence of [UTF-8] encoded [Unicode] characters, and further
> interpretation is subject to prior agreement between the client and
> server.
This is inconsistent. If userid can be 'interpreted', then that
interpretation can e.g. convert it to lowercase before it is compared,
so it isn't necessarily compared octet-wise as stated at first.
Or is something else meant by 'further interpretation'?
Also, 'compared octet-wise' with what? I can think of two meanings:
- during bind, compare with the list of authorization IDs which
the authentication ID may authorize,
- during non-bind, compare with the authorization IDs listed in the
access controls which apply to that operation.
> 12. Invalidated Associations
> The association remains
> invalidated until the next successful bind request.
s/successful//. A failed bind establishes a new association too.
Also, I suggest to add:
Note that the server may in any case choose to return
strongAuthRequired at nearly any time. The above behavior
is spelled out because it often makes sense and is simple for
users [or "simple for clients"?] to understand.
> 13. TLS Ciphersuites
> Servers SHOULD NOT support
> weaker ciphersuites unless other data integrity and
> confidentiality protection (such as a SASL security layer) is
> in place
I don't know if this is worth worrying about, but: What should the
implementation do if one establishes a SASL security layer, then starts
TLS with such a 'weaker [TLS] ciphersuite' (e.g. a null cipher), and
then Binds to remove the SASL layer? Should the Bind fail, leaving the
SASL layer intact? Or should the server perform graceful TLS closure?
That would be a bit backwards...
Also, add '.' at the end of the paragraph.
> 14. Security Considerations
This paragraph:
> The use of cleartext passwords and other unprotected authentication
> credentials is strongly discouraged over open networks when the
> underlying transport service cannot guarantee confidentiality.
...and this one in Section 14.1 (Start TLS Security Considerations):
> Client and server implementors SHOULD take measures to ensure proper
> protection of credentials and other confidential data where such
> measures are not otherwise provided by the TLS implementation.
...can be merged.
> Operational experience shows that clients can (and frequently do)
> misuse unauthenticated bind (see section 5.1). (..) Clients that
> use the results from a simple bind operation to make authorization
> decisions should actively detect unauthenticated bind requests (via
> the empty password value) and react appropriately.
Suggest to replace the last two lines with something more specific:
decisions should ensure that the supplied password is not empty.
> 14.1. Start TLS Security Considerations
> The goals of using the TLS protocol with LDAP are to ensure
> connection confidentiality and integrity, and to optionally provide
> for authentication. [TLS] expressly provides these capabilities.
...the latter in combination with SASL/EXTERNAL, but only if the EXTERNAL
implementation chooses to make use of the TLS credentials. It could
make use of some other security service.
This paragraph doesn't look like a security consideration to me, though.
> The use of TLS does not provide or ensure
> for confidentiality and/or non-repudiation of the data housed by an
> LDAP-based directory server. Nor does it secure the data from
> inspection by the server administrators.
In message 'Re: authmeth: missing protection' at 16 Feb 2004,
<http://www.OpenLDAP.org/lists/ietf-ldapbis/200402/msg00040.html>,
you suggested that this refers to accessing the data through other means
than the protocol. If so, that is not clear from the text. I suggest
this paragraph is replaced with:
LDAP itself provides no security or protection from accessing or
updating the directory by other means than through the LDAP
protocol, e.g. from inspection by database administrators.
Now the paragraph should be moved to section 14, since the modified text
is no longer about TLS.
> Client and server implementors SHOULD take measures to ensure proper
> protection of credentials and other confidential data where such
> measures are not otherwise provided by the TLS implementation.
TLS or other protection mechanism. So move it out of the TLS security
consideration to the general consideration.
> Server implementors SHOULD allow for server administrators to elect
> whether and when connection confidentiality and/or integrity is
> required, as well as elect whether and when client authentication
> via TLS is required.
By client authentication via TLS, do you mean to demand a client
certificate which the server can certify, or to demand SASL/EXTERNAL
afterwards?
> Additional security considerations relating to the EXTERNAL
> mechanism to negotiate TLS can be found in [SASL] and [TLS].
Since this consideration exists, maybe there should be a similar
consideration in section 14 for [SASL], [DIGEST-MD5], [SASLPrep],
[StringPrep], and [UTF-8].
> Appendix A. LDAP Association State Transition Tables
Wow, this table has shrunk a lot more than I dared hope for.
Even so, now that it has done so, it can shrink even more:
> 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
> Authentication ID = J
> Authorization ID = Z
S3 and S4 can be merged. In the context of associatin 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.2. Actions that Affect LDAP Association State
> A2 Client successfully performs anonymous simple bind
> A3 Client successfully performs unauthenticated simple bind
I would merge these, as well as mechanisms like SASL/ANONYMOUS:
A2 Client successfully binds to produce an anonymous
association, e.g. with anonymous or unauthenticated
Simple bind, or with the ANONYMOUS SASL mechanism.
> A7 Client abandons a bind operation, and server processes the
> abandon
> A8 Client abandons a bind operation, and server does not process
> the abandon
Bind operations can no longer be abandoned. See [Protocol] 4.11.
> 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"?
> A.4. LDAP Association State Transition Table
> Any A10 no Section 4.2.1
> change
> Any A11 S1 Section 4.2.3
A10 and A11 should be "either no change or S0", where state S0 is the
state for an invalidated association.
Or one could say that the authorization and authentication IDs are
actually unchanged, but they are unavailable when the association is
invalidated.
------------------------------------------------------------------------
Editorial comments:
References to [Protocol] section 4.13.* should be 4.14.* (StartTLS).
> 3.1.1. Start TLS Request
> If the client did not establish a TLS connection before sending some
> other request, and the server requires the client to establish a TLS
s/other//. We are not really talking about 'other than Start TLS' here,
so there is no operation to be 'other' than. Sorry, my fault, from an
incomplete change I suggested previously.
> 3.1.4. Discovery of Resultant Security Level
> Ascertaining the TLS connection's
> security level is implementation dependent
s/Ascertaining/How to ascertain/.
I suggest to strike the following; it is obvious from the above:
> and accomplished by
> communicating with one's respective local TLS implementation.
> If the client or server decides that the level of authentication or
> security is not high enough for it to continue, it SHOULD gracefully
> close the TLS connection immediately after the TLS negotiation has
> completed (see [Protocol] section 4.13.3.1 and section 3.2.3 below).
In LDAP context, "authentication" is the Bind operation. Please use
another term, or clarify that this sentence refers to what [TLS] means
with "authentication".
> If the client decides to continue, it may gracefully close the TLS
> connection and attempt to Start TLS again, it may send an unbind
> request, or it may send any other LDAP request.
This sentence seems redundant to me. But if you keep it, reword to:
"If the client decides to continue after TLS closure, it may
attempt to Start TLS (...)"
since it might have been the server which initiated TLS closure, so it
is wrong to talk about the _client_ doing graceful TLS closure.
> 3.1.5. Server Identity Check
> - The client MUST use the server provided by the user (or other
s/server/server name/, I think.
> trusted entity) as the value to compare against the server name
> as expressed in the server's certificate.
> 6. Anonymous Authentication
>
> Directory operations that modify entries or access protected
> attributes or entries generally require client authentication.
> Clients that do not intend to perform any of these operations
> typically use anonymous authentication.
I agree with Kurt that this should be deleted ('authmeth review notes
[long]', 27 Feb 2004), buf if it is kept:
s/anonymous authentication/anonymous associations/. The client might
not have authenticated (anonymously).
> 6. Anonymous Authentication
> clients may
> need to actively detect situations where they would
unintentionally
> make an
> unauthenticated bind request.
> 7. Simple Authentication
> An LDAP client may establish an LDAP association by sending a Bind
> Request with a name value consisting of an
...non-empty... (and s/an/a/ above)
> LDAP distinguished name
> [LDAPDN] and specifying the simple authentication choice with a
...non-empty...
> password value.
> The simple authentication choice is not suitable for authentication
> in environments where there is no network or transport layer
> confidentiality.
s/The simple authentication choice/Simple Authentication/. 'The simple
authentication choice' includes anonymous auth, which is OK without TLS.
'Simple Authentication' does not.
> 8.2. SASL Authentication Initiation and Protocol Exchange
> To the encapsulating protocol, these challenges and responses are
s/encapsulating protocol/LDAP protocol/ or s/protocol/LDAP protocol/.
I think the former is actually clearer, because it is simpler.
> 8.3. Octet Where Negotiated Security Mechanisms Take Effect
> Once a SASL security layer providing integrity or confidentiality
> services takes effect, the layer remains in effect until a new layer
> is installed (i.e. at the first octet following the final
> BindResponse of the bind operation that caused the new layer to take
> effect).
Suggest to add:
Thus, an established SASL security layer is not affected by a
failed or non-SASL Bind.
> 8.4. Determination of Supported SASL Mechanisms
> reading the 'supportedSASLMechanisms ' attribute from the root DSE
^^^
Remove a space.
> 9. SASL EXTERNAL Mechanism
Suggest s/Mechanism/Authentication Mechanism/ here and in the name
of section 10 (SASL DIGEST-MD5 Mechanism).
> 9.4 Authorization Identity Syntax
I suggest "SASL" in front of the section name.
> In order to support additional specific authorization identity
> forms, future updates to this specification may add new choices
> supporting other forms may be added to the authzId production.
s/may be added to/of the/.
> 10. SASL DIGEST-MD5 Mechanism
> LDAP servers that implement any authentication method or mechanism
> other than simple anonymous bind MUST implement the SASL
> DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
> authentication with protection against passive eavesdropping attacks
> but does not provide protection against active intermediary attacks.
> DIGEST-MD5 also provides data integrity and data confidentiality
> capabilities.
There is one blank line too much here.
> 11. General Requirements for Password-based Authentication
The section name should be changed to cover non-bind operations, unless
references to non-bind operations are removed from this section as
discussed in the 'authmeth: passwords in the clear' thread.
> To mitigate the security risks associated with the use of passwords,
> a server implementation
which supports other authentication methods than simple anonymous bind
> MUST implement a configuration that at the
> time of authentication or password modification, requires:
> 12. Invalidated Associations
> The server may, at any time, invalidate the association, e.g. if the
> established security association between the client and server has
> unexpectedly failed or been compromised.
Too many commas. Remove the first two.
> 13. TLS Ciphersuites
> A client or server that supports TLS
s/A client or server/An implementation/?
> 14.1. Start TLS Security Considerations
> Additionally, an active-
> intermediary attacker can remove the Start TLS extended operation
> from the supported attribute of the root DSE.
s/supported/supportedExtension/.
> Therefore, both
> parties SHOULD independently ascertain and consent to the security
> level achieved once TLS is established
s/Therefore//. This is independent from supportedExtension, which just
advices about whether or not StartTLS is available at all, not about the
resulting security level if StartTLS _is_ used.
> A.2. Actions that Affect LDAP Association State
> A5 Client Binds SASL EXTERNAL with implicit assertion of
> authorization ID (section 3.3.6.1)]. The current
> authentication ID maps to authorization ID = Y.
> A6 Client Binds SASL EXTERNAL with explicit assertion of
> authorization ID = Z (section 3.3.6.2)]
Wrong section numbers.
> A.4. LDAP Association State Transition Table
> Current Next
> State Action State Comment
> ------- ------- ----- ---------------------------------------
That first column with only "Any" values is cute, but not really
necessary anymore, and it does reduce the space for the rest of the
columns.
The [authmeth] section numbers in this table are wrong.
> G.8. Changes for draft-ldap-bis-authmeth-09
> - Used non-quoted names for all SAL mechanisms
s/SAL/SASL/.
> - Reworded sentence beginning, "It is also desireable to allow
> authentication methods to carry identities based on existingù
s/ù//. 8-bit character.
> H.38 Effect of Start TLS on authentication state
> on editorÆs perception of WG consensus gaged by conversations at
s/Æ/'/. 8-bit character.
--
Hallvard