>>    Is kerberosIV fully supported if you build things in /usr/src/domestic?
>> Is the KerberosV implementations under development?
>
>I wish it were, but I have a hunch it's not.

Actually ... it might soon be, if _someone_ replies to email I sent
(I won't mention any names ... Jason :-) ).

>There's a fair amount of
>functionality that's apparently still not implemented, such as setting
>tickets to be forwardable in the krb5.conf file.

Argh, don't get me started about _that_, especially when I wrote the
code that got sort-of put in the MIT distribution, but then taken out
but it got put in the Cygnus distribution ....

>I also have a set of patches for krb5 in xdm that I got from somebody, I
>think on comp.protocols.kerberos.

Possibly me ... I had one set of patches, but there are a few others.

>I also remember corresponding with
>somebody who said he had a set of patches for the X server and xhost.
>That would just be the cat's meow, but it seems like there was some major
>logistical problem with it.  I *think* the problem was that the patch was
>written for krb5-1.0beta6, and the API changed from that release to
>krb5-1.0 and its successors.  At the time, I didn't have a copy of the
>newer API, so I was in no position to modify the patch for the current
>version of krb5, and I couldn't find an old version of krb5 out there
>anywhere.

I _did_ look at this code, because I was mildly curious about this.

Fixing this code isn't actually impossible ... it might be pretty easy,
because while the API has changed, it hasn't changed _that_ much
(all that really needs to be done is a Kerberos context needs to be
created and added to various function calls at some points).  The
question is, "is it worth it"?  The big downside to this is that is
requires mods to both the client libraries and the server, which is
easy enough when you're running NetBSD everywhere (except for Netscape,
but hey, that's going to change :-) ), but it's hard if you want to
display apps from random system X, which is the whole point of having
authenticated X connections in the first place :-)

As Johan has pointed out, it doesn't help out on the integrity or
confidentiality side; it just authenticates at connection time.
Although I personally think this still has some merit; it raises the
bar and breaks most of the cracker breakin kits, which IMHO isn't so
bad :-)

--Ken