Change "other protocols" section to more general infrastructure recommendations
authorAlexander Wuerstlein <arw@arw.name>
Sun, 2 Feb 2014 19:26:15 +0000 (20:26 +0100)
committerAlexander Wuerstlein <arw@arw.name>
Sun, 2 Feb 2014 19:26:15 +0000 (20:26 +0100)
src/practical_settings/kerberos.tex

index 8e50689..f8c38cd 100644 (file)
@@ -16,22 +16,35 @@ The Kerberos protocol over time has been extended with a variety of extensions a
 
 Only the Kerberos 5 protocol and implementation will be discussed. Kerberos 4 is obsolete, insecure and its use is strongly discouraged.
 
-\subsubsection{Relations to other Protocols}
-\label{subsubsection:kerberos_relation_to_other_protocols}
+\subsubsection{Providing a suitable Setup for secure Kerberos Operations}
+\label{subsubsection:kerberos_secure_setup}
 
-\paragraph{DNS considerations}
-Kerberos relies on a trustworthy DNS infrastructure. The identity of a service is tied to its DNS name, similarly the realm a client belongs to as well as the KDC, kpasswd and kerberos-adm servers may be specified in DNS TXT and SRV records. Spoofed DNS entries will cause denial-of-service situations and might endanger the security of a Kerberos realm.
+The aim of Kerberos is to unify authentication across a wide range of services, for many different users and use cases and on many computer platforms. The resulting complexity and attack surface make it necessary to carefully plan and continuously evaluate the security of the overall ecosystem in which Kerberos is deployed. Several assumptions are made on which the security of a Kerberos infrastructure relies:
+\begin{itemize}
+       \item Every KDC in a realm needs to be trustworthy. The KDC's principal database must not become known to or changed by an attacker. The contents of the principal database enables the attacker to impersonate any user or service in the realm.
+       \item Synchronisation between KDCs must be secure, reliable and frequent. An attacker that is able to intercept or influence synchronisation messages obtains or influences parts of the principal database, enabling impersonation of affected principals. Unreliable or infrequent synchronisation enlarges the window of vulnerability after disabling principals or changing passwords that have been compromised or lost.
+       \item KDCs must be available. An attacker is able to inhibit authentication for services and users by cutting off their access to a KDC.
+       \item Users' passwords must be secure. Since Kerberos is a single-sign-on mechanism, a single password may enable an attacker to access a large number of services.
+       \item Service keytabs need to be secured against unauthorized access similarly to SSL/TLS server certificates. Obtaining a service keytab enables an attacker to impersonate a service.
+       \item DNS infrastructure must be secure and reliable. Hosts that provide services need consistent forward and reverse DNS entries. Especially avoid LDAP replication and database backends. LDAP enlarges the attack surface of your KDC and facilitates unauthorized access to the principal database e.g. by ACL misconfiguration. The identity of a service is tied to its DNS name, similarly the realm a client belongs to as well as the KDC, kpasswd and kerberos-adm servers may be specified in DNS TXT and SRV records. Spoofed DNS entries will cause denial-of-service situations and might endanger the security of a Kerberos realm.
 % "might endanger" according to the following source:
 % http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html
 % unfortunately no further details beyond the suspicion of vulnerability are provided
 % mentions possible redirection to a compromised realm in setups with trust relations: http://www.ietf.org/proceedings/48/I-D/cat-krb-dns-locate-02.txt
+       \item Clients and servers in Kerberos realms need to have synchronized clocks. Tickets in Kerberos are created with a limited, strictly enforced lifetime. This limits an attacker's window of opportunity for various attacks such as the decryption of tickets in sniffed network traffic or the use of tickets read from a client computer's memory. Kerberos will refuse tickets with old timestamps or timestamps in the future. This would enable an attacker with access to a systems clock to deny access to a service or all users logging in from a specific host.
+\end{itemize}
 
-Therefore it is strongly recommended to use DNSSEC. \todo{link to DNSSEC section as soon as there is one} If that is not possible, at least ensure that all servers and clients in a realm use a trustworthy DNS server contacted via secure network links.
-
-\paragraph{NTP considerations}
-Tickets in Kerberos are created with a limited, strictly enforced lifetime. This limits an attacker's window of opportunity for various attacks such as the decryption of tickets in sniffed network traffic or the use of tickets read from a client computer's memory.
-
-It is therefore necessary that all clients and servers agree on the current time. It is recommended to use NTP on a trustworthy server via secure network links. \todo{link to NTP section as soon as there is one}
+Therefore we suggest:
+\begin{itemize}
+       \item Secure all KDCs at least as strongly as the most secure service in the realm.
+       \item Dedicate physical (i.e. non-VM) machines to be KDCs. Do not run any services on those machines beyond the necessary KDC, kerberos-adm, kpasswd and kprop services. 
+       \item Restrict physical and administrative access to the KDCs as severely as possible. E.g. ssh access should be limited to responsible adminstrators and trusted networks. 
+       \item Encrypt and secure the KDCs backups.
+       \item Replicate your primary KDC to at least one secondary KDC.
+       \item Prefer easy-to-secure replication (propagation in Kerberos terms) methods.
+       \item It is strongly recommended to use DNSSEC. \todo{link to DNSSEC section as soon as there is one} If that is not possible, at least ensure that all servers and clients in a realm use a trustworthy DNS server contacted via secure network links.
+       \item It is recommended to use NTP on a trustworthy server via secure network links. \todo{link to NTP section as soon as there is one}
+\end{itemize}
 
 \subsection{Implementations}
 \label{subsection:kerberos_implementations}