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

Re: TLS Server Identity Check



Besides the callback mechanism I previously suggested, it might
be appropriate to have LDAP session options
(accessed via ldap_[gs]et_option) which provide policy:
        LDAP_OPT_TLS_NAME_CHECK

which can take the values:
        LDAP_OPT_TLS_NAME_STRICT_CHECK  (0) [default]
        LDAP_OPT_TLS_NAME_LAZY_CHECK (1)
        LDAP_OPT_TLS_NAME_NO_CHECK (2)

Where strict is per RFC2830, lazy allows (in addition to
RFC2830) DNS canonical names, and no check disables the
check.

The callback would only be called if the check failed.
        

At 05:42 PM 11/24/00 +0100, Norbert Klasen wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> I crossed by replies...  It was tls.c change I made a couple
>> very minor changes to.  Also, I have yet to review the changes
>> in terms of RFC 2830 compliance (which states exactly how
>> server certs must be checked).
>
>Good point. RFC2830 states that:
>   - The client MUST use the server hostname it used to open the LDAP
>     connection as the value to compare against the server name as
>     expressed in the server's certificate.  The client MUST NOT use the
>     server's canonical DNS name or any other derived form of name.
>
>Currently I get the hostname from ldap_host_connected_to() which DOES
>make an reverse lookup. ldap_host_connected_to() is also used in KBIND
>and SASL to determine the remote hostname. Shouldn't Kerberos and SASL
>also go by the initially specified hostname? 
>
>And another point:
>   If the hostname 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 connection in any case) or terminate the connection
>   and indicate that the server's identity is suspect. Automated clients
>   SHOULD close the connection, returning and/or logging an error
>   indicating that the server's identity is suspect.
>
>If we want to give clients a chance to let users override, the server
>identity check must be moved from ldap_pvt_tls_start(). But then what
>about automated clients. How's this best accounted for in a library?
>
>-- 
>Norbert Klasen
>DFN Directory Services                           tel: +49 7071 29 70335
>ZDV, Universität Tübingen                        fax: +49 7071 29 5912
>Wächterstr. 76, 72074 Tübingen              http://www.directory.dfn.de
>Germany                             norbert.klasen@zdv.uni-tuebingen.de