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