Re: your mail

[Antoine Verheijen <antoine_(_at_)_nihon_(_dot_)_ucs_(_dot_)_ualberta_(_dot_)_ca>]

They're not. Let's go back to what started this: login and su (and part
of SSH). Remember that ticket-based Kerberos authentication is NOT being
done here. The user types a password into the login password prompt and,
instead of verifying the password against the local /etc/passwd file,
it's verified against a Kerberos database instead. In essence, login IS
the client and there is no server (or service) to whom a ticket is being
passed. The only reason "rcmd.<hostname>@<realm>" is being used is 
because OpenBSD chose to use this service key to verify the validity of
the responding KDC (which the current form does not guarantee). OpenBSD
could just as easily have chosen a completely different principal/instance
pair to do this, or, in fact, have used an entirely different means altogether.
This is not a Kerberos protocol issue, it is a unilateral decision made by 
OpenBSD. Kerberos does not provide, in any documentation/code I've seen,
a recommended means for doing KDC validation (you may correct me on this
if I'm wrong). 

I guess inherently I'd like to see OpenBSD correct its mistake by 
divorcing the KDC validation mechanism from the "machine service"
mechanism accessed using "real" Kerberos authentication.

> 
> On Thu, 20 Jul 2000, Antoine Verheijen wrote:
> 
> > Wrong. Typically, I would support the FQDN and not permit usage of
> > rcmd_(_dot_)_hostname_(_at_)_realm against my machines at all! I would not need it.
> > Furthermore, if you aren't interested in the FQDN, don't use it and
> > nothing is different than the way it is now.
> 
> yeah? and how are your clients generating inst names for service tickets?
> 
> -d.
> 
> ---
> http://www.monkey.org/~dugsong/
> 
> 
> 


-----------------------------------------------------------------------
Antoine Verheijen                  Email: Antoine_(_dot_)_Verheijen_(_at_)_UAlberta_(_dot_)_CA
CNS Network Services               Phone: (403) 492-9312
University of Alberta              Fax:   (403) 492-1729