Turning off hostname canonicalisation
Nicolas.Williams at sun.com
Wed Sep 14 00:24:45 EDT 2005
On Tue, Sep 13, 2005 at 09:54:53PM -0400, Sam Hartman wrote:
> >>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:
> Jeffrey> On Tuesday, September 13, 2005 02:59:41 PM -0400 Sam
> Jeffrey> Hartman
> Jeffrey> <hartmans at mit.edu> wrote:
> >>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
> >>>>>>> writes:
> Nicolas> The proposed set/change password version 2 protocol deals
> Nicolas> with principal aliasing...
> >> It requires that the KDC be able to enumerate all the
> >> principals that a particular service can be known as. That is
> >> not compatible with case insensitive keytabs in an
> >> interoperable manner.
> Jeffrey> You've used that phrase twice now, and I still can't
> Jeffrey> figure out what it means. What requirement do you see
> Jeffrey> that is not being met?
> The issue is that unless I know that both the KDC and the keytab code
> are case insensitive, then it will not work interoperably.
> I think it is very dangerous to encourage implementations to have
> aliasing algorithms beyond what the set/change password spec will
> allow because doing so reduces the likelihood that one vendor's code
> can be used to replace another vendor's code.
For the record: I've not encouraged case insensitive principal name
matching. RFC1510 and RFC4120 recommend the use of lower case for the
domain name in NT-SRV-HST principal names. It helps to enforce this at
principal creation/modification time.
More information about the krbdev