2024 update

[wiki.git] / doc / kerberized-server.mdwn

diff --git a/doc/kerberized-server.mdwn b/doc/kerberized-server.mdwn
index bb36f93446d14633f08df7a96fd0b0119546a8ba..47a338770541dfc0e35eec955183dcae323cb43f 100644 (file)
--- a/doc/kerberized-server.mdwn
+++ b/doc/kerberized-server.mdwn
@@ -2,7 +2,7 @@
 
 If you want kerberized logins on a server you run, you'll need a
 *keytab* from accounts.  Fill out the
-[keytab request form](http://web.mit.edu/accounts/www/srvtabform.html),
+[keytab request form](https://ist.mit.edu/accounts/keytab),
 which sends them an e-mail.
 
 Your new keytab will be in
@@ -15,6 +15,9 @@ and then **set a new (random) key**.
     # k5srvutil change
     # k5srvutil delold
 
+Note that the `k5srvutil` command will also generate keys for the 3DES and RC4 ciphers, which are considered weak.
+You are strongly advised to read the "Upgrading cryptographic strength" section below on how to generate only AES keys instead.
+
 If you're using Debathena, you can install the `debathena-ssh-server-config` package to configure Kerberos authentication on the server side. If not, make sure your `/etc/ssh/sshd_config` file includes the lines
 
     GSSAPIAuthentication yes
@@ -38,17 +41,17 @@ later add get this file by default.)
 
 ## Upgrading cryptographic strength
 
-You may wish to change the encryption algorithms (*enctypes*) included in your keytab. With server principals (like `daemon/servername.mit.edu` or `host/servername.mit.edu`) it is particularly important to support *only* strong algorithms. If you support a weak algorithm, an attacker can request a service ticket encrypted with that key, allowing them to do an offline attack and potentially extract your secret key.
+You may wish to change the encryption algorithms (*enctypes*) included in your keytab. With server principals (like `daemon/servername.mit.edu` or `host/servername.mit.edu`) it is particularly important to support *only* strong algorithms. If you support a weak algorithm, an attacker can request an initial ticket encrypted with that key, allowing them to do an offline attack and potentially extract the secret key.
 
 To change the supported enctypes, run `kadmin`:
 
     kadmin -p daemon/kronborg.mit.edu  -k -t daemon.kronborg.keytab
 
-Then, create new keys:
+From within `kadmin`, to create new keys:
 
-    ktadd -k daemon.kronborg.keytab -e aes256-cts:normal -e aes128-cts:normal daemon/kronborg.mit.edu
+    ktadd -k daemon.kronborg.keytab -e aes256-cts:normal,aes128-cts:normal daemon/kronborg.mit.edu
 
-After all tickets currently issued against your service expire (which will happen after at most one day), you should remove the old keys from your keytab:
+After all tickets currently issued against your service expire (which will happen after at most one day), you should remove the old keys from your keytab. If there are no outstanding tickets, you can do this from within `kadmin`:
 
     ktremove -k daemon.kronborg.keytab daemon/kronborg.mit.edu old