[OpenAFS] OpenAFS 1.6.5 on OSX

[D Brashear]

> On Apr 27, 2015, at 8:40 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>=20
>> On Mon, 27 Apr 2015, Jeffrey Altman wrote:
>>=20
>>=20
>> 1. OpenAFS has an obligation to provide backward compatibility with IBM
>> AFS 3.6 rxkad as long as it wishes to use the name.
>=20
> 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.
>=20
>> 2. Frustrating end users who have no control over their cell
>> administrators will not result in sites having an incentive to upgrade
>> their cells.
>=20
> 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. =20

Only the ones building from source. I compile against and ship Heimdal. Patc=
h what you like, I'll carry a local patch and simply frustrate no one but my=
self.=20

> 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.
>=20
>> 3. Breaking one platform is not fair.  If OpenAFS is going to break
>> compatibility it should do so for all platforms.
>=20
> Hrrm?  One platform is already broken; I propose only shifting around
> brokenness.


>=20
>> 4. aklog requires DES support for session keys to use with fcrypt.
>=20
> 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.
>=20
>> 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.
>=20
> 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.
>=20
>> I see no justification for intentionally breaking the use of DES session
>> keys on OS platforms that still support it.
>=20
> 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.
>=20
> -Ben