Update IS&T keytab request form link

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

diff --git a/doc/kerberized-server.mdwn b/doc/kerberized-server.mdwn
index 96d07673821e6ee9b745d351ca5f57a792068b47..47a338770541dfc0e35eec955183dcae323cb43f 100644 (file)
--- a/doc/kerberized-server.mdwn
+++ b/doc/kerberized-server.mdwn
@@ -2,19 +2,22 @@
 
 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
 `/mit/accounts/srvtabs/FOR_YOURUSERNAME`, which is AFS and vaguely
 insecure.  You probably want to install it in `/etc/krb5.keytab`,
-and then set a new (random) key.
+and then **set a new (random) key**.
 
     # mv -f /etc/krb5.keytab /etc/krb5.keytab.old  # back up any keytab you already have
     # mv /mit/accounts/srvtabs/FOR_JOEUSER/joeserver-new-keytab /etc/krb5.keytab
     # 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
@@ -35,3 +38,24 @@ matches; that is to say, an Athena user whose username matches a local
 username can log in to that local account.  (One option to avoid this is
 to create a `.k5login` file in `/etc/skel` so that new accounts you
 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 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
+
+From within `kadmin`, to create new keys:
+
+    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. If there are no outstanding tickets, you can do this from within `kadmin`:
+
+    ktremove -k daemon.kronborg.keytab daemon/kronborg.mit.edu old
+
+Before exiting, you may wish to verify in a separate terminal that the correct updated key has been written to the keytab:
+
+    kinit -k -t daemon.kronborg.keytab daemon/kronborg.mit.edu
+    kvno daemon/kronborg.mit.edu@ATHENA.MIT.EDU