Introduction
This document is intended to aid institutions aspiring to meet the requirements of the InCommon Federation's Identity Assurance Profile (IAP) for Silver level of assurance using muilti-factor implementations. Only sections of the IAP where there is a challenge unique to multi-factor are specifically addressed.
IAP sections discussed in this document:
- 4.2.3 Credential Technology
- 4.2.3.1 Credential Unique Identifier
- 4.2.3.2 Resistance to Guessing Authentication Secret
- 4.2.3.3 Strong Resistance to Guessting Authentication Secret
- 4.2.3.4 Stored AUthentication Secrets
- 4.2.3.5 Protected Authentication Secrets
- 4.2.6.1 Identity Record Qualification
For more information about the InCommon Assurance program, terms and definitions, and links to the IAP and IAAF documents and the FAQ, see the Assurance Resources section
Tokens
Tokens commonly used as something you have for multi-factor authentication are:
- Out-of-band tokens
- One-time password devices
- X.509 digital certificates, either stored in software or on a hardware device
NIST [SP 800-63] categorizes single-factor and multi-factor tokens. A single-factor token that represents something you have must be used in combination with another factor - typically something you know - in order to achieve multi-factor authentication. A multi-factor token that represents something you have requires activatation through a second factor of authentication - either something you know or something you are.
Multi-factor examples
Example 1
A university uses accounts and passwords to authenticate to many services on their campus. The account/password credential satisfies some, but not all requirements of the InCommon Silver IAP. The university also issues one-time-password (OTP) devices to faculty and staff. The devices are considered to be single-factor because the device does not require a second factor of authentication for activation. The OTP devices are issued using an in-person process that is designed to meet all the identity-proofing requirements for InCommon Silver. During the issuance process, the Subscriber's university account is linked to a registration record for the OTP device. At authentication time, the user must enter their university account/password combination and must prove possession of the OTP device by entering the generated one-time-password string. The university asserts that the OTP device and its supporting infrastructure meets or exceeds the requirements for InCommon Silver.
Multi-factor problem statement
Since the IAP does not specifically address multi-factor implemetnations, it is not clear whether both factors used in a multi-factor implementation must meet all requirements for InCommon Silver, or whether it is sufficient for only one factor to meet the requirements. The answer may lie in whether the addition of the factor which does not meet Silver requirements strengthens or weakens the security of the authentication process.
Example 2
A university issues personal X.509 certificates on a USB hardware token device -- a multi-factor cryptographic device according to NIST [SP 800-63]. A password is required in order to activate the device. In order to obtain a certificate on the token, elegible Subjects must bring identifying documents in person to a registration station, where the identity proofing procedures are designed to comply with InCommon Silver. The technical environment and all aspects of the registration and enrollment process are designed to comply with the InCommon Silver profile.
Multi-factor problem statement
The Credential in Example 2 employs public key technology, and the Subject must prove possession of the private key component of the key pair during authentication. Since the Authentication Secret described in the IAAF is generally a password, passphrase, PIN, or symmetric key, language in the IAP is not generally oriented toward public key technology. However, the credential was designed to meet NIST [SP 800-63] LoA 4 specifications. Therefore, the institution will provide documentation supporting the assertion that the credential meets or exceeds the effect of the Silver requirements. References to NIST [SP 800-63] will be used for guidance.
Sample Management Assertions
4.2.3 Credential Technology |
These InCommon IAPs are based on use of “shared Authentication Secret” forms of identity Credentials. If other Credentials are used to authenticate the Subject to the IdP, they must meet or exceed the effect of these requirements. |
|||
Criteria |
Management Assertion |
|||
.1 Credential unique identifier |
1. The institution's personal digital certificate (PDC) is issued with a Subject Distinguished Name (DN) and a serial number.The serial number is a unique number in the serial number field. The DN of the PDC contains a UID. The UID is a uniquely assigned attribute of a person in the institution's Enterprise Directory. See the {link to cetificate profile} for a complete description of the certificate DN. The serial number and the UID distinguish the PDC from all other Credentials issued by the IdPO. |
|||
.2 Resistance to guessing Authentication Secret |
See 4.2.3.3, Strong Resistance |
|||
.3 Strong resistance to guessing Authentication |
1. The institution's PDC on the MF device provides cryptographic strength mechanisms described in NIST [SP 800-63] for Level 3 and 4 assurance, protecting the private key against compromise by on-line guessing. The device is a multi-factor "hard" cryptographic token, requiring the user to unlock the device with a password in order to access the private key. |
]]></ac:plain-text-body></ac:structured-macro> |
||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="597b773e-0fd3-40cc-ae2f-f0f14e8b8cf9"><ac:plain-text-body><![CDATA[ |
.4 Stored Authentication Secrets |
The authentication secret is the x.509 private key which is generated onboard the MF cryptographic device. The private key cannot be exported off the device; thus it is not escrowed. The MF hardware cryptographic token used by the institution is certified at FIPS 140-2 Level 2. (See [FIPS 140 Certificate |
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt852.pdf].) This credential protects stored secrets at NIST [SP 800-6] assurance Level 4, thus meeting the criteria for method 3 in section 4.2.3.4 of the IAP. |
]]></ac:plain-text-body></ac:structured-macro> |
.5 Protected Authentication Secrets |
1. When issuing personal digital certificate credentials, the MF cryptogrpahic device generates and stores the user’s RSA key pair inside the protected environment of the smart chip in the device. The user’s private key component is never transmitted to another Credential Store and is permanently kept on the device. Access to the private key component on the device is password protected and implements a lockout threshold of 10 consecutive invalid password attempts. |