On Monday, May 16, 2005 07:13:52 PM -0400 Jeffrey Altman <[EMAIL PROTECTED]> wrote:
The Kitten PRF drafts ... are not public yet.
By which he actually means "they are active work items of the IETF kitten working group, on which you are welcome to comment. I expect to issue a last call on these documents sometime this week".
For reference, the documents in question are draft-ietf-kitten-gssapi-prf-03.txt draft-ietf-kitten-krb5-gssapi-prf-03.txt
For what it's worth, Jeff and Love haven't shed a whole lot of light on how this is all expected to work, so I'll try to do so. While I was involved in some of the basic design, it's been a while since I've touched this stuff, so hopefully Love will correct me on the bits that have changed.
rxgk is an Rx security class module, like rxkad. It is designed to provide strong security for Rx using modern cryptographic algorithms and design techniques, which are areas in which rxkad is sorely lacking (even if you replace DES with a modern cipher, it's still pretty bad). While the rxgk builds on the Kerberos crypto framework (RFC3961), the security class itself is designed to be authentication-mechanism-agnostic; it does not require the use of Kerberos or GSSAPI.
What rxgk proper does require is some means of authenticating and securing an exchange with the server which is done prior to connection setup. This exchange results in an rxgk token and an encryption key, which can then be used for establishing multiple connections between the same client and server (or multiple servers, if they are configured to use the same private key for encrypting rxgk tokens). Note that unlike rxkad, rxgk never uses this key for encrypting actual connection data, does not reuse keys across connections, and has strong protection against replays even within a connection.
The token-based design has several major benefits. First, it decouples the authentication mechanism from the protocol used to protect actual connection data, allowing the former to be swapped out at-will (unlike rxkad, which works only with single-DES Kerberos tickets). There are some parallels to gssklog in this approach, but in the case of rxgk the tokens were designed expressly for the needs of the security class, rather than being based on the design of some particular authentication mechanism. In fact, the original intent was to initially build an implementation directly around Kerberos V, with the ability later to drop in GSSAPI when that became a viable option. Of course, at this point there is no longer any intent to build authentication for rxgk on raw krb5.
Second, the token-based approach keeps authentication out of the core of the security class, which in the case of the AFS cache manager means it can also be kept out of the kernel. Because the rxgk token key can be shared between servers, it is possible to perform the initial authentication exchange up front, as is done now, and pass the rxgk token and key to the kernel in the same way that Kerberos tickets are currently passed. Down the line, this will probably be replaced with a richer interface allowing for separate per-server keys and/or automatic aquisition and renewal of tokens as needed.
Finally, the token-based approach allows authentication and parameter negotiation to take place outside the context of an Rx security class, before the first protected packet is ever transmitted. This allows for things like enctype negotiation, level negotiation, and the use of authentication mechanisms requiring multiple round trips, all of which would otherwise be impossible due to the limitations of the Rx security model.
Obviously, an actual useful implementation will require a means to carry out the initial authentication exchange and, for implementations involving kernel code, a way to get an rxgk token out of the aklog-alike process and into the kernel. In the case of GSSAPI-rxgk, I expect the former will be done using unauthenticated RPC's made to a special "universal" Rx service running on the same port as the main server. While servers will need to provide certain components, as they do today with rxkad, the majority of the details at both ends will be handled entirely inside the library.
And yes, I expect rxgk to be fully workable for rx-based services which are not part of AFS. I have several of those myself.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
