[OpenAFS] OpenAFS 1.6.5 on OSX

[Benjamin Kaduk]

On Mon, 27 Apr 2015, Jeffrey Altman wrote:

>
> 1. OpenAFS has an obligation to provide backward compatibility with IBM
> AFS 3.6 rxkad as long as it wishes to use the name.

aklog.c bears no IBM copyright, and was not present in AFS 3.6.
In the absence of evidence to the contrary, such as a written AFS mark
agreement, I am forced to conclude that aklog functionality is not subject
to the compatibility restriction.

> 2. Frustrating end users who have no control over their cell
> administrators will not result in sites having an incentive to upgrade
> their cells.

Well, unless someone steps forward to write some more complex guessing
logic, we either frustrate end users in weak cells or frustrate end users
on newer OS X.  I am not in a position to write that logic, and when thus
forced to make the choice, I choose the number which will be increasing
with time over the number which ought to be decreasing over time.

> 3. Breaking one platform is not fair.  If OpenAFS is going to break
> compatibility it should do so for all platforms.

Hrrm?  One platform is already broken; I propose only shifting around
brokenness.

> 4. aklog requires DES support for session keys to use with fcrypt.

It would be helpful to distinguish between AFS session keys (must be
56-bit-plus-parity) and Kerberos session keys (which do not, given
rkad-kdf).  We carefully wrote the server such that it is impossible for
the server to support rxkad-k5 and not rxkad-kdf, which is somewhat
relevant here.

> There is no additional strength obtained from a 56-bit key plus parity
> derived from an AES256 session key than from the use of a DES session
> key without derivation.  Either way the rxkad challenge-response is
> using a 56-bit key and the wire privacy is using fcrypt.

The case in question here is where the local krb5 library just plain has
no 1DES support, period; the only way to get functional AFS is to use
aklog with rxkad-kdf, or kauth.

> I see no justification for intentionally breaking the use of DES session
> keys on OS platforms that still support it.

I am framing it as a choice between supporting OS X variants which do not
support DES keys at all (in krb5), and supporting old OSX variants which
do support DES session keys but have no functional programmatic way to
enable the use of weak crypto.  You are free to reject my framing of the
question, but please provide an alternate one in its stead.

-Ben