Implementing IETF Draft on DNS use in Kerberos

[Nicolas Williams]

On Thu, Jul 18, 2002 at 03:07:10PM -0400, Sam Hartman wrote:
> (Nico, I realize you do actually get itbut I'm concerned that your
> explanation was not quite sufficient.)

Actually, I could stand some correction anyways; for one I gave no
explanation and further, my comment about pre-authentication was
irrelevant. Still, in the case that Will Fiveash was describing there
is no need to do a TGS exchange because the client principal in the
AS exchange is the host's client principal - if the host can decrypt
the AS-REP then all's good.

I think one way to explain the issue in question is to point out that
AS exchanges authenticate two entities and only those two entities,
a client principal and a KDC, to each other.

When there is a third party seeking to authenticate a client principal
then a further TGS exchange and an AP exchange are needed. Specifically,
an AS exchange implies no authentication of the client principal to
the host whence the client principal sends the AS-REQ - so if a host
is attempting to authenticate a user to itself then it must follow-up
the user's AS exchange with a TGS exchange to get a service ticket for
a principal for which the host has a key (other than the user). An AP
exchange is not needed because the host can directly verify the service
ticket returned by the TGS.

In the case that Will Fiveash was describing the host was using its own
principal to mutually authenticate to its AS as discovered via DNS,
thereby indirectly authenticating the DNS information.

Because DNS is insecure we have no choice but to indirectly verify
information gleaned from DNS that relates to Kerberos. Specifically we
can verify host->REALM and domain->KDCs information - host aliasing
cannot be verified however, so hosts must have keys for all names by
which one is to refer to them and DNS must be used only for discovering
the network addresses of hosts.

<off-topic>
It would be interesting to see if the GSS-TSIG work by MS could be
leveraged to secure DNS at the transport level and to hell with data
authentication (among other things this would require a way to indicate
whether the data in a response to a recursive request was obtained
in a secure manner). Such an approach to DNS security might be more
workable than DNSSEC on the theory per-connection key exchange and
authentication crypto would be faster and easier to manage than per-RR
signature verification.
</offtopic>

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

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.