I should say some further stuff that might help people for planning purposes.
The rxk5 openafs service principal name is: afs-k5/<cell-name>@realm-name when you create this principal, you tell the kdc what encryption types are to be supported - you should not list any types your server binaries cannot handle. You'll then save that on your openafs db servers in some keytab like /etc/openafs/server/keytab.afs and this file will replace "KeyFile" for rxk5. Whether you support rxkad or rxk5 on your servers depends entirely on if you have a keyfile or keytab. If you have both, you'll support both. If you create an "afs" principal with other than des key types, you lose. Migrating your servers to rxk5 consists of upgrading your software and installing the keytab. You might need to fiddle with krb5.conf or /etc/openafs/server/krb.conf, depending. When you run aklog, it will query the local cache manager to see what types it supports, intersect that against the kerberos libraries aklog was linked against, then give that to the kdc will will intersect that against the key types it has and supports and select the "best one", which will probably be the first one that aklog gives it. If you run an rxk5 enabled aklog, it will get and store an rxk5 credential by default unless you indicate by command line flag (-k4) or environment variable to save an rxkad token. You can be authenticated in multiple cells, and whether the cm uses rxkad or rxk5 to a particular cell (for a particular pag) will be determined entirely by which kind of token was last set for that cell (in that pag). When you run other tools, you will have the opportunity to tell it both the cell & some clue as to which credentials cache to use via command line arguments. You will be able to point to either the keytab (rxk5 localauth), the keyfile (rxkad localauth), a kerberos 5 credentials cache (rxk5), a ktc token (rxkad or rxk5), or nothing (noauth). Again, you'll be able to use rxk5 in one cell or rxkad in another, using the same tool. There are some intelligent defaults here so if you tell it "-localauth" it will see if you have a keytab first, then try for the keyfile. This part is the last thing left to finish - so I won't tell you the hackish flags Matt and I used in development. With aklog, you were able to use "-k" if you didn't have the domain_realm stanza right in your krb5.conf file. With the other tools, this capability likely won't be there, so plan on fixing krb5.conf so that you don't need to use -k even with aklog. So far as tools goes: we don't plan to do anything with kaserver. An rxk5 version of kaserver just doesn't make sense without also making it a k5 kdc, and there are lots of perfectly good krb5kdc's already. For ptserver, we use just the current name structure, with the obvious s/\./\// hack. Other people are working on teaching ptserver about multiple name spaces, so we hope in the future that will provide a native k5 name space for rkx5. bos/vos/pts are the 3 big userland tools, and all those work with rxk5. The actual wire data packet encryption or integrity checking is done using standard kerberos 5 algorithms - what your kerberos library can do will determine all the basic cryptography. We have it supporting des, des3, rc4, and aes today. We have it working with heimdal & mit. You'll be able to run with heimdal right off. MIT is a bit more problemmatical; no big deal but you probably won't be able to use vendor libraries at least right off. We plan to also support openssl, which might give you the interesting potential for hardware crypto accelleration of openafs servers such as the fileserver. The kernel part links against its own unique self-contained crypto blob; it's intended to be a fairly fast but very portable. In the future, kernel cm's for some architectures may be able to use the kernel crypto support. How well that will work will depend in a large part how "key agile" the kernel interface can be. Somebody had asked about "fs setcrypt". For rxkad, that selects between rxkad_clear & rxkad_crypt. For rxk5, the same bit will select between rxk5_auth and rxk5_crypt. We have code to do "rxk5_clear", but believe it only makes sense in very specialized circumstances. For most services, this is true: security index 0 = noauth, 1 = rxvab (extinct), 2 = rxkad, (rarely) 3 = rxkad (crypt), 4 = rxgk, 5 = rxk5. As for when you might see this, this depends on several things; Matt and I want to finish a few things up -- mainly "tokens" at this point, but I might get openssl working too. The gatekeepers will need to add it to the repository. It's possible the next 1.5.x release after that will have this, but there will in any case be significant work to make it stable and work on all platforms. Presumably at some point after that, there will be an even numbered release (1.6? 1.8?) that has rxk5. If you're *desperately* interested in an early peek - drop Matt or I a line. -Marcus Watts _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info