FQDN needed by sasl_gss_client_step or gss_import_name?

Steve Langasek vorlon at dodds.net
Fri May 17 10:32:26 EDT 2002


On Thu, May 16, 2002 at 09:32:32PM -0400, Lawrence Greenfield wrote:
>    Date: Thu, 16 May 2002 20:19:14 -0500
>    From: "Jacques A. Vidrine" <n at nectar.cc>

>    On Thu, May 16, 2002 at 09:04:00PM -0400, Lawrence Greenfield wrote:
>    > Hopefully the Kerberos clarifications in the krb-wg will address this
>    > issue and MIT will change their implementation.. 

>    Change it how?

> By not using DNS to construct service principals.

> Currently, when a request for (say) "ldap at ad.cmu.edu" is made, the MIT
> GSS/Kerb implementations performs a forward looku of "ad.cmu.edu" and
> then a reverse lookup of the answer (say "fred.ad.cmu.edu") and then
> requests a ticket for the service principal "ldap/fred.ad.cmu.edu".

In practice, compromising the DNS only lets you perpetrate a DoS, and
DoS attacks are a dime a dozen.  To exploit this further, you would need
to also get your hands on a real service principal in the Kerberos realm,
either by compromising another server or by betraying a trust relationship
within the realm.  For my part, I don't indiscriminately hand out service
principals called ldap/myevilmachine.dodds.net to anyone who asks for one.

> Since DNS is an insecure mechanism (an attacker could substitute
> "myevilmachine.cmu.edu" for "fred.ad.cmu.edu" in the DNS response)
> this leads to a vulnerability.  Microsoft Kerberos implementations
> aren't subject to this attack.

Hmm, I think Microsoft Kerberos implementations are just as vulnerable to
DoS attacks in the DNS: all I have to do is interfere with forward
lookups, and Microsoft clients can't find their servers any better than 
MIT clients can.

Steve Langasek
postmodern programmer



More information about the Kerberos mailing list