FQDN needed by sasl_gss_client_step or gss_import_name?

[Nicolas.Williams@ubsw.com]

user->client: connect to FOO
client->DNS: get canon name and address for FOO
DNS->client: the canonical name for FOO is BAR and this is its address
client<->BAR: TCP connect and negotiate Kerberos auth
client->KDC: get ticket to talk to BAR
KDC->client: ticket to talk to BAR
client->BAR: AP-REQ
BAR->client: AP-REP
client<->BAR: chat

Something's wrong with this: the user doesn't know that FOO was canonicalized to BAR just like that and the client doesn't have a way to authenticate the canonicalization because DNS is not secure. I hate it. I used to be in denial of this.

There's a solution: push some of the canonicalization to KDC. The MS approach is to have the KDC treat SPNs which are "obviously" DNS aliases as real principals using the same key material as that of the canonical name. Like so:

user->client: connect to FOO
client->DNS: get address of FOO
DNS->client: the canonical name for FOO is BAR and this is its address
client<->FOO(really BAR): TCP connect and negotiate Kerberos auth
client->KDC: get ticket to talk to FOO
KDC->client: ticket to talk to FOO (using BAR's key)
client->FOO(really BAR): AP-REQ
FOO(really BAR)->client: AP-REP
client<->FOO(really BAR): chat

Implementing this really means that the KDC and the DNS name service have to have a higher degree of integration because the KDC now needs to have secure access to the same info as stored in the zone files for the same realms' domains. Mind you, there already has to be a pretty good correlation between the two - now it has to be more formal.

Cheers,

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.