Jeffrey Altman writes: ... > > rxk5 does not do everything that we wanted rxgk to do but they are > much further along in the development process than rxgk is at the moment > and rxk5 provides 90% of what is desired.
rxk5 can also be the basis for doing rxgk -- the basic packet encryption is very close to what rxgk would have to do anyways. I believe the plan is to share that logic with rxgk. The main thing rxgk changes is how the initial token generation, challenge, & response logic work. Those are actually technically simple; the real complexity in gssapi is 2 things: sorting out various extensions to gssapi that rxgk needs that may not have made their way through the standardization process yet, and figuring out how to wedge pieces of gssapi into various bits of openafs especially the kernel. The latter has actually been done already in linux for NFSv4, but the code only does des. I can't really blame the folks who did that -- des3 and aes hadn't yet been standardized for gssapi when that work was done. I hope to see work go forward for rxgk, or if not exactly rxgk, there are certainly all those "other things" we don't do that we should find ways to do. rxk5 is the useful part of rxgk that we can deliver this year. rxgk, rxtcp, and departmental fileservers, these are all things we should continue to work on, each is going to require significant extra work, and I hope are improvements people here can look forward to seeing happen. -Marcus _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info