XEP-0438: update to match draft-ietf-kitten-password-storage-01

Signed-off-by: Sam Whited <sam@samwhited.com>

xep-0438.xml

@@ -3,6 +3,7 @@
   <!ENTITY OWASP "the <span class='ref'><link url='https://owasp.org/'>Open Web Application Security Project (OWASP)</link></span> <note>The Open Web Application Security Project (OWASP, or OWASP Foundation) is a nonprofit foundation that works to improve the security of software. For further information, see &lt;<link url='https://owasp.org/'>https://owasp.org/</link>&gt;.</note>" >
   <!ENTITY owasppasswords "<span class='ref'><link url='https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html'>OWASP Password Storage Cheat Sheet</link></span> <note>OWASP Cheat Sheet Series for password storage &lt;<link url='https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html'>https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html</link>&gt;.</note>" >
   <!ENTITY rfc2195 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2195'>RFC 2195</link></span> <note>RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response &lt;<link url='http://tools.ietf.org/html/rfc2195'>http://tools.ietf.org/html/rfc2195</link>&gt;.</note>" >
+  <!ENTITY rfc5746 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5746'>RFC 5746</link></span> <note>RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension &lt;<link url='http://tools.ietf.org/html/rfc5746'>http://tools.ietf.org/html/rfc5746</link>&gt;.</note>" >
   <!ENTITY rfc7677 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7677'>RFC 7677</link></span> <note>RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms &lt;<link url='http://tools.ietf.org/html/rfc7677'>http://tools.ietf.org/html/rfc7677</link>&gt;.</note>" >
   <!ENTITY rfc8018 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8018'>RFC 8018</link></span> <note>RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 &lt;<link url='http://tools.ietf.org/html/rfc8018'>http://tools.ietf.org/html/rfc8018</link>&gt;.</note>" >
   <!ENTITY rfc8265 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8265'>RFC 8265</link></span> <note>RFC 8265: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords &lt;<link url='http://tools.ietf.org/html/rfc8265'>http://tools.ietf.org/html/rfc8265</link>&gt;.</note>" >
@@ -31,11 +32,17 @@
   <supersededby/>
   <shortname>passwords</shortname>
   &sam;
+  <revision>
+    <version>0.2.0</version>
+    <date>2020-10-30</date>
+    <initials>ssw</initials>
+    <remark><p>Update to match draft-ietf-kitten-password-storage-01.</p></remark>
+  </revision>
   <revision>
     <version>0.1.1</version>
     <date>2020-05-05</date>
     <initials>ssw</initials>
-    <remark><p>Fix reference to external document</p></remark>
+    <remark><p>Fix reference to external document.</p></remark>
   </revision>
   <revision>
     <version>0.1.0</version>
@@ -87,12 +94,30 @@
 </section1>
 <section1 topic='Glossary' anchor='glossary'>
   <p>
-    Many terms used in this document are defined in &nistsp800-63-3; Appendix
+    Various security-related terms are to be understood in the sense
-    A.1 and in &nistsp800-132; §3.1.
+    defined in &rfc4949;
+    Some may also be defined in defined in &nistsp800-63-3; Appendix A.1 and in
+    &nistsp800-132; §3.1.
+  </p>
+  <p>
     Throughout this document the term "password" is used to mean any password,
     passphrase, PIN, or other memorized secret.
   </p>
+  <p>
+    Other common terms used throughout this document include:
+  </p>
   <dl>
+    <di>
+      <dt>Mechanism Pinning</dt>
+      <dd>
+        Mechanism pinning A security mechanism which allows SASL clients to
+        resist downgrade attacks.
+        Clients that implement mechanism pinning remember the perceived strength
+        of the SASL mechanism used in a previous successful authentication
+        attempt and thereafter only authenticate using mechanisms of equal or
+        higher perceived strength.
+      </dd>
+    </di>
     <di>
       <dt>Pepper</dt>
       <dd>
@@ -101,6 +126,12 @@
         They must not be stored alongside the hashed password.
       </dd>
     </di>
+    <di>
+      <dt>Salt</dt>
+      <dd>
+        In this document salt is used as defined in &rfc4949;.
+      </dd>
+    </di>
   </dl>
 </section1>
 <section1 topic='SASL Mechanisms' anchor='required'>
@@ -166,6 +197,30 @@
       <li>PLAIN</li>
       <li>DIGEST-MD5, CRAM-MD5</li>
     </ol>
+    <p>
+      The EXTERNAL mechanism defined in &rfc4422; appendix A is placed at
+      the top of the list.
+      However, its perceived strength depends on the underlying authentication
+      protocol.
+      In this example, we assume that TLS (&rfc8446;) services are being used.
+    </p>
+    <p>
+      The channel binding ("-PLUS") variants of SCRAM (&rfc5802;) are listed
+      above their non-channel binding cousins, but may not always be
+      available depending on the type of channel binding data available to
+      the SASL negotiator.
+    </p>
+    <p>
+      The PLAIN mechanism sends the username and password in plain text,
+      but does allow for the use of a strong key derivation function (KDF)
+      for the stored version of the password on the server.
+    </p>
+    <p>
+      Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last
+      because they use weak hashes and ciphers and prevent the server from
+      storing passwords using a KDF.  For a list of problems with DIGEST-
+      MD5 see &rfc6331;.
+    </p>
   </section2>
   <section2 topic='Storage' anchor='client-storage'>
     <p>
@@ -200,7 +255,7 @@
   <section2 topic='Storage' anchor='server-storage'>
     <p>
       Servers MUST always store passwords only after they have been salted and
-      hashed.
+      hashed using a strong KDF.
       If multiple hashes are supported for use with SCRAM, for example
       SCRAM-SHA-1 and SCRAM-SHA-256, separate salted and hashed passwords SHOULD
       be calculated and stored for each mechanism so that users can log in with
@@ -216,6 +271,25 @@
       pepper stored in the application configuration, an environment variable,
       or some other location other than the datastore containing the salts.
     </p>
+    <p>
+      The following minimum restrictions MUST be observed when generating salts
+      and peppers.
+      More up to date numbers may be found in &owasppasswords;
+    </p>
+    <dl>
+      <di>
+        <dt>Minimum Salt Length</dt>
+        <dd>
+          16 bytes
+        </dd>
+      </di>
+      <di>
+        <dt>Minimum Pepper Length</dt>
+        <dd>
+          32 bytes
+        </dd>
+      </di>
+    </dl>
   </section2>
   <section2 topic='Authentication and Rotation' anchor='auth'>
     <p>
@@ -251,16 +325,16 @@
   </p>
   <dl>
     <di>
-      <dt>Minimum iterations</dt>
+      <dt>Minimum iteration count (c)</dt>
       <dd>10,000 (100,000 for higher security environments)</dd>
     </di>
     <di>
-      <dt>Minimum salt length</dt>
+      <dt>Hash</dt>
-      <dd>16 bytes</dd>
+      <dd>SHA256</dd>
     </di>
     <di>
-      <dt>Minimum pepper length</dt>
+      <dt>Output length (dkLen)</dt>
-      <dd>32 bytes</dd>
+      <dd>hLen (length of the chosen hash)</dd>
     </di>
   </dl>
   <p>
@@ -270,17 +344,34 @@
 </section1>
 <section1 topic='Password Complexity Requirements' anchor='passwordcomplexity'>
   <p>
-    Clients and servers SHOULD enforce a minimum length of 8 characters for user
+    Before any other password complexity requirements are checked, the
-    passwords.
+    preparation and enforcement steps of the OpaqueString profile of &rfc8265;
+    SHOULD be applied (for more information see the Internationalization
+    Considerations section).
+    Entities SHOULD enforce a minimum length of 8 characters for user passwords.
     If using a mechanism such as PLAIN where the server performs hashing on the
     original password, a maximum length between 64 and 128 characters MAY be
     imposed to prevent denial of service (DoS) attacks.
-    Passwords SHOULD be required to conform to the Opaque String profile of
+    Entities SHOULD NOT apply any other password restrictions.
-    &rfc8265;.
+  </p>
-    No other password restrictions should be applied.
+  <p>
+    In addition to these password complexity requirements, servers SHOULD
+    maintain a password blocklist and reject attempts by a claimant to use
+    passwords on the blocklist during registration or password reset.
+    The contents of this blocklist are a matter of server policy.
+    Some common recommendations include lists of common passwords that are not
+    otherwise prevented by length requirements, and passwords present in known
+    breaches.
   </p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
+  <p>
+    This document contains recommendations that are likely to change over time.
+    It should be reviewed regularly to ensure that it remains accurate and up to
+    date.
+    Many of the recommendations in this document were taken from
+    &owasppasswords;, &nistsp800-63b;, and &nistsp800-132;.
+  </p>
   <p>
     The SCRAM suite of SASL mechanisms are recommended in this document,
     however, there is currently no way to force a password reset.
@@ -288,6 +379,22 @@
     that new, untested, SCRAM-based or SCRAM-like mechanisms should be added
     with caution.
   </p>
+  <p>
+    The "-PLUS" variants of SCRAM support channel binding to their underlying
+    security layer, but lack a mechanism for negotiating what type of channel
+    binding to use.
+    In &rfc5802; the tls-unique (&rfc5929;) channel
+    binding mechanism is specified as the default, and it is therefore likely to
+    be used in most applications that support channel binding.
+    However, in the absence of the TLS extended master secret fix (&rfc7627;)
+    and the renegotiation indication TLS extension (&rfc5746;) the tls-unique
+    and tls-server-endpoint channel binding data can be forged by an attacker
+    that can MITM the connection.
+    Before advertising a channel binding SASL mechanism, entities MUST ensure
+    that both the TLS extended master secret fix and the renegotiation
+    indication extension are in place and that the connection has not been
+    renegotiated.
+  </p>
   <p>
     This document mentions many hash functions that are already in
     use in the XMPP ecosystem, or that have been used in the past.
@@ -297,11 +404,28 @@
     implications, see &xep0414;
   </p>
   <p>
-    This document contains recommendations that are likely to change over time.
+    For TLS 1.3 no channel binding types are currently defined. Channel binding
-    It should be reviewed yearly to ensure that it remains accurate and up to
+    SASL mechanisms MUST NOT be advertised or negotiated over a TLS 1.3 channel
-    date.
+    until such types are defined.
-    Many of the recommendations in this document were taken from the
+  </p>
-    &owasppasswords;, which can be used as a reference when making updates.
+</section1>
+<section1 topic='Internationalization Considerations' anchor='security'>
+  <p>
+    The PRECIS framework (Preparation, Enforcement, and Comparison of
+    Internationalized Strings) defined in &rfc8264; is used to enforce
+    internationalization rules on strings and to prevent common application
+    security issues arrising from allowing the full range of Unicode codepoints
+    in usernames, passwords, and other identifiers.
+    The OpaqueString profile of &rfc8265; is used in this document to ensure
+    that codepoints in passwords are treated carefully and consistently.
+    This ensures that users typing certain characters on different keyboards
+    that may provide different versions of the same character will still be able
+    to log in.
+    For example, some keyboards may output the full-width version of a character
+    while other keyboards output the half-width version of the same character.
+    The Width Mapping rule of the OpaqueString profile addresses this and
+    ensures that comparison succeeds and the claimant is able to be
+    authenticated.
   </p>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>