RX Kerberos 5 security class requirements of Kerberos library
jaltman at secure-endpoints.com
Wed Jan 3 13:14:07 EST 2007
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.
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
to get rid of single DES within AFS in as efficient a manner as possible
that we do not make security worse in other respects. The first step in
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
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
happen AFS must get a new security class out sooner rather than later.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070103/229df98a/attachment.bin
More information about the krbdev