[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
authmeth-12 review notes
Authmeth-12 review notes follow. I'm splitting some subjects out to
separate threads. A number of the issues are copied (and sometimes
modified a bit) from earlier review notes which as far as I can remember
have not received responses; I don't know if they have been forgotten or
rejected. In the latter case, I'd like to know that, and except for
minor matters why. Or if I'm the one who has forgotten what happened
with some of them, feel free to jump on me.
> 1. Introduction
> LDAP offers the following security mechanisms:
> (3) Data integrity protection by means of TLS or SASL mechanisms
> with security layers that provide data integrity protection,
>
> (4) Data confidentiality protection by means of the TLS protocol or
> SASL mechanisms that provide data confidentiality protection,
These seem a bit redundant. How about
(3) Data integrity protection by means of security layers in TLS or
SASL mechanisms,
(4) Data confidentiality protection which the TLS protocol and
SASL mechanisms can provide,
Except, the rest of the draft says just "confidentiality protection",
not "data confidentiality protection".
> It seems clear that allowing implementations, faced with the above
> requirements, to simply pick and choose among the possible
> alternatives is not a strategy that is likely to lead to
> interoperability. In the absence of mandates, clients will be
> written that do not support any security function supported by the
> server, or worse, they will support only clear text passwords that
> provide inadequate security for most circumstances.
Implementations have had these choices for a while now. Can we replace
"It seems clear" ... "[not] likely to lead to interoperability" ...
"clients will be written" with statements that this DID happen?
The end of the next paragraph also gives me a vague "we are working on
this"-feeling rather than "we have done this":
> it is desirable to ensure secure interopability
> by indentifying a mandatory-to-implement mechanism for establishing
> transport-layer security services.
The start of the following sentence is not right; there are exceptions:
> Because
> these authentication mechanisms transmit credentials in plain text
> form and other authentication mechanisms do not provide data
> security services,
I suggest:
replace "Because these" with "Because many", (or several, some, ...?)
replace "and other authentication mechanisms" with "and/or".
> 1.2.1. Glossary of Terms
> - "connection" and "LDAP connection" both refer to the underlying
> transport protocol connection between two protocol peers.
>
> - "TLS connection" refers to an LDAP connection with TLS
> protection [TLS].
>
> - "association" and "LDAP association" both refer to the
> association of the LDAP connection and its current
> authentication and authorization state.
Switch to new [Protocol] terminology: "connection", "TLS-protected
LDAP exchange", "association" (not "LDAP association").
Though maybe the latter should get a bit more explanation in Authmeth:
("I.e. the client's current authentication and authorization identity"
-- and possibly other factors such as strength of bind method etc.?)
> 2. Implementation Requirements
> Implementations MAY support additional mechanisms of the simple and
> SASL bind choices. Some of these mechanisms are discussed below.
I would replace "additional mechanisms of the simple and SASL bind
choices" with "additional authentication mechanisms".
> 3.1.4. Client Certificate
> In an LDAP server requests a client to provide its certificate
> during TLS negotiation and the client does not present a suitablle
> certifcate (e.g. one that can be validated), the server MAY use a
> local security policy to determine whether to successfully complete
> TLS negotiation.
s/MAY/may/? What else than local security policy could the server use?
I guess the alternative is an implementation-specific setting; but I
would hope such a setting would just be a default - and using a default
would be a local security policy:-)
> 3.1.5. Discovery of Resultant Security Level
> After a TLS connection is established on an LDAP connection, both
> parties must individually decide whether or not to continue based on
> the security level achieved.
s/must/MUST/?
> 4.3. Invalidated Associations
> While the
> association is invalidated, the server may reject any operation
> request other than Bind, Unbind, and StartTLS by responding with a
> resultCode of strongAuthRequired
Thus ensuring that "strong"AuthRequired is totally misnamed, since even
anonymous bind fixes this condition. I think that needs to be noted
either in [Authmeth] or [Protocol].
> This behavior is
> explained here to help client implementers properly understand and
> react to this situation.
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.
Or explicitly say the opposite, if that has been decided. I seem to
remember a mention that someone disliked that the server could do this,
but I cannot find that now.
> 5. Bind Operation
> If the authorization identity is not
> specified, the server derives it from the authentication identity in
> an implementation-specific manner.
Should this and "implementation-specific" in B.4 (Authorization
Identity) be "implementation-specific and/or according to local policy"?
> 8. Simple Authentication Mechanism of Simple Bind
> Servers that map the DN sent in the bind request to a directory
> entry with an associated set of one or more passwords
Maybe add "which can be used with this authentication mechanism" since
an entry could contain several password representations of different
types, where each mechanism can only use some of the types.
> , will compare
> the presented password to the set of passwords associated with that
> entry. The presented password is considered valid if it matches any
> member of this set.
>
> If the DN is not valid, or the password is not valid for the DN, or
> the server otherwise considers the credentials to be invalid, the
> server is to return the invalidCredentials result code. The server
> is only to return success result code when the credentials are valid
> and the server is willing to provide service to the entity these
> credentials identify.
These two paragraphs mostly apply to other authentication mechanisms
too; though they would need to be generalized - some mechanisms do not
use a DN, others do not use a password, and some only work if there is
exactly one password which that mechanism can use.
I don't remember if I'm trying to resurrect a dead horse with the two
above comments; if so do tell me to leave it dead.
> Server behavior is undefined for Bind requests with a zero-length
> name value and specifying the simple authentication choice with a
> value of non-zero length.
Is this totally undefined, in that it may succeed but do something else
than what the simple authentication mechanism does? If so, it is not
that mechanism and does not belong in this section, but in section 5.1;
and the Simple Authentication Mechanism should be redefined to be
specified by a non-empty DN and a non-empty password. That would
require updates other places too, at least in the Security
Considerations section which refers to this mechanism.
If it is only undefined whether or not it succeeds as the Simple
Authentication Mechanism, that should be clarified here.
> LDAP implementations MUST be
> capable of protecting it by establish::qment of TLS (as discussed in
> section 3) or other suitable data confidentiality and data integrity
> protection(e.g. IPSec).
Maybe this should be turned around, since the section is about Bind and
not TLS:
LDAP implementations SHALL NOT support this mechanism unless they
can protect it by TLS.
(I removed "or other..."; see my 'TLS issues' message.)
> 10. SASL EXTERNAL Mechanism
> 11. SASL DIGEST-MD5 Mechanism
I suggest s/Mechanism/Authentication Mechanism/ in these titles.
> 12.1. General LDAP Security Considerations
> Servers can minimize denial of service attacks by timing out idle
> connections, and returning the unwillingToPerform resultCode rather
> than performing computationally expensive operations requested by
> unauthorized clients.
OpenLDAP returns adminLimitExceeded in some cases - e.g. if too many
entries are left to check after the indexes have been used. That seems
reasonable to me, though I'm not sure what adminLimitExceeded originally
means (in X.500).
> 12.2. StartTLS Security Considerations
> The goals of using the TLS [TLS] protocol with LDAP are to ensure
> connection confidentiality and integrity, and to optionally provide
> for authentication. TLS expressly provides these capabilities
> (although the authentication services of TLS are available to LDAP
> only in combination with the SASL EXTERNAL authentication method,
> and then only if the SASL EXTERNAL implementation chooses to make
> use of the TLS credentials).
That does not look like a security consideration to me.
> Clients SHOULD either warn the user when the security level
> achieved does not provide data confidentiality and/or integrity
> protection, or be configurable to refuse to proceed without an
> acceptable level of security.
I think this implies the wrong default. I suggest s/SHOULD/SHOULD by
default/, and they may then be configurable to be _willing_ to proceed
anyway.
However, that 'acceptable level' is a moving target. Maybe this should
be added somewhere (not under StartTLS):
Unfortunately, old implementations are (at least by default) likely
to consider poor security acceptable, since new attacks are regularly
being discovered and increasing computing power makes more attacks
practical.
> Server implementors SHOULD allow server administrators to elect
> whether and when data confidentiality and integrity are required, as
> well as elect whether TLS authentication of the client is required.
"TLS authentication" = "demand a client certificate which the server can
verify", not "demand SASL/EXTERNAL afterwards"?
I asked for clarification, and I notice the wording has changed in that
direction, but I don't know if that was in response to my request. I
would prefer more clearer words that "authentication" does not refer to
LDAP authentication (even to someone who has not read [TLS]), but if
others feel that the current wording is sufficient, that's OK.
> 12.3. Unauthenticated Mechanism Security Considerations
> LDAP server
> implementations will return a success response to an unauthenticated
> bind request
s/LDAP server implementations will/LDAP servers may/.
> 13. IANA Considerations
>
> The following IANA considerations apply to this document:
>
> Please update the GSSAPI service name registry to point
"ldap"
> to [Roadmap]
> and this document.
> 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. I previously suggested to also merge
SASL/ANONYMOUS, but if I remember correctly from the sasl list, that's
not anonymous in LDAP sense after all.
> A.4. LDAP Association State Transition Table
> S1, the initial state for the state machine described in this table,
> is the authentication state when an LDAP connection is initially
> established.
Actually you could make that a separate action A0: "Connecting to the
LDAP server".
BTW, I noted previously that it would be easier to read the table if the
actions and/or states have names rather than numbers. It's less
important now that the table is so much smaller, but it would still be
nice.
> Appendix B. Authentication and Authorization Concepts
Maybe "Data integrity protection" and "Confidentiality protection"
should also be explained? (And the section would be renamed.)
> B.2. Access Control Factors
>
> They might include
the association's authorization identity,
(That was actually not obvious to me at first; I wondered if ACFs were
more magical than that:-)
> source IP address, encryption strength,
> (...)
========
Editorial comments:
> 1. Introduction
s/indentifying/identifying/.
> 1.2.2. Security Terms and Concepts
> 3.2. Effects of TLS on a Client's Authorization Identity
"Appendix C" should be "Appendix B".
> 3.1.4. Client Certificate
s/suitablle/suitable/.
s/certifcate/certificate/.
s/external/EXTERNAL/.
> 3.2.1. TLS Connection Establishment Effects
> The decision to keep or invalidate the established LDAP association
> (section 12) after TLS connection establishment is a matter of local
> server policy.
s/section 12/section 4.3/.
> 3.2.2. Client Assertion of Authorization Identity
> specifying a SASL mechanism of EXTERNAL [SASL] (section 9).
s/section 9/section 10/.
> 5.1. Simple Authentication Choice
> 3. a simple authentication mechanism using credentials consisting
> of a name (in the form of an LDAP distinguished name [LDAPDN])
> and a password (section X).
I don't think that's the right section:-)
> 7. Unauthenticated Authentication Mechanism of Simple Bind
> Unauthenticated binds can have significant security issues (see
> section 14).
Section 12.3. And maybe s/./:/.
> 8. Simple Authentication Mechanism of Simple Bind
> capable of protecting it by establish::qment of TLS (as discussed in
Garbage: ^^^^^^^^^^^^^^^^
> LDAP implementations
> SHOULD support authentication with the "simple" authentication
> choice when the connection is protected against eavesdropping using
> TLS, as defined in section 4.
Section 3.
> 9.1. SASL Service Name for LDAP
> The SASL service name for LDAP is "ldap", which has been registered
> with the IANA as a GSSAPI service name.
Add a reference to the definition of "GSSAPI"?
> 10.2. Explicit Assertion
> An explicit authorization identity assertion is performed by
> invoking a Bind request of the SASL form using the EXTERNAL
> mechanism name that includes the credentials octet string. This
> string MUST be constructed as documented in section 3.4.1.
Section 10.4.
> 10.4. SASL Authorization Identity Syntax
> authzId = dnAuthzId / uAuthzId
Use '::=' instead of '=', like the other ldapbis drafts.
> DNCOLON = %x64 %x6e %x3a ; "dn:"
> UCOLON = %x75 %x3a ; "u:"
I would put these at the end of the grammar, so all definitions are
found below their use.
> 12.1.1.Password-related Security Considerations
Missing space after "12.1.1.".
> 12.2. StartTLS Security Considerations
> Clients SHOULD either warn the user when the security level
> achieved does not provide data confidentiality and/or integrity
Unindent "Clients".
> 12.4. Simple Mechanism Security Considerations
>
> The simple authentication mechanism of simple bind discloses the
> password to
the
> server,
> 12.5. SASL DIGEST-MD5 Mechanism Security Considerations
>
> The SASL DIGEST-MD5 mechanism is prone to the qop substitution
> attack, as discussed in 6.2 of RFC 2831. The qop substitution
> attack can be mitigated (as discussed in 6.2 of RFC 2831).
RFC 2831 Section 6 is "Authors' Addresses". Besides, I would think RFC
2831 should be [DIGEST-MD5] which will replace it, but its section 6 is
also "Authors' Addresses".
> 12.6. Related Security Considerations
Missing newline after header.
> Normative References
> [StringPrep] M. Blanchet, "Preparation of Internationalized
Unindent description.
> Appendix A. LDAP Association State Transition Tables
>
> This section provides a state transition table to represent a state
> diagram for the various authentication and TLS states
There are no TLS states in the table now.
> A.2. Actions that Affect LDAP Association State
Remove spurious "]"s in actions A5 and A6.
> A.4. LDAP Association State Transition Table
> Action State Comment
> ------- ----- -------------------------------------------------
If you expand the "Action" field, you can put things like
"A6, D1 or D2 = no" and "A6, D1 = D2 = yes" on a single line.
> A8 no [Protocol] section 4.14.2.1
> change
I suggest to call that A8 "no change[*]" and add
[*] The server may invalidated the association after TLS
establishment/closure; section 3.2.
> F.8. Changes for draft-ldapbis-authmeth-09
> - Reworded sentence beginning, "It is also desirable to allow
> authentication methods to carry identities based on existingù
> non-LDAP DN-forms..."
s/ù//. 8-bit character.
--
Hallvard