[OpenAFS] Help rekeying cell when both service principals (afs@REALM and afs/cell@REALM) exist

Kim Kimball dhk@ccreinc.com
Thu, 21 Nov 2013 10:38:22 -0700


> It is only worth mentioning in this context because I know how old the
> systems involved are.

There may still be some Solaris 7 instances -- "ancient" was an apt description.
  

On 11/21/2013 9:49 AM, Jeffrey Altman wrote:
> On 11/21/2013 11:39 AM, Jeffrey Hutzelman wrote:
>>> The other thing that Kim needs to test given the age of the clients is
>>> whether or not any of them suffer from an old bug that would result in
>>> an out of bounds array access if the service enctype has a value that is
>>> not recognized by the client.  If so, it may not be possible to deploy
>>> AES256-SHA1 enctypes.
>> Uh, I'm not aware of any such bug.  Can you provide a reference?
>> There _is_ a bug which could result in an out-of-bounds array access if
>> the returned token is too large, which could happen for some enctypes.
>> However, this is relatively unlikely if your client principal names
>> aren't too big.  We designed rxkad-2b such that everything would fit
>> within the smaller limit even with maximal-size client principal names,
>> but that was using DES, and the block size for the AES enctypes is
>> larger.
> Early MIT Kerberos and CyberSafe had this bug.  Oracle's Kerberos that
> forked form MIT Krb5 1.0 Alpha inherited this bug.  I don't know when it
> was fixed but the fix was probably around the time that Windows 2000
> showed up because of their negative enctype values.
>
> Java had this bug until 1.4.
>
> It is only worth mentioning in this context because I know how old the
> systems involved are.
>
> Jeffrey Altman
>
>