Is this too big of a change?

[Sam Hartman]

>>>>> "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
case.



    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
    Douglas> token.

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.