[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Extension: WG Last Call: draft-ietf-ldapbis-authmeth-15.txt



My apologies to all on this one. I definitely got several things backward in my updates to this section for authmeth-15. I have investigated and then reworked this section and believe that you will be much happier with the server identity check section in authmeth-16.

Roger

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 09/22/05 3:52 pm >>>
Howard Chu writes:
> Section 3.1.5 Server Identity Check
> This section talks about how a client must verify a server's name
> against the identity presented in the server's certificate. This clause
>   - The "*" wildcard character is allowed in the server name
>         provided by the user.  If present, it matches only the left-most
>         label from the subjectAltName.
> makes no sense to me. That implies that I can issue an ldap request to
> e.g. ldap://*.example.com, which at a glance means to perform a DNS zone
> transfer against example.com and then issue an LDAP query against every
> DNS host record that's returned. (...)

The following seems to have kind of reversed logic too:

>      - If a subjectAltName extension of type dNSName is present in the
>        certificate, it MUST be used as the source of the server's
>        identity.

This is wrong if the user provided an IP address and not a name.

>        Otherwise, if a subjectAltName extension of type
>        iPAddress is present in the certificate it SHOULD be used as the
>        source of the server's identity.  Implementations MAY support
>        the use of other subjectAltName types as sources of the server's
>        identity.

Given the "Otherwise..." above, it seems clear that if subjectAltName is
present in the certificate, iPAddress shall not be used even if it is
present too.  Thus, if one has ldap.example.com in the certificate,
one cannot connect to its IP address as well.

Also, it no longer seems to be an option to use the name in the CN, even
if there is no subjectAltName.  The above text is stricter about
alternatives.  Also the specification of dNSName in the next sentence
does not allow for anything else:

>    If the server name does not match the dNSName-based identity in the
>    certificate per the above check, user-oriented clients SHOULD either
>    notify the user (clients may give the user the opportunity to
>    continue with the LDAP session in this case) or close the transport
>    connection and indicate that the server's identity is suspect.

I think this sentence should be swapped a bit: Clients SHOULD indicate
that the server's identity is suspect and either notify ... or close
the transport connection.

BTW, the above dNSName should at least be relaxed to subjectAltname, to
be consistent with the rest of the text.  Though as you see I think that
too is too strict.

>    Automated clients SHOULD close the connection and then return and/or
>    log an error indicating that the server's identity is suspect.