RX Kerberos 5 security class requirements of Kerberos library

Sam Hartman hartmans at MIT.EDU
Wed Jan 3 09:04:48 EST 2007


>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:

    Jeffrey> Marcus Watts wrote:
    >> Sam Hartman <hartmans at mit.edu> writes:
    >>>>>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:
    Marcus> I hope that answer's Sam's concerns regarding not going
    Marcus> through the KDC for this code path.
    >>>  Not entirely.  I definitely think that when there is a KDC
    >>> available that you should use it.  I'm willing to accept that
    >>> you might want a fallback for talking to local services when
    >>> you have a key and no network.
    >>> 
    >>> --Sam
    >>  Ok.  Let's talk about that.  How does the AFS "server-side"
    >> client code know when the KDC is up?  What value is the KDC
    >> going to add in participating in this process?  What use is
    >> another AFS server going to put in whatever might be provided
    >> by the KDC that couldn't be constructed directly by the remote
    >> server?  How can that AFS server know that any such added data
    >> was in fact authentic secure data added by the KDC and not just
    >> something made up by another server with access to the service
    >> key?  I can think of a lot of interesting things that might be
    >> done by some future KDC (though not very many that present
    >> KDC's do) -- but I can't think of any that are relevant to
    >> -localauth.

    Jeffrey> The AFS folks are thinking primarily about how AFS works
    Jeffrey> today in the legacy of kaserver and how can we easily
    Jeffrey> implement -localauth based upon that architecture.

    Jeffrey> Sam and Nico are considering other possibilities.  For
    Jeffrey> one, there are uses for such an API for non-local auth
    Jeffrey> uses.  Think of Love's forging of AFS user tokens by
    Jeffrey> Samba.  This is not a local auth operation and it could
    Jeffrey> very well benefit from contact with the KDC.

I'm explicitly trying to limit this API to localauth.  Nico disagrees
with that.




More information about the krbdev mailing list