add section about changing enctypes

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

diff --git a/doc/kerberized-server.mdwn b/doc/kerberized-server.mdwn
index 0aee6cb159245050cb205aa2ab854c4b9d286266..bb36f93446d14633f08df7a96fd0b0119546a8ba 100644 (file)
--- a/doc/kerberized-server.mdwn
+++ b/doc/kerberized-server.mdwn
@@ -3,19 +3,19 @@
 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),
-which sends them an e-mail.  Ask for a "keytab"; by default they'll
-give you a srvtab, the Kerberos 4 analogue.
+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 randomize the 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
 
-Then make sure your `/etc/ssh/sshd_config` file includes the lines
+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
     GSSAPIKeyExchange yes
@@ -23,18 +23,36 @@ Then make sure your `/etc/ssh/sshd_config` file includes the lines
 This will let you SSH in with Kerberos.
 
 Then create a file called `.k5login` in the home directory of
-whichever users you want to be able log into with Kerberos. List the
+whichever users you want to be able to log into with Kerberos. List the
 full Kerberos principal of each user, one per line (e.g.,
 `joeuser@ATHENA.MIT.EDU`)
 
-## Dealing with srvtabs
+If you don't want it to be possible to log in to a user account via
+Kerberos, create an empty `.k5login` file in their home directory.
+Otherwise, by default, you can log in to a user account with a Kerberos
+principal from the default realm (ATHENA, presumably) whose username
+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.)
 
-If you don't specifically mention a "keytab" in your request to
-Accounts, they may give you the Kerberos 4 equivalent, a srvtab.
+## Upgrading cryptographic strength
 
-In this case you'll want to convert the srvtab to a keytab, like so.
+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.
 
-    $ ktutil
-    ktutil: rst /mit/accounts/srvtabs/FOR_JOEUSER/joeserver-new-srvtab
-    ktutil: wkt /etc/krb5.keytab
-    ktutil: q
+To change the supported enctypes, run `kadmin`:
+
+    kadmin -p daemon/kronborg.mit.edu  -k -t daemon.kronborg.keytab
+
+Then, create new keys:
+
+    ktadd -k daemon.kronborg.keytab -e aes256-cts:normal -e 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:
+
+    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