Link to the quickstart page.

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

diff --git a/doc/kerberized-server.mdwn b/doc/kerberized-server.mdwn
index 953075953a64d85c459f6e9734cb74abbd1a3a3f..02319072344267360b3a18160c6a4d3454694be6 100644 (file)
--- a/doc/kerberized-server.mdwn
+++ b/doc/kerberized-server.mdwn
@@ -15,6 +15,9 @@ and then **set a new (random) key**.
     # k5srvutil change
     # k5srvutil delold
 
     # 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
 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,7 +41,7 @@ later add get this file by default.)
 
 ## Upgrading cryptographic strength
 
 
 ## 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`:
 
 
 To change the supported enctypes, run `kadmin`:
 


@@ -46,7 +49,7 @@ To change the supported enctypes, run `kadmin`:
 
 From within `kadmin`, to 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. If there are no outstanding tickets, you can do this from within `kadmin`:
 
 
 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`: