[OpenAFS-devel] rx + kerberos5 + !des

[Jeffrey Hutzelman]

On Monday, May 16, 2005 07:13:52 PM -0400 Jeffrey Altman 
<jaltman@columbia.edu> 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