Assurance

[Ann West <>]

Hi Jeffrey,

Thank you for the suggestion. 

Yes, you are correct. The term "levels" in this context refer to Levels of Assurance 3 and 4 as defined by 800-63-1.

Ann

------------------ 

As you may be aware, there are also FIPS 140-2 levels for hardware encryption while the e-Authentication SP800-63 document refers to assurance levels.  Both “levels” are used throughout this section, and even refer back to each other, so it might be a good idea to be very clear and specific about which level.  Therefore #3 applies only to the credential store and management requirements of the Level 3 Assurance, i.e. section 7.3, yes?

 

4.2.3.4 Stored Authentication Secrets.

 

Authentication Secrets shall not be stored as plaintext. Access to encrypted stored Secrets and to decrypted copies shall be protected by discretionary access controls that limit access to administrators and applications that require access.

 

Three alternative methods may be used to protect the stored Secret:

1.     Authentication Secrets may be concatenated to a variable salt (variable across a group of Authentication Secrets that are stored together) and then hashed with an Approved Algorithm so that the computations used to conduct a dictionary or exhaustion attack on a stolen Authentication Secret file are not useful to attack other similar Authentication Secret files. The hashed Authentication Secrets are then stored in the Authentication Secret file. The variable salt may be composed using a global salt (common to a group of Authentication Secrets) and the userID (unique per Authentication Secret) or some other technique to ensure uniqueness of the salt within the group of Authentication Secrets; or

2.     Store Secrets in encrypted form using Approved Algorithms and decrypt the needed Secret only when immediately required for authentication; or

3.        Any method protecting stored Secrets at NIST [SP 800-63] Level 3 or 4 may be used.

 

Excerpt from SP800-64 (Pages 64-65)

7.3. Token and Credential Management Assurance Levels

7.3.1. Requirements per Assurance Level

The stipulations for management of tokens and credentials by the CSP and Verifier are described below for each assurance level. The stipulations described at each level in this section are incremental in nature; requirements stipulated at lower levels are implicitly included at higher levels.

[…]

At Level 3, the following is required:

• Credential storage²⁴ – Files of long-term shared secrets used by CSPs or Verifiers at Level 3 shall be protected by access controls that limit access to administrators and only to those applications that require access. Such shared secret files shall be encrypted so that:

1.        The encryption key for the shared secret file is encrypted under a key held in a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and decrypted only as immediately required for an authentication operation.

2.        Shared secrets are protected as a key within the boundary of a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and is not exported in plaintext from the module.

 

Strongly bound credentials support tamper detection mechanisms such as digital signatures, but weakly bound credentials can be protected against tampering using access control mechanisms as described above.

• Token and credential verification services – CSPs shall provide a secure mechanism to allow Verifiers or RPs to ensure that the credentials are valid. Such mechanisms may include on-line validation servers or the involvement of CSP servers that have access to status records in authentication transactions.

Temporary session authentication keys may be generated from long-term shared secret keys by CSPs and distributed to third party Verifiers, as a part of the verification services offered by the CSP, but long-term shared secrets shall not be shared with any third parties, including third party Verifiers. This typeof third-party (or delegated) verification is used in the realm of GSM (Global System for Mobile Communications) roaming; the locally available network authenticates the “roaming” Subscriber using a temporary session authentication key received from the Base Station. Such temporary session authentication keys are typically created by cryptographically combining the long term shared secret with a nonce challenge, to generate a session key. The challenge and session key are securely transmitted to the Verifier. The Verifier in turn sends only the challenge to the Claimant, and the Claimant applies the challenge to the long-term shared secret to generate the session key. Both Claimant and Verifier now share a session key, which can be used for authentication. Such verification schemes are permitted at this level provided that Approved cryptographic algorithms are used for all operations.

Token and credential verification services categorized as FIPS 199 “Moderate” or “High” for availability shall be protected in accordance with the Contingency Planning (CP) controls specified in NIST SP 800-53 to provide an adequate level of availability needed for the service.

•                      Token and credential renewal /re-issuance – Renewal and re-issuance shall only occur prior to expiration of the current credential. Claimants shall authenticate to the CSP using the existing token and credential in order to renew or re-issue the credential. All interactions shall occur over a protected session such as SSL/TLS.

•                      Credential revocation and destruction – CSPs shall have a procedure to revoke credentials and tokens within 24 hours. The certificate status provisions of CAs cross-certified with the Federal Bridge CA at the Basic, Medium, High or Common Certificate Policy levels are considered to meet credential status and revocation provisions of this level. Verifiers shall ensure that the tokens they rely upon are either freshly issued (within 24 hours) or still valid. Shared secret based authentication systems may simply remove revoked Subscribers from the verification database.

•                      Records retention – All stipulations from Level 2 apply.

•                      Security controls – The CSP must employ appropriately tailored security controls from the moderate baseline of security controls defined in [SP 800­53] and must ensure that the minimum assurance requirements associated with the moderate baseline are satisfied.

 

 

From: [] On Behalf Of Ann West
Sent: Tuesday, January 22, 2013 12:19 PM
To:
Subject: [Assurance] Assurance 1.2 Release Candidates: Public Comment Period Ends Tomorrow

 

As a reminder,  the public review period ends Wednesday Jan 23 COB Pacific.

 

Best regards,

Ann

 

From: Ann West <>
Reply-To: "" <>
Date: Wednesday, January 16, 2013 11:15 AM
To: "" <>
Subject: [Assurance] Assurance 1.2 Release Candidates Available for Public Review: Comments Due Jan 23

 

Good evening (or afternoon),

 

InCommon is pleased to make available the Release Candidates V1.2-January 2013 of inCommon's Framework and Profiles documents for public review. 

 

As a reminder, the  Community informally discussed these documents in December 2012 on our Assurance Implementers call. Since then,  we have made one change to update 4.2.5.5 to  address Session Hijacking per FICAM request. The rest of the text remains the same. 

 

Comments on the January 2013 version of 1.2  should generally be constrained to the FICAM-introduced material as reflected in the DIFF files.  

To review the release candidate, go to https://spaces.internet2.edu/display/InCAssurance/Profile+and+Framework+Versions If you have additional comments, please send those along as well. They will be collected for future consideration.

 

InCommon does not plan to host a conference call to discuss the changes, since we covered them in December. If you would like me to schedule something, just let me know. We invite the community to send comments to the list by COB Wednesday January 23, 2013.

 

Best regards,

Ann

-----------

Ann West

Assistant Director,

Assurance and Community

Internet2/InCommon/Michigan Tech 

 

office: +1.906.487.1726