[OpenAFS] Roadmap for features

[Jeffrey Hutzelman]

On Monday, November 08, 2004 10:46:49 -0500 Derrick J Brashear 
<shadow@dementia.org> wrote:

>> - A secure RPC / packet privacy.  This should be solved by above, right?
>> We'd like to enforce packet privacy for secure file service on the file
>> server side like in DCE/DFS and not rely on the client admin to remember
>> to enable it.
>
> well, we'd need some switch to enable/force it, there's a little bit of
> work to do for it, but it's mostly free once you have the above.

This turns out to be trickier than it sounds.

First, let me refer everyone to RFC2828 with regard to some security
terms, particularly "privacy", "security", "data confidentiality", and
"data integrity".

Accesses done without tokens are done using the rxnull security class.
This class does not and cannot provide data confidentiality or integrity
protection.  So, if you want to "force" the use of these features, you
need to not allow unauthenticated access.  Unfortunately, it's not as
simple as just disallowing rxnull, because some operations are _always_
done using unauthenticated connections.  The most critical of these is
checking that a fileserver is up, which is done every 3 minutes.  If
this fails, the cache manager will declare the fileserver down.

Today, accesses done with tokens are done using the rxkad security class.
This class provides authentication, and may provide other services,
depending on what level is used.  There are three levels:

- rxkad_clear provides no protection
- rxkad_auth  provides data integrity
- rxkad_crypt provides data integrity and confidentiaity

All three levels also provide a trivial checksum on the rx packet header.
In any case, the crypto used by rxkad to provide these services is fairly
weak, both because the cipher is poor and because it is not used in ways
that protect against certain attacks.   Note that authentication itself
is based on Kerberos; its strength depends largely on the enctypes used.

Negotiation of the level to be used is done in a fairly simplistic manner.
Basically, the client proposes a level, and the server determines whether
the proposed level is good enough.  If the level the client used is below
the server's minimum level, the connection fails.  So, it is possible to 
have a fileserver which requires rxkad_crypt, but the only way to talk to 
such a server is to configure the client correctly -- it won't happen 
automatically.


In the future, accesses done with tokens will use rxgk.  This is a modern
security class based on the Kerberos crypto operations defined in
draft-ietf-krb-wg-crypto-07.txt (a Proposed Standard, currently in the
RFC Editor queue awaiting publication).  It provides authentication and
both data integrity and data confidentiality services on all connections, 
using any of a variety of ciphers.


Negotiation of the security class is slightly different, but still pretty 
simple.  The client proposes a security class, and if the server supports 
that class, the connection proceeds, and if not, it fails.  There is no way 
for a server to force use of a particular class, but it is likely that 
rxgk-capable cache managers will try rxgk first, and if that is unavailable 
either fail or fall back to rxkad, depending on local configuration.


>> - AFS/NFS translator for any one of Solaris, AIX or Linux.  I tried it on
>> Solaris 9 and encountered knfs issues as per bugid 1480.  Does it work
>> well on any of these three platforms now?
>
> cs.cmu.edu is using it on solaris 9, but perhaps not with authentication.
> linux and aix aren't supported now; i only ported to solaris (the ibm
> translator was not provided)

We run the translator on Solaris, but exported read-only and primarily to 
support installs.  We used to operate a full-service translator supporting 
knfs.  However, when we finally replaced it with modern hardware and 
software, we decided to discontinue the service due to lack of use.  So, we 
didn't even try this mode on OpenAFS.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA