[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change
I support your proposal. We definitely need to specify consistent
behavior in the face of failed binds (thanks to Kurt for noticing the
discrepancy). I think it is too late to change LDAPv3's behavior (as
specified in 2251) since clients likely exist that rely on the
"revert-to-anonymous" behavior it specifies... but that is an argument
for another later day.
--
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's. Got LDAP?
RL 'Bob' Morgan wrote:
>
> As Kurt has pointed out (and first pointed out back in November),
> there is a difference between RFC 2251 and
> draft-ietf-ldapext-ldapv3-tls-06.txt on the question of what the client
> authentication/authorization state should be after a failed bind
> attempt. 2251 (last paragraph of 4.2.1) says:
>
> Clients MAY send multiple bind requests on a connection to change
> their credentials. A subsequent bind process has the effect of
> abandoning all operations outstanding on the connection. (This
> simplifies server implementation.) Authentication from earlier binds
> are subsequently ignored, and so if the bind fails, the connection
> will be treated as anonymous.
>
> Call this the "revert-to-anonymous" approach. Whereas ldapv3-tls-06
> (first paragraph of 6.1.2.3) says:
>
> For either form of assertion, the server MUST verify that the client's
> authentication identity as supplied in its TLS credentials is permitted
> to be mapped to the asserted authorization identity. The server MUST
> reject the Bind operation with an invalidCredentials resultCode in the
> Bind response if the client is not so authorized. The LDAP association's
> authentication identity and authorization identity (if any) which were
> in effect after TLS establishment but prior to making the Bind request,
> MUST remain in force.
>
> Call this the "leave-as-is" approach. (The same language appears in
> the second paragraph too.)
>
> The intention never was to have different behavior for different kinds
> of binds. Some of us (Jeff and Bob) think that the leave-as-is
> approach is the right thing to do for all failed binds, since it's
> more intuitive (to us), consistent with other practice (eg "su" on
> UNIX), and produces a cleaner state diagram. However, upon reflection
> these arguments don't seem compelling enough to change the behavior
> that is in RFC 2251, especially at this point when a revised 2251
> isn't even on the table. We do think it's worthy of discussion when
> 2251 is revised, though.
>
> We also don't want this issue to hold up the issuance of the set of
> security docs (draft-ietf-ldapext-authmeth-04.txt,
> draft-ietf-ldapext-ldapv3-tls-06, draft-leach-digest-sasl-05.txt)
> which this WG has been working on for over two years, and which will
> remove the IESG warning from the front of RFCs 2251-56. These docs
> have already been through WG and IETF last calls, and IESG review, and
> are very close to going to RFC.
>
> So, we propose that section 6.1.2.3 in draft-ietf-ldapext-ldapv3-tls-06
> be changed to reflect the revert-to-anonymous approach; new text is
> appended to this message.
>
> This is a small but substantive change which will require a new (-07)
> version of the ldapv3-tls draft. Rather than go through another full
> last call we suggest waiting a week from today for comments on this
> change, then telling the Area Directors to go forward with
> ldapv3-tls-07 for publication.
>
> Comments, please.
>
> - RL "Bob" Morgan
> Jeff Hodges
> Mark Wahl
>
> ---
>
> 6.1.2.3. Error Conditions
>
> For either form of assertion, the server MUST verify that the client's
> authentication identity as supplied in its TLS credentials is permitted
> to be mapped to the asserted authorization identity. The server MUST
> reject the Bind operation with an invalidCredentials resultCode in the
> Bind response if the client is not so authorized.
>
> Additionally, with either form of assertion, if a TLS session has not
> been established between the client and server prior to making the SASL
> EXTERNAL Bind request and there is no other external source of authenti-
> cation credentials (e.g. IP-level security RFC 1825), or if, during the
> process of establishing the TLS session, the server did not request the
> client's authentication credentials, the SASL EXTERNAL bind MUST fail
> with a result code of inappropriateAuthentication.
>
> After the above Bind operation failures, any client authentication
> and authorization state of the LDAP association is lost, so the LDAP
> association is in an anonymous state after the failure. TLS
> connection state is unaffected, though a server MAY end the TLS
> connection, via a TLS close_notify message, based on the Bind
> failure (as it MAY at any time).