RX Kerberos 5 security class requirements of Kerberos library
Nicolas Williams
Nicolas.Williams at sun.com
Wed Jan 3 13:42:19 EST 2007
On Wed, Jan 03, 2007 at 01:14:07PM -0500, Jeffrey Altman wrote:
> 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.
Understood. And you have my opinion on that:
- go ahead
- follow Sam's proposal (additional gic_opts)
- don't bother with false checks for client credentials: if the
interface will mint a ticket without talking to the KDC because the
client provided a shared key for the target service principal then
don't insist on having a keytab entry (or password) for the client
principal name.
In particular I really prefer the gic_opt approach as that is clearly
extensible.
Nico
--
More information about the krbdev
mailing list