From: Greg Hudson Date: Thu, 14 Jun 2018 21:51:43 +0000 (-0400) Subject: Add documentation on dictionary attacks X-Git-Tag: krb5-1.17-beta1~93 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=93204537f12ef6b7de86d9a82423bcacc2005537;p=thirdparty%2Fkrb5.git Add documentation on dictionary attacks ticket: 8694 (new) --- diff --git a/doc/admin/dictionary.rst b/doc/admin/dictionary.rst new file mode 100644 index 0000000000..a5c5786872 --- /dev/null +++ b/doc/admin/dictionary.rst @@ -0,0 +1,88 @@ +.. _dictionary: + +Addressing dictionary attack risks +================================== + +Kerberos initial authentication is normally secured using the client +principal's long-term key, which for users is generally derived from a +password. Using a pasword-derived long-term key carries the risk of a +dictionary attack, where an attacker tries a sequence of possible +passwords, possibly requiring much less effort than would be required +to try all possible values of the key. Even if :ref:`password policy +objects ` are used to force users not to pick trivial +passwords, dictionary attacks can sometimes be successful against a +significant fraction of the users in a realm. Dictionary attacks are +not a concern for principals using random keys. + +A dictionary attack may be online or offline. An online dictionary +attack is performed by trying each password in a separate request to +the KDC, and is therefore visible to the KDC and also limited in speed +by the KDC's processing power and the network capacity between the +client and the KDC. Online dictionary attacks can be mitigated using +:ref:`account lockout `. This measure is not totally +satisfactory, as it makes it easy for an attacker to deny access to a +client principal. + +An offline dictionary attack is performed by obtaining a ciphertext +generated using the password-derived key, and trying each password +against the ciphertext. This category of attack is invisible to the +KDC and can be performed much faster than an online attack. The +attack will generally take much longer with more recent encryption +types (particularly the ones based on AES), because those encryption +types use a much more expensive string-to-key function. However, the +best defense is to deny the attacker access to a useful ciphertext. +The required defensive measures depend on the attacker's level of +network access. + +An off-path attacker has no access to packets sent between legitimate +users and the KDC. An off-path attacker could gain access to an +attackable ciphertext either by making an AS request for a client +principal which does not have the **+requires_preauth** flag, or by +making a TGS request (after authenticating as a different user) for a +server principal which does not have the **-allow_svr** flag. To +address off-path attackers, a KDC administrator should set those flags +on principals with password-derived keys:: + + kadmin: add_principal +requires_preauth -allow_svr princname + +An attacker with passive network access (one who can monitor packets +sent between legitimate users and the KDC, but cannot change them or +insert their own packets) can gain access to an attackable ciphertext +by observing an authentication by a user using the most common form of +preauthentication, encrypted timestamp. Any of the following methods +can prevent dictionary attacks by attackers with passive network +access: + +* Enabling :ref:`SPAKE preauthentication ` (added in release + 1.17) on the KDC, and ensuring that all clients are able to support + it. + +* Using an :ref:`HTTPS proxy ` for communication with the KDC, + if the attacker cannot monitor communication between the proxy + server and the KDC. + +* Using FAST, protecting the initial authentication with either a + random key (such as a host key) or with :ref:`anonymous PKINIT + `. + +An attacker with active network access (one who can inject or modify +packets sent between legitimate users and the KDC) can try to fool the +client software into sending an attackable ciphertext using an +encryption type and salt string of the attacker's choosing. Any of the +following methods can prevent dictionary attacks by active attackers: + +* Enabling SPAKE preauthentication and setting the + **disable_encrypted_timestamp** variable to ``true`` in the + :ref:`realms` subsection of the client configuration. + +* Using an HTTPS proxy as described above, configured in the client's + krb5.conf realm configuration. If :ref:`KDC discovery + ` is used to locate a proxy server, an active + attacker may be able to use DNS spoofing to cause the client to use + a different HTTPS server or to not use HTTPS. + +* Using FAST as described above. + +If :ref:`PKINIT ` or :ref:`OTP ` are used for +initial authentication, the principal's long-term keys are not used +and dictionary attacks are usually not a concern. diff --git a/doc/admin/index.rst b/doc/admin/index.rst index fbe5e42e3b..d87b003ae9 100644 --- a/doc/admin/index.rst +++ b/doc/admin/index.rst @@ -17,6 +17,7 @@ For administrators pkinit.rst otp.rst spake.rst + dictionary.rst princ_dns.rst enctypes.rst https.rst diff --git a/doc/admin/lockout.rst b/doc/admin/lockout.rst index c7e4e33a48..446b91d3ea 100644 --- a/doc/admin/lockout.rst +++ b/doc/admin/lockout.rst @@ -1,3 +1,5 @@ +.. _lockout: + Account lockout =============== diff --git a/doc/admin/spake.rst b/doc/admin/spake.rst index 4f6eeaf53d..8b9f4710cd 100644 --- a/doc/admin/spake.rst +++ b/doc/admin/spake.rst @@ -1,12 +1,14 @@ +.. _spake: + SPAKE Preauthentication ======================= SPAKE preauthentication (added in release 1.17) uses public key -cryptography techniques to protect against password dictionary -attacks. Unlike :ref:`PKINIT `, it does not require any -additional infrastructure such as certificates; it simply needs to be -turned on. Using SPAKE preauthentication may modestly increase the -CPU and network load on the KDC. +cryptography techniques to protect against :ref:`password dictionary +attacks `. Unlike :ref:`PKINIT `, it does not +require any additional infrastructure such as certificates; it simply +needs to be turned on. Using SPAKE preauthentication may modestly +increase the CPU and network load on the KDC. SPAKE preauthentication can use one of four elliptic curve groups for its password-authenticated key exchange. The recommended group is