FQDN needed by sasl_gss_client_step or gss_import_name?

[Nicolas.Williams@ubsw.com]

BTW, in smallish environments this is not a big concern, you're right. If you have large environments with lots of realms and trusts between them, then this becomes an issue, because while one administrator can (maybe) vouch for the security of hosts in one realm he may not for other realms.

Nico
--  

> -----Original Message-----
> From: Steve Langasek [mailto:vorlon at dodds.net]
> Sent: Monday, May 20, 2002 5:19 PM
> To: David Lawler Christiansen (NT)
> Cc: cyrussasl; krb5
> Subject: Re: FQDN needed by sasl_gss_client_step or gss_import_name?
> 
> 
> 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.