> On Apr 27, 2015, at 8:40 AM, Benjamin Kaduk <[email protected]> wrote:
>
>> 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.
Only the ones building from source. I compile against and ship Heimdal. Patch
what you like, I'll carry a local patch and simply frustrate no one but myself.
> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
