FQDN needed by sasl_gss_client_step or gss_import_name?

[Steve Langasek]

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