RX Kerberos 5 security class requirements of Kerberos library

[Jeffrey Altman]

Nicolas Williams wrote:
> I think TLS with self-signed certs is a better fit, protocol-wise, for
> authentication of middle-ware to servers.  The Kerberos V AP exchange as
> a PSK mechanism can work, but it has this wrinkle that the client
> principal name cannot be ascertained (unless it is, or is coerced to be
> the same as the service principal name); this may be seen as a feature,
> since some consumers may want krb5 PSK initiators to be able to assert
> any client principal.
>
> In any case, I really dislike the idea that this API would check that
> there is what appears to be a credential for the client principal name
> being asserted -- either don't do that or go through the KDC and forget
> about PSK.
>
> Nico

Nico:

We are not discussing what we should do when building a new infrastructure.
We are discussing what is done in an existing infrastructure.  I am
attempting
to get rid of single DES within AFS in as efficient a manner as possible
providing
that we do not make security worse in other respects.  The first step in
that is
enabling a new security class that can support non-DES enctypes.  We are not
looking to redesign how all of the AFS servers and administrative tools
work
with each other in the process.

Sam has placed a requirement that the functionality that is added to MIT
Kerberos be general enough for other purposes.  I believe the functionality
described meets Sam's condition and satisfies the needs of AFS.

I want Kerberos 4 to die a quicker death than it is and in order to make
that
happen AFS must get a new security class out sooner rather than later.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070103/229df98a/attachment.bin