Behavior change of krb5_rd_req: what error to return

[Nicolas Williams]

On Wed, Dec 03, 2008 at 11:27:39AM -0500, Sam Hartman wrote:
>     Greg> Agreed, if we accept the assumption that servers do not know
>     Greg> how to compare client-provided principal names against
>     Greg> keytab principals in the general case.
> 
> I think this is a good assumption: we have been looking for mechanisms
> to reliably make this work in the case of KDC aliases for years and
> not come up with ideas that seem likely to be implemented in a good
> fraction of environments.  So, I think dropping the assumption that
> servers can make this comparison is desirable.  We might be able to
> handle the case insensitive and Unicode issues, but dealing with DNS
> and other forms of aliases will be quite challenging.

If you could implement set-passwd or extend kadmin so that you could get
the list of aliases from the KDC -- on the assumption that there's a
finite list of aliases -- then you could have a service to keep the
keytab up to date.

But I gather that that's not likely to happen.  Which leaves you with
the heuristic that if a key works, then the given sname must be an alias
of the keytab entry's sname.

Note that having aliases which share the same longterm key as another
principal means that an attacker can undetectably change the sname in
the unauthenticated plain-text part of the Ticket.  (The sname is not
repeated inside the Ticket nor in the Authenticator.)  I'm not sure that
such an attack is terribly interesting, UNLESS the service is going to
make authorization decisions according to the name by which it was
called.

I would prefer that the keys for aliases be different from their
canonical principal names, such as by salting their "passwords."  That
would require keeping around the canonical principal's "password" used
to derive its keys.  That could be done using special keytab entries, of
course, though it would mean some changes to kadmin, ktutil and klist.

I'm pretty sure that Active Directory salts the entity' password to
generate the keys for its servicePrincipalName aliases.  I think you'll
want to do the same.

Nico
--