On Thu, May 16, 2002 at 08:19:14PM -0500, Jacques A. Vidrine wrote: > On Thu, May 16, 2002 at 09:04:00PM -0400, Lawrence Greenfield wrote: > > Hopefully the Kerberos clarifications in the krb-wg will address this > > issue and MIT will change their implementation.. > > Change it how?
At the interim KRB-WG meeting there was a discussion about this. Here's some possibilities, tell me which you prefer :) - don't canonicalize, expect the user to know the canonical name - secure DNS (yeah...) - don't canonicalize, spontaneously alias principals at the KDC That last one means that when I use a non-fully-qualified hostname or an alias of a hostname as a or part of a service principal name, then the KDC will issue the requested ticket IFF the KDC can determine that the requested name is indeed an alias of some other SPN. The application too must know its aliases or try its keys for all SPNs by which a client references it. IIRC MS does just that. That is what I propose MIT, Heimdal et. al. do. >From a user's perspective it works just like before, only more securely, though transparency depends on the KDC being able to determine which host the client really means, or, rather, what that name would resolve to from the client's point of view. 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. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
