Hi Jeffrey,
​
Thanks for the clarification.
In my case this will be a new installation so no clients < 1.6.5 will be seen on the cell ever (1.6.5 is part of SL distribution and may be used occasionally). I hope this won't be an issue.
Public service isn't planned by now.
​
Martin
​
​
On Thu, 31 Jul 2014 10:39:12 -0400
 Jeffrey Altman <jalt...@your-file-system.com> wrote:
On 7/31/2014 10:18 AM, Brandon Allbery wrote:
On Thu, 2014-07-31 at 16:12 +0200, Martin Richter wrote:
So this means that client caching can't be used anymore after DES has
been removed from the KDC?
​
No; rxkad-kdf derives a DES key from a stronger key. Also clients still
default to no encryption in the cache manager (fs setcrypt).
​
This is only true for UNIX cache managers.   Windows default to "fs
setcrypt on".
Just
pointing out that (weaker-than-)DES is still used in some places,
​
Weaker than DES (the fcrypt encryption algorithm or no encryption at
all) is used in *all* places.  The use of AES256-SHA1 is only for
Kerberos authentication and protection of the long term AFS service
principal key.  AES256 is never used for wire privacy or integrity
protection within the AFS protocol.
​
However, I believe Martin is asking a different question.
​
 When the issuance of service tickets with DES session keys is
 turned off in the KDC, can existing AFS cache managers that do
 not support "rxkad-kdf" continue to access the AFS cell?
​
The answer to this question is "no".  If an older AFS client, say
OpenAFS 1.4.11 or 1.6.3 attempts to obtain an AFS token it will request
the use of DES for the session key.  The KDC (if DES is disabled) will
either fail the request indicating that there is no support for the
DES-CBC-CRC encryption type or will issue a service ticket with a
non-DES session key and a failure will be reported by the client-side
Kerberos library.   In either case, the older AFS client will be unable
to authenticate to the cell.
​
Jeffrey Altman
​
​
​
​

Reply via email to