Rendering edits (usnistgov#17)

* Update text on biometrics types

* Markdown rendering corrections

* Additional rendering correction

* Add reference timestamps to cover pages

* Port issue template from master branch

* Correct location of cover page logos

* Remove sidebar from homepage, add links at top

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,14 @@
+**Organization**:
+
+**Type**:
+
+**Reference (Include section and paragraph number)**:
+
+**Comment (Include rationale for comment)**:
+
+**Suggested Change**:
+
+---
+
+Organization: 1 = Federal, 2 = Industry, 3 = Other 
+

index.md

@@ -1,5 +1,5 @@
 ---
-layout: page
+layout: cover
 title: "NIST SP 800-63-3 Digital Authentication Guideline"
 description: "Public Preview for NIST Special Publication: SP 800-63-3 Digital Authentication Guideline"
 ---
@@ -12,6 +12,33 @@ description: "Public Preview for NIST Special Publication: SP 800-63-3 Digital A
 <div class="section-container" markdown="1">
 <div class="section-content" markdown="1">
 
+<ul class="audiences">
+<li>
+  <div>
+    <a href="sp800-63-3.html"><img src="assets/800_63_3_doc.png" alt="SP 800-63-3" width="150px" height="150px"></a>
+  </div>
+  <h3><a href="sp800-63-3.html">SP 800-63-3</a></h3>
+</li>
+<li>
+  <div>
+    <a href="sp800-63a.html"><img src="assets/800_63_3_Proofing.png" alt="SP 800-63A" width="150px" height="150px"></a>
+  </div>
+  <h3><a href="sp800-63a.html">SP 800-63A</a></h3>
+</li>
+<li>
+  <div>
+    <a href="sp800-63b.html"><img src="assets/800_63_3_Authenticators.png" alt="SP 800-63B" width="150px" height="150px"></a>
+  </div>
+  <h3><a href="sp800-63b.html">SP 800-63B</a></h3>
+</li>
+<li>
+  <div>
+    <a href="sp800-63c.html"><img src="assets/800_63_3_Federation.png" alt="SP 800-63C" width="150px" height="150px"></a>
+  </div>
+  <h3><a href="sp800-63c.html">SP 800-63C</a></h3>
+</li>
+</ul>
+
 Welcome to the NIST SP 800-63-3 Public Preview!  We're excited to share the major transformation that this document has undergone, as well as collaboratively enhance and evolve the guidance as we head to a public draft later this summer.
 
 ## A few formalities

sp800-63-3.md

@@ -4,6 +4,7 @@ title: "DRAFT NIST Special Publication 800-63-3"
 description: "DRAFT NIST Special Publication 800-63-3"
 ---
 
+{{ site.time | date_to_rfc822 }}
 {% include_relative sp800-63-3/cover.md %}
 {% include_relative sp800-63-3/sec1_2_introduction.md %}
 {% include_relative sp800-63-3/sec3_definitions.md %}

sp800-63-3/sec3_definitions.md

@@ -197,7 +197,7 @@ An attack on the authentication protocol run in which the attacker positions him
 #### Message Authentication Code (MAC)
 A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. MACs provide authenticity and integrity protection, but not non-repudiation protection.
 
-####Multi-Factor
+#### Multi-Factor
 A characteristic of an authentication system or an authenticator that uses more than one authentication factor.
 
 The three types of authentication factors are something you know, something you have, and something you are.

sp800-63-3/sec4_model.md

@@ -87,7 +87,7 @@ However, this recommendation does accept that authentication systems that incorp
 
 For example, consider a piece of hardware (the authenticator) that contains a cryptographic key (the authenticator secret) where access is protected with a fingerprint. When used with the biometric, the cryptographic key produces an output that is used in the authentication process to authenticate the claimant. An impostor must steal the encrypted key (by stealing the hardware) and replicate the fingerprint to use the authenticator. This specification considers such a device to effectively provide two factor authentication, although the actual authentication protocol between the verifier and the claimant simply proves possession of the key.
 
-As noted above, biometrics, when employed as a single factor of authentication, do not constitute acceptable secrets for digital authentication, but they do have their place in this specification. Biometric characteristics are unique personal attributes that can be used to verify the identity of a person who is physically present at the point of verification. They include facial features, fingerprints, iris and retina scans, voiceprints and many other characteristics. [Special Publication 800-63A, Enrollment and Identity Proofing](sp800-63a.html) recommends that biometrics be used in the enrollment process for higher levels of assurance to later help prevent a subscriber who is registered from repudiating the enrollment, to help identify those who commit enrollment fraud, and to unlock authenticators.
+As noted above, biometrics, when employed as a single factor of authentication, do not constitute acceptable secrets for digital authentication, but they do have their place in this specification. Biometric characteristics are unique personal attributes that can be used to verify the identity of a person who is physically present at the point of verification. They include facial features, fingerprints, iris patterns, voiceprints, and many other characteristics. [Special Publication 800-63A, Enrollment and Identity Proofing](sp800-63a.html) recommends that biometrics be used in the enrollment process for higher levels of assurance to later help prevent a subscriber who is registered from repudiating the enrollment, to help identify those who commit enrollment fraud, and to unlock authenticators.
 
 #### 4.3.2. Credentials
 

sp800-63a.md

@@ -4,6 +4,7 @@ title: "DRAFT NIST Special Publication 800-63A"
 description: "DRAFT NIST Special Publication 800-63A"
 ---
 
+{{ site.time | date_to_rfc822 }}
 {% include_relative sp800-63a/cover.md %}
 {% include_relative sp800-63a/sec1_2_introduction.md %}
 {% include_relative sp800-63a/sec3_definitions.md %}

sp800-63b.md

@@ -4,6 +4,7 @@ title: "DRAFT NIST Special Publication 800-63B"
 description: "DRAFT NIST Special Publication 800-63B"
 ---
 
+{{ site.time | date_to_rfc822 }}
 {% include_relative sp800-63b/cover.md %}
 {% include_relative sp800-63b/sec1_2_introduction.md %}
 {% include_relative sp800-63b/sec3_definitions.md %}

sp800-63b/sec3_definitions.md

@@ -160,7 +160,7 @@ An attack on the authentication protocol run in which the attacker positions him
 #### Message Authentication Code (MAC)
 A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. MACs provide authenticity and integrity protection, but not non-repudiation protection.
 
-####Multi-Factor
+#### Multi-Factor
 A characteristic of an authentication system or an authenticator that uses more than one authentication factor.
 
 The three types of authentication factors are something you know, something you have, and something you are.

sp800-63b/sec4_aal.md

@@ -35,7 +35,7 @@ Verifiers operated by government agencies at AAL 1 SHALL be validated to meet th
 
 In order to be valid at AAL 1, authentication assertions SHALL meet the requirements defined in [SP 800-63C](sp800-63c.html). Bearer assertions MAY be used.
 
-####<a name="aal1reauth"></a> 4.1.4. Reauthentication
+#### <a name="aal1reauth"></a>4.1.4. Reauthentication
 
 At AAL 1, reauthentication of the subscriber SHOULD be repeated at least once per 30 days, regardless of user activity.
 
@@ -80,7 +80,7 @@ Verifiers operated by government agencies at AAL 2 SHALL be validated to meet th
 
 In order to be valid at AAL 2, authentication assertions SHALL meet the requirements defined in [SP 800-63C](sp800-63c.html). Bearer assertions MAY be used.
 
-####<a name="aal2reauth"></a> 4.2.4. Reauthentication
+#### <a name="aal2reauth"></a>4.2.4. Reauthentication
 
 At AAL 2, authentication of the subscriber SHALL be repeated at least once per 12 hours, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following no more than 30 minutes of user inactivity. The CSP MAY prompt the user to cause activity just before the inactivity timeout, if desired. Reauthentication MAY use one of two authentication factors if the AAL 2 requirements of [Section 5.2.4](#reauth_sm) are met.
 
@@ -99,6 +99,7 @@ AAL 3 is intended to provide the highest practical remote network authentication
 #### 4.3.1. Permitted Authenticator Types
 
 Authentication Assurance Level 3 requires the use of one of two kinds of hardware devices:
+
 * Multi-factor OTP Device
 * Multi-Factor Cryptographic Device
 
@@ -112,7 +113,7 @@ Verifiers at AAL 3 SHALL be validated at [[FIPS 140]](#FIPS140-2) Level 2 or hig
 
 In order to be valid at AAL 3, authentication assertions SHALL meet the requirements of proof-of-possession assertions as defined in [SP 800-63C](sp800-63c.html).
 
-####<a name="aal3reauth"></a> 4.3.4. Reauthentication
+#### <a name="aal3reauth"></a>4.3.4. Reauthentication
 
 At AAL 3, authentication of the subscriber SHALL be repeated at least once per 12 hours, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following a period of no more than 15 minutes of user inactivity. It is permissible to prompt the user to cause activity just before the inactivity timeout, if desired.
 

sp800-63b/sec5_authenticators.md

@@ -53,7 +53,7 @@ Look-up secrets SHALL be generated using an approved random number generator and
 
 Verifiers SHALL use approved encryption and SHALL authenticate themselves to the claimant (e.g., through the use of a X.509 certificate acceptable to the claimant) when requesting look-up secrets in order to provide resistance to eavesdropping and phishing attacks.
 
-####<a name="out-of-band"></a> 5.1.3. Out of Band
+#### <a name="out-of-band"></a>5.1.3. Out of Band
 
 An Out of Band authenticator is a physical device that is uniquely addressable and can receive a verifier-selected secret for one-time use. The device is possessed and controlled by the claimant and supports private communication over a secondary channel that is separate from the primary channel for e-authentication. The claimant presents the received secret to the verifier using the primary channel for e-authentication.
 
@@ -91,7 +91,7 @@ A single factor OTP device is a hardware device that supports the time-based gen
 
 Single factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier.
 
-#####<a name="sfotpa"></a> 5.1.4.1. Single Factor OTP Authenticators
+##### <a name="sfotpa"></a>5.1.4.1. Single Factor OTP Authenticators
 
 Single factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the lifetime of the device. The second is a nonce that is changed each time the authenticator is used or is based on a real-time clock.
 
@@ -179,7 +179,7 @@ Multi-factor cryptographic device authenticators use tamper-resistant hardware t
 
 Each authentication operation using the authenticator SHOULD require the input of the additional factor. Input of the additional factor MAY be accomplished via either direct input on the device or via a hardware connection (e.g., USB or smartcard). 
 
-#####<a name="mfcdv"></a> 5.1.8.2 Multi-Factor Cryptographic Device Verifiers
+##### <a name="mfcdv"></a>5.1.8.2 Multi-Factor Cryptographic Device Verifiers
 
 Multi-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device and activation factor. The authenticator output is highly dependent on the specific cryptographic device and protocol, but it is generally some type of signed message.
 
@@ -189,11 +189,11 @@ The challenge nonce SHALL be at least 64 bits in length, and SHALL either be uni
 
 #### 5.2. General Authenticator Requirements
 
-##### 5.2.1. Physical Authenticators
+#### 5.2.1. Physical Authenticators
 
 CSPs SHALL provide subscriber instructions on how to appropriately  protect the authenticator against theft or loss. The CSP SHALL provide a mechanism to revoke or suspend the authenticator immediately upon notification from subscriber that loss or theft of the authenticator is suspected.
 
-#####<a name="throttle"></a> 5.2.2. Rate Limiting (Throttling)
+#### <a name="throttle"></a>5.2.2. Rate Limiting (Throttling)
 
 *cf. 800-63-2 sec 8.2.3, p.75*
 
@@ -213,9 +213,10 @@ Since these measures often create user inconvenience, it is best to allow a cert
 
 When the subscriber successfully authenticates, the failure counter SHOULD be reset to zero.
 
-####<a name="biometric_use"></a> 5.2.3. Use of Biometrics
+#### <a name="biometric_use"></a>5.2.3. Use of Biometrics
 
 For a variety of reasons, this document supports only limited use of biometrics for authentication. These include:
+
 - Biometric False Accept Rates (FAR) and False Reject Rates (FRR) do not provide confidence in the authentication of the subscriber by themselves. In addition, FAR and FRR do not account for spoofing attacks.
 - Biometric matching is probabilistic, whereas the other authentication factors are deterministic
 - Biometrics are difficult to revoke compared to other authentication factors.  For example, PKI certificates and passwords
@@ -228,6 +229,7 @@ Biometrics SHALL be used with another authentication factor that SHALL be revoka
 The biometric system SHALL have a tested equal error rate of **1 in 1000** or better. The biometric system SHALL be operational with a false match rate of **1 in 1000** or better. 
 
 If matching is performed centrally:
+
 * Use of the biometric SHALL be bound tightly to a single, specific device that is identified using approved cryptography
 * Presentation attack detection (PAD) SHALL be implemented 
 * Biometric revocation SHOULD be implemented

sp800-63b/sec6_lifecycle.md

@@ -4,14 +4,16 @@
 
 During the lifecycle of an authenticator bound to a subscriber's identity, a number of events may occur that affect the use of that authenticator. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions that SHALL be taken in response to those events.
 
-###<a name="binding"></a> 6.1. Authenticator binding
+### <a name="binding"></a>6.1. Authenticator binding
+
 Authenticators may be provided by a CSP as part of a process such as enrollment; in other cases, the subscriber may provide their own, such as software or hardware cryptographic modules. For this reason, we refer to the *binding* of an authenticator rather than the issuance, but this does not exclude the possibility that an authenticator is issued as well.
 
 Throughout the online identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with the identity. It SHALL also maintain the information required for throttling authentication attempts when required, as described in section 5.2.2.
 
 The record created by the CSP SHALL contain the date and time the authenticator was bound to the account and SHOULD include information about the binding, such as the IP address or other device identifier associated with the enrollment. It SHOULD also contain information about unsuccessful authentications attempted with the authenticator.
 
 #### 6.1.1. Enrollment
+
 The following requirements apply when an authenticator is bound to an identity as a result of a successful identity proofing transaction, as described in 800-63-A.
 
 At IAL 2, the CSP SHALL bind at least one, and SHOULD bind at least two, authenticators to the subscriber's online identity. Binding of multiple authenticators is preferred in order to recover from loss or theft of their primary authenticator. While at IAL 1 all identifying information is self-asserted, creation of online material or an online reputation makes it undesirable to lose control of an account as result of the loss of an authenticator. The second authenticator makes it possible to securely recover from that situation.

sp800-63b/sec8_security.md

@@ -76,7 +76,7 @@ There are several other strategies that may be applied to mitigate the threats d
 
 - *Out of band techniques* may be employed to verify proof of possession of registered devices (e.g., cell phones).
 
-###8.3. Authenticator Recovery
+### 8.3. Authenticator Recovery
 
 The weak point in many authentication mechanisms is the process followed when a subscriber loses control of one or more authenticators and needs to replace them. In many cases, the options remaining available to authenticate the subscriber are limited, and economic concerns (cost of maintaining call centers, etc.) motivate the use of inexpensive, and frequently less secure, backup authentication methods. To the extent that authenticator recovery is human-assisted, there is also the risk of social engineering attacks.
 

sp800-63c.md

@@ -4,6 +4,7 @@ title: "DRAFT NIST Special Publication 800-63C"
 description: "DRAFT NIST Special Publication 800-63C"
 ---
 
+{{ site.time | date_to_rfc822 }}
 {% include_relative sp800-63c/cover.md %}
 {% include_relative sp800-63c/sec1_2_introduction.md %}
 {% include_relative sp800-63c/sec3_definitions.md %}

sp800-63c/cover.md

@@ -18,8 +18,8 @@ http://dx.doi.org/10.6028/NIST.SP.XXX
 
 {:/comment}
 
-![](../sp800-63-3/media/csd.png)  
-![](../sp800-63-3/media/nist_logo.png)
+![](sp800-63-3/media/csd.png)  
+![](sp800-63-3/media/nist_logo.png)
 
 # DRAFT NIST Special Publication 800-63C
 
@@ -53,7 +53,7 @@ http://dx.doi.org/10.6028/NIST.SP.XXX
 
 Month TBD 2016
 
-![](../sp800-63-3/media/commerce_logo.png)
+![](sp800-63-3/media/commerce_logo.png)
 
 U.S. Department of Commerce  
 *Penny Pritzker, Secretary*