FQDN needed by sasl_gss_client_step or gss_import_name?

[Steve Langasek]

On Mon, May 20, 2002 at 02:00:21PM -0700, David Lawler Christiansen (NT) wrote:

> > From: Steve Langasek [mailto:vorlon at dodds.net]
> > Sent: Friday, May 17, 2002 7:32 AM
> > To: Lawrence Greenfield
> > Cc: Jacques A. Vidrine; Dave Snoopy; cyrussasl; krb5
> > Subject: Re: FQDN needed by sasl_gss_client_step or gss_import_name?

> [...]

> > > 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.

> DoS isn't the issue.  Spoofing is.  Relying on DNS for name
> canonicalization would enable an attacker to defeat mutual
> authentication.  

*Only* if the attacker has his own trusted service principal which he can
substitute for that of the server being spoofed.  Granted, as Kerberos use
becomes more widespread through increased deployment of Win2K, and as
inter-realm trust relationships become more frequent, this becomes a more
useful attack vector; but at least for my applications, DNS spoofing does
not represent a real danger, because there are very few service principals
that an attacker could successfully use in this manner: the inconvenience
of attempting to deploy another system for principal canonicalization far
outweighs any risks.

Steve Langasek
postmodern programmer