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


More information about the krbdev mailing list