Is this too big of a change?
hartmans at MIT.EDU
Mon Aug 26 15:38:00 EDT 2002
>>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
Douglas> The 344 byte limit, sort shoots down the use of the -dfs
Douglas> flag we had in the ak5log, if the ticket was from W2K.
Yes, but since by that point you're changing clients increase the limit.
You do have to know you're talking to new servers before using the -dfs flag.
Douglas> But if you are using the krb524d to in effect convert a
Douglas> k5 ticket to a k5 ticket, for use only by AFS, do you
Douglas> need to copy all data? You could leave out the w2k
Douglas> authorization data, as AFS will not use it.
You do not need to, but if you just copy data you don't even need
access to the encryption key and we believe that this is more
desirable than support for krb5 with very large tickets.
My current implementation does not use any keys at all in the new afs
Douglas> Something else we have been doing is to use two keys, one
Douglas> for the principal shared between the KDC and krb524d, and
Douglas> another shared between the krb524d and afs servers. This
Douglas> allows them to have different kvno, and different
Douglas> enctypes The krb524d basically has access to the AFS
Douglas> keyfile. But this would not be true if you eventually
Douglas> want to get to the point where the KDC is issuing the AFS
I don't think we have any interest in this.
Douglas> This brings up the question, does the AFS token has to be
Douglas> a K5 ticket, or just something which could take advantage
Douglas> the improved encryption andtimestamps in k5?
If the AFS token can be constructed from a k5 ticket without access to
an encryption key you get significant advantages in terms of reducing
privileged code and deploy AFS in Kerberos only environments.
More information about the krbdev