[OpenAFS] Encryption of traffic

[Marcus Watts]

   Jason Edgecombe <jason@rampaginggeek.com> writes:
> Date:    Tue, 26 Jun 2007 18:47:56 EDT
> To:      Russ Allbery <rra@stanford.edu>
> cc:      openafs-info@openafs.org
> From:    Jason Edgecombe <jason@rampaginggeek.com>
> Subject: Re: [OpenAFS] Encryption of traffic
> 
> Russ Allbery wrote:
> > 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.
> >
> >   
> ok, dumb question time.
> 
> Would using ASN.1 be more of a pain than helpful? I only say this 
> because I read in the O'Reilly kerberos book that Krb5 uses ASN.1 to 
> "future-proof" the encryption stuff and the protocol in general. I know 
> nothing about ASN.1 besides that it's use by Kerb5, SNMP, and a few others.
> 
> Sincerely,
> Jason Edgecombe

Using asn.1 is more of a pain than helpful.  It's just a data marshalling
protocol - a way to translate in-memory binary structures into an
octet stream that can be shared at wire level with other hardware
implementations that may have very significant internal binary variation.
As such, asn.1 would shine if we wanted to past-proof ourselves to
make code to run hardware derived from the IBM 7080, GE 645, DEC PDP-6,
and univac 1103A.  It's a complicated algorithm because of this need;
every integer that gets shipped across the wire has its length encoded,
there are multiple ways to ship character strings around, and this
creates interesting annoying problems like how to handle or test outsized
integers, weird foreign character encodings, and other features of the
protocol.  Asn.1 does win in one regard however; it can handle optional
data quite well.

OpenAFS is not likely to run on hardware platforms derived from any of
those past machines.  It is likely to only ever run on machines that have
binary 2's complement arithmetic, memory addressible in units of 8 bit
octets, and said memory can be aggregated on natural boundaries to small
power of 2 multiples of octets (2,4,8), with memory addresses consisting
of 32 or 64-bit address pointers pointing to the lowest address byte
of a word in memory - and said machine uses or at least doesn't fight
the idea of using ascii text encoding.  On these platforms, there is a
much simpler data marshalling protocol, sun xdr.  It's been around for a
long time, & it's already in use in most of AFS.  rxk5 uses xdr to deal
with its own local data marshalling needs, such as creating a challenge.
This does not completely eliminate asn.1 from the rxk5 world, because
kerberos 5 does use it.  However, it's quite possible to support all the
present encryption types of kerberos, and probably any future ones that
might reasonably be invented, without making any *extra* use of asn.1.
This is what precisely what rxk5 does.

rxgk as I understand it does make extra use of asn.1.  This is intended to
provide additional protocol flexibility at the cost of requiring a more
complicated protocol negotiation phase, fortunately also part of rxgk.
I believe rxgk may be capable of negotiating the use of packet level
cryptographic algorithms that might not be supported by either kerberos
5 or gssapi.  My knowledge may be outdated or just plain wrong here,
so don't quote me without checking elsewhere first.

				-Marcus Watts