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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > > 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 [EMAIL PROTECTED] > 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. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
