Is this too big of a change?

Sam Hartman hartmans at MIT.EDU
Mon Aug 26 14:35:15 EDT 2002


>>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:

    Douglas> Sam Hartman wrote:
    >>  Hi.  We're working on 1.2.6beta2 and are proposing to make a
    >> change that has somewhat more impact than we would normally
    >> make in a point release and we'd like to see how much trouble
    >> it would create for users.
    >> 
    >> The OpenAFS and Arla community is working on support for
    >> somewhat more native krb5 authentication to AFS.  Servers will
    >> support the encrypted part of a krb5 ticket sent with a special
    >> kvno as an AFS token.  It turns out that if you have a special
    >> krb524d this improvement allows you to upgrade to doing krb5
    >> AFS without any client changes.

    Douglas> How does this match the code that Transarc added to the
    Douglas> AFS clients for the AFS to DFS migration tool? There the
    Douglas> token could be a K5 ticket. Are you using the same trick?

We are using a similar trick.  Their trick required a larger buffer
than the clients they shipped had for max token size and required
client changes to generate a kvno greater than one byte.

I believe that server implementations of rxkad will also support their
trick.
    Douglas> Where is the exception list? If its with each krb524d
    Douglas> that OK.

Yes, it will be a file read by krb524d.  We considered adding a kdb
flag, but that would have negatively impacted people using krb524d
without a database (w2k KDCs) and would have required kadmin changes
in a patch release.



    Douglas> Can I still use a W2K KDC? We do that here with a
    Douglas> modified krb524d and a ak5log.

Yes, you can.  However you may end up issuing v4 tickets rather than
the new style AFS tokens because the new style tokens are only issued
if the token is shorter than 344 bytes (current max token size in
OpenAFS) which is unlikely if your tickets contain w2k authorization
data.  However, the AFS server will hapilly still accept v4 tokens so
all will continue to work.


    Douglas> As AFS starts to use K5, what are the relationships of
    Douglas> the AFS cell name and the Kerberos realm name? Hopefully
    Douglas> they are seperate. Where the principal used are something
    Douglas> like afs/<afscell>@<krb5realm> With no assumptions about
    Douglas> the afs cell matching the realm. This should also mean
    Douglas> that the afsservers should be able to use principals from
    Douglas> multiple realms.

Certainly this is true of the current k5 plan.  Naming gets much more
complex for RXGSS and you should follow those discussions when they
happen (I'm not particularly involved in anything to do with RXGSS so
I don't really know the state).





More information about the Kerberos mailing list