RX Kerberos 5 security class requirements of Kerberos library

[Marcus Watts]

Various wrote lots of stuff regarding what Nico describes as:
...
> I think you're proposing an API that allows one to use the Kerberos V AP
> exchange as a pre-shared symmetric key authentication mechanism.
...
I'm not sure that's quite how I'd say it, but it's a start.

I don't think the context for this was completely described.
The purpose of this is to implement afs "-localauth" semantics.

In AFS, all of the fileservers & db servers have the same server
key installed -- for rxk5, that is "afs-k5/<cellname>@<realm-name>".
(for rx, that key was "afs[ /<cellname> ] @<realmname>").
There are lots of arguments that could be made regarding sharing
the server key - there are actually good reasons not to do this,
but for better or worse, that's a current design feature of AFS
which cannot be easily changed.  The original reason AFS had
"-localauth" was to permit starting and stopping the AFS kdc
(kaserver).  I don't know how many people run the MIT kdc
under bosserver, but I don't see much value to breaking this.

It's an inherent property of the Needham and Schroeder protocol
used by kerberos that anybody who has a copy of the server key
can create tickets for any user, real or imaginary, which are then
completely indistinguishable from keys created by the kdc.
I don't know of any way to fix this without using public key cryptography.
A trip to the KDC to validate such credentials isn't of great
benefit - if mallet has a copy of the service key he's got all he
needs to impersonate the KDC to the service.  Therefore, functions
to implement "-localauth" don't compromise any real security.

I hope that answer's Sam's concerns regarding not going through
the KDC for this code path.

Regarding Nico's (and Jeff's) API concerns -- I don't think I have any
strong feelings here.  As long as it takes a keytab, service & client
name in, does local crunching, & produces a credential as output, I
don't much care how the guts work.  From an aesthetic standpoint, I
think not putting it in krb5_get_init_creds is an advantage, because
that means not putting code in a pure end-user client that is only
useful in a fairly specialized environment on the server.  Also, I
think there are already problems with the fixed size & lack of 'free'
function for krb5_get_init_creds_opt.  Also from a aesthetic
standapoint, I think there's some advantage to letting the service
construct and manipulate the ticket at low level before it's encrypted
-- it's going to see it shortly anyways at the other end, and this
would allow it to trivially do things like construct a special PAC for
itself (if it wanted).  But, as I said, I think these are more
aesthetic concerns than anything else for AFS.

				-Marcus Watts