[OpenAFS] Encryption of traffic

[Marcus Watts]

> Date:    Tue, 26 Jun 2007 09:39:13 PDT
> To:      Katrine Svendsen <kat_svendsen@hotmail.com>
> cc:      <openafs-info@openafs.org>
> From:    Russ Allbery <rra@stanford.edu>
> Subject: Re: [OpenAFS] Encryption of traffic
> 
> Katrine Svendsen <kat_svendsen@hotmail.com> writes:
> 
> > I'm trying to find some details about the traffic encryption between an
> > AFS client and server (fs setcrypt on/off), but this seems to be very
> > difficult.I would like to know about such things as keylength, mode of
> > operation, key generation/distribution etc. Does anybody have a good
> > source for this?
> 
> AFS uses an encryption method called fcrypt, which is a modified DES.
> Google for fcrypt will return a lot of hits, although I don't know if any
> of them have detailed analyses.  This encryption method is fairly obsolete
> at this point.
> 
> > It also seems to me that not too much have happened in this field (when
> > considering AFS) the last years. Am I right when I think that the
> > network traffic-encryption in AFS is somewhat "ancient"? Why is there
> > not more focus on this?
> 
> On the contrary, this is our top development priority apart from keeping
> things generally working, and is the focus of both the rxk5 and rxgk
> work.  The difficulty is that replacing the encryption algorithm in AFS
> requires substantial protocol changes and ideally one wants to generalize
> the encryption layer and support all GSSAPI encryption types at the same
> time, as well as provide a framework for stronger authentication in
> general.
> 
> Both rxk5 and rxgk have made substantial progress in the past year.
> 
> -- 
> Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

Fcrypt is described here:
	http://surfvi.com/~ota/fcrypt-paper.txt
it was probably obselete when deployed; its only real advantage is speed.
It's used in cbc mode, and there's some sort of not terribly convincing
checksum algorithm happening as well.  AFS also supports "integrity
without privacy" (rxkad_auth), which does not encrypt the payload but can
detect changes, and "rxkad_clear", which is what you get for fileserver
traffic if you say "fs setcrypt off".

As designed and originally deployed, AFS used kerberos 4 - DES + pcbc.
There are lots of references out there for kerberos 4 & pcbc.  AFS uses
the des session key straight with fcrypt; there's no further key
generation happening.

Current distributions of AFS also support kerberos 5 - but only with DES.
That is the service key & the session key must both be DES.  The rest of rxkad
works exactly as before.

A patch for rxk5 is here:
/afs/umich.edu/group/itd/build/mdw/openafs/patches/afs-rxk5-r1518-m50.patch.bz2
it adds in support for kerberos 5 with mit or heimdal, and supports current
kerberos 5 encryption types.  The token interface between the kernel & userland
will change slightly shortly (at the request of the rxgk folks), and there
is still some other cleanup to happen.  rxk5 generates a different key for each
packet sent & received, and uses straight kerberos 5 encryption protocols
to either encrypt (rxk5_crypt) or do integrity but no privacy (rxk5_auth).
rxk5 does not by default support "no integrity" (rxk5_clear) and the small bits
of the fileserver & cache manager that known about this select rxk5_auth
for rxk5 in place of rxkad_clear for rxkad.

Help, I'm being dragged off to a meeting!  Hope this helps...

				-Marcus Watts