UCTrust Workgroup
Child pages
  • InCommon Silver Requirements

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

4.2 SPECIFICATION OF IDENTITY ASSURANCE REQUIREMENTS
This section contains all of the normative language for the Bronze and Silver IAPs.
In the requirements that follow, indicates that the numbered section applies to the
Bronze IAP; indicates that the numbered section applies to the Silver IAP.

InCommon Silver Requirement

UCOP Process

4.2.1 BUSINESS, POLICY AND OPERATIONAL CRITERIA IdP Operators must have the organizational structures and processes to come into and remain in compliance with the provisions of this IAP.


We see no problems complying with 4.2.1 as long as all other sections are compliant. Previously considered "low" impact.

4.2.1.1 INCOMMON PARTICIPANT
The IdPO must be an InCommon Participant in good standing in order to be considered for certification under this IAP. In this context, "good standing" means not in arrears with respect to financial obligations to InCommon nor out of compliance with other contractual obligations to InCommon.





Compliant

4.2.1.2 NOTIFICATION TO INCOMMON
The IdP Operator must notify InCommon of any circumstance that may affect the status
of its compliance with this IAP.

1. The IdP Operator must notify InCommon of any significant changes to its operation
that may affect the status of its compliance and hence its qualification under this IAP. Notification should occur no less than 30 days before the changes are to be made effective, or as soon as practicable after an unanticipated change is noted.

2. The IdPO must report to InCommon any breach of security or integrity of its IdMS Operations that may affect the status of its compliance and hence its qualification under this IAP. A report must be made as soon as practicable after any such incident is noted.









Compliant


4.2.1.3 CONTINUING COMPLIANCE
After initial certification by InCommon, IdP Operators must declare to InCommon continued compliance with profiles under this IAP at least every 3 years.




Need to set up this notification procedure. Otherwise compliant.

4.2.2 REGISTRATION AND IDENTITY PROOFING
Identity proofing in this IAP is based on government-issued ID or public records. Verified
information is used to create a record for the Subject in the IdPO's IdMS.



Some changes required. Previously estimated as "moderate" impact.

4.2.2.1 RA AUTHENTICATION
Each RA must authenticate to the IdMS using a credential that meets or exceeds Silver
requirements. Communications between an RA and the IdMS shall be encrypted using an industry
standard protocol that also authenticates the IdMS platform.




Compliant.

4.2.2.2 IDENTITY VERIFICATION PROCESS
1. The identity proofing and registration process shall be performed according to written policy or practice statements that specify the particular steps taken by IdPO staff or systems to verify identities.

2. The above statement(s) shall address the primary objectives of registration and identity proofing, including:

• Ensuring a person with the claimed identity information does exist, and that the
identity information is sufficient to uniquely identify a single person within the IdPO's range of foreseeable potential Subjects;

• Ensuring that the physical person requesting registration is entitled to the claimed
identity.

3. Personally identifiable information collected as part of the registration process must be protected from unauthorized disclosure or modification.


Compliant. Processes are documented on UCTrust wiki. See https://wiki.ucop.edu/display/UCOPIDM/Home

4.2.2.3 REGISTRATION RECORDS
1. A record of the facts of registration shall be maintained by the IdPO.
2. The record of the facts of registration shall include:
• Identity proofing document types and issuers;
• Full name as shown on the documents;
• Date of birth;
• Current Address of Record.
3. Records also must include revocation or termination of registration.


Nearly compliant.

BRC makes copies of identity proofing documents and enters data into PPS, to include:

  • Type of identity proofing document presented
  • Full Name A question: What if a person's common name (that which he uses, for example, as his e-mail address) is different from his real name as evidenced by his passport or drivers license? Is this still OK?
  • DOB
  • Current Address


    BRC must also log revocations and terminations.

4.2.2.4 IDENTITY PROOFING
Prior to this process, the Subject supplies his or her full name, date of birth, and an Address of Record to be used for communication with the Subject, and may, subject to the policy of the IdPO, also supply other identifying information. For each Subject, the full name, date of birth and Address of Record must be verified using one or more of the following methods:


We are compliant with this section, as noted below in 4.2.2.4.2, as we only need ONE of the following three alternatives.

4.2.2.4.1 Existing relationship
If the IdPO is a function of an enterprise, the identity proofing process may be able to leverage a pre-existing relationship, e.g., the Subject is an employee or student. Where some or all of the identity proofing done at the time the existing relationship
was established is comparable to that required in §4.2.2.4.2 or §4.2.2.4.3 below, those results may be relied upon for this purpose. The IdPO's Registration
Authority (RA) shall confirm that the Subject is a person with a current relationship to the organization, record the nature of that relationship and verify that the relationship is in good standing with the organization.







N/A

4.2.2.4.2 In-Person proofing
1. The RA shall establish the Subject's IdMS registration identity based on possession of a valid current government photo ID that contains the Subject's picture (e.g., driver's license or passport), and either an address or nationality.

2. The RA inspects the photo ID and compares the image to the physical Subject. The RA records the document type and issuer, the address given on the ID if there is one, and the date of birth shown on the ID if there is one. If the ID appears valid, the photo matches the physical Subject, and the ID confirms the Subject's date of birth, the RA authorizes issuance of Credentials.

3. If the address given on the ID does not confirm the Address of Record, it must be confirmed as described in §4.2.2.5 below.




This is the method BRC uses. Note the procedure for confirming a non-matching address, described in 4.2.2.5.

4.2.2.4.3 Remote proofing
1. The RA shall establish the Subject's IdMS registration identity based on possession of at least one valid government ID number (e.g., a driver's license or passport) and either a second government ID number or financial account number (e.g., checking account, savings account, loan or credit card) with confirmation via records of either number.

2. The RA verifies other information provided by the Subject using both of the ID numbers above through record checks either with the applicable agency or
institution or through credit bureaus or similar databases, and confirms that: name, date of birth, and other personal information in records are on balance consistent with the application and sufficient to identify a unique individual. If this appears to be the case, the RA authorizes issuance of Credentials.

3. If the record checks do not confirm the Address of Record, it must be confirmed as described in §4.2.2.5 below.

Compliant.

There are three variants of remote proofing at present:

  1. Washington/Sacramento:
    • Admins in Wash/Sac do the identity proofing and make copies of the documents.
    • They send these copies along with I-9 information to BRC.
    • BRC does the PPS entry and the UCTrust certification.
  2. UC Press:
    • UC Press does the identity proofing.
    • UC Press enters I-9 information into their own payroll system and maintains the log.
    • UC Press does the logon check
    • BRC does the UCTrust certification on request from UCPress.
  3. Anywhere else:
    • Campus admin or notary does the identity proofing.
    • Notarized copies of identity proofing are sent to BRC.
    • BRC does the I-9 entry into payroll and UCTrust certification.

4.2.2.5 ADDRESS OF RECORD CONFIRMATION
The Address of Record must be confirmed before the Subject's record can be considered to meet the requirements of this IAP. If the Address of Record was not confirmed as part of Identity proofing, then it must be accomplished by one of the following methods:

1. The RA contacts the Subject at the Address of Record and receives a reply from the
Subject; or

2. The RA issues Credentials in a manner that confirms the Address of Record supplied by the Subject.

a. For a physical Address of Record, the RA requires the Subject to enter online a temporary Secret from a notice mailed to the Subject's Address of Record.

b. For an electronic Address of Record, the RA confirms the ability of the Subject to receive telephone communications at a telephone number or e-mail at an e-mail address. Any Secret not sent over a Protected Channel shall be invalidated upon first use.

Needs some work.

Currently, BRC has the ability to observe a person's e-mail address when they log in to prove their AD account and password.

A better process would be to e-mail a 'secret' to the subject person and observe that the secret was received when the subject person logs in in-person.



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.

Previously considered "low" impact.

4.2.3.1 CREDENTIAL UNIQUE IDENTIFIER
1. Each Credential issued by the IdPO shall include a unique identifier (e.g., userID, Distinguished Name, serial number) that distinguishes it from all other Credentials in use by the IdPO.

2. A Subject can have more than one Credential unique identifier, but a given Credential unique identifier must map to at most one Subject.

3. The IdPO shall clearly associate the Credential unique identifier to the Subject's registration record in the IdMS, for use by the Verifier or other parties.


Compliant. No shared accounts are allowed.

4.2.3.2 RESISTANCE TO GUESSING AUTHENTICATION SECRET
The Authentication Secret and the controls used to limit online guessing attacks shall ensure that an attack targeted against a given Subject's authentication Secret shall have a probability of success of less than 2-10(1 chance in 1,024) over the life of the Authentication Secret. This requires that an Authentication Secret be of sufficient complexity and that the number of invalid attempts to enter an Authentication Secret for a Subject be limited.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="08520738-67f7-4efa-b9cf-e4214f2e9c07"><ac:plain-text-body><![CDATA[Refer to NIST Special Publication 800-63-1 [SP 800-63], Appendix A, for a discussion of Authentication Secret complexity and resistance to online guessing.


]]></ac:plain-text-body></ac:structured-macro>
Compliant. In accordance with the NIST document, UCOP's AD password standards (8 characters, with dictionary and composition checking) yields a guessing entropy of 30 bits which exceeds Level 1 or 2-10 (1 chance in 1,024) .

UCOP does have a mechanized "invalid attempts" policy which does limit such attempts. Specifically, the domain controller will lock a user out after 5 unsuccessful attempts within 10 minutes.  The account will be locked out for 30 minutes; then it will unlock itself.

4.2.3.3 STRONG RESISTANCE TO GUESSING AUTHENTICATION SECRET
1. The Authentication Secret and the controls used to limit online guessing attacks shall ensure that an attack targeted against a given Subject's Authentication Secret shall have a probability of success of less than 2-14 (1 chance in 16,384) over the life of the Authentication Secret. This requires that an Authentication Secret be of sufficient complexity and that the number of invalid attempts to enter an
Authentication Secret for a Subject be limited.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4af2431a-6c7d-44cd-a474-10cf4eb81d9a"><ac:plain-text-body><![CDATA[2. The Authentication Secret shall have at least 10 bits of min-entropy to protect against untargeted attack. Refer to NIST Special Publication 800-63-1 [SP 800-63], Appendix A, for a discussion of authentication Secret complexity and resistance to online guessing and how to calculate min-entropy.


]]></ac:plain-text-body></ac:structured-macro>
Compliant. In accordance with the NIST document, UCOP's AD password standards (8 characters, with dictionary and composition checking) yield a guessing entropy of 30 bits which meets Level 2 or 2-14 (1 chance in 16,384).

UCOP does have a mechanized "invalid attempts" policy which does limit such attempts. Specifically, the domain controller will lock a user out after 5 unsuccessful attempts within 10 minutes.  The account will be locked out for 30 minutes; then it will unlock itself.


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 (see also §4.2.5.6). 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 industry standard 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 industry standard algorithms and decrypt the needed Secret only when immediately required for authentication; or

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9cf3e5ca-69c1-4cab-b282-d63a3e8ae31b"><ac:plain-text-body><![CDATA[3. Any method protecting stored Secrets at NIST [SP 800-63] Level 3 or 4 may be used.


]]></ac:plain-text-body></ac:structured-macro>
Compliant. AD uses method 2.

4.2.3.5 PROTECTED AUTHENTICATION SECRETS
1. Any Credential Store containing Authentication Secrets used by the IdP (or the IdP's Verifier) is subject to the operational constraints in §4.2.3.4 and §4.2.8 (that is, the same constraints as IdMS Operations). When Authentication Secrets are sent from one Credential Store to another Credential Store (for example in an account provisioning operation) Protected Channels must be used.

2. Whenever Authentication Secrets used by the IdP (or the IdP's Verifier) are sent between services for verification purposes (for example, an IdP to a Verifier, or some non-IdP application to a Verifier), Protected Channels should be used, but Protected Channels without client authentication may be used.

3. If Authentication Secrets used by the IdP (or the IdP's Verifier) are exposed in a transient fashion to non-IdP applications (for example, when users sign on to those applications using these Credentials), the IdPO must have appropriate policies and procedures in place to minimize risk from this exposure.


Compliant. All interaction with the AD is encrypted with Kerberos – both desktop authentication (when we sign on in the morning) and all other AD interaction (e.g., Sharepoint) use Kerberos.

4.2.4 CREDENTIAL ISSUANCE AND MANAGEMENT
The authentication Credential must be bound to the physical Subject and to the IdMS record pertaining to that Subject as described in this section.

Moderate level of difficulty

4.2.4.1 CREDENTIAL ISSUANCE
To ensure that the same Subject acts throughout the registration and Credential issuance process, the Subject shall identify himself or herself in any new transaction (beyond the first transaction or encounter) with information known only to the Subject, for example a temporary Secret which was established during a prior transaction or encounter, or sent to the Subject's Address of Record. When identifying himself or herself in person, the Subject shall do so either by using a Secret as described above, or through the use of an equivalent process that was established during a prior encounter.

Compliant. BRC requires subject to sign in to AD while being observed.

4.2.4.2 CREDENTIAL REVOCATION OR EXPIRATION
1. The IdPO shall revoke Credentials and Tokens within 72 hours after being notified that a Credential is no longer valid or is compromised.

2. If the IdPO issues Credentials that expire automatically within 72 hours or less then the IdPO is not required to provide an explicit mechanism to revoke the Credentials.

We should check to be sure that Techdesk has this policy established. Given that this is a generous amount of time to close an account, we assume compliant.

4.2.4.3 CREDENTIAL RENEWAL OR RE-ISSUANCE
Appropriate policy and process must be in place to ensure that any new Credential and/or new Authentication Secret is provided only to the actual Credential Subject should it be necessary to reissue an Authentication Secret, e.g., due to suspected
compromise or the Subject having forgotten the Secret, or to reissue a Credential due to expiration. This process must be at least as trustworthy as the process used for initial issuance of the Credential.

Prior to the IdPO allowing renewal or re-issuance of a Credential, the Subject must prove possession of an unexpired current Authentication Secret or, if the Subject cannot supply the current Authentication Secret, one of the following methods may be used:

1. The Subject must supply answers to pre-registered personalized questions designed to be difficult for any other person to know;

2. A short-lived single use Secret sent to the Address of Record that the Subject must submit in order to establish a new Authentication Secret. Replacing a forgotten Authentication Secret can be accomplished at any time using the above methodology. Authentication Secrets shall not be recovered; new Secrets shall be issued.

After expiration of the current Credential or Authentication Secret, or if none of the alternative mechanisms specified above are successful, renewal and re-issuance shall not be allowed. The Subject must re-establish her or his identity with the IdPO as defined in Section 4.2 above.

All interactions conducted via a shared network shall occur over a Protected Channel such as SSL/TLS.

Not compliant. Passwords are currently reset on the phone using employee-id as the 'secret.'

Need to work on a solution for this.

4.2.4.4 CREDENTIAL ISSUANCE RECORDS RETENTION
The IdPO shall maintain records of Credential issuance and revocation for a minimum of 180 days beyond the expiration of the Credential. These records must include, for each Credential issuance/revocation event, the Credential unique identifier and the time of issuance/revocation.

As above, logs must be kept for password re-issuance.

4.2.5 AUTHENTICATION PROCESS
The Subject interacts with the IdP to prove that he or she is the holder of a Credential, enabling the subsequent issuance of Assertions.

Low impact.

4.2.5.1 RESIST REPLAY ATTACK
The authentication process must ensure that it is impractical to achieve successful authentication by recording and replaying a previous authentication message.

Compliant

4.2.5.2 RESIST EAVESDROPPER ATTACK
The authentication protocol must resist an eavesdropper attack. Any eavesdropper who
records all the messages passing between a Subject and a Verifier or relying party must find that it is impractical to learn the Authentication Secret or to otherwise obtain information that would allow the eavesdropper to impersonate the Subject.

Complaint

4.2.5.3 SECURE COMMUNICATION
Industry standard cryptographic operations are required between Subject and IdP in order to ensure use of a Protected Channel to communicate.

Compliant. All use SSL.

4.2.5.4 PROOF OF POSSESSION
The authentication process shall prove the Subject has possession of the Authentication Secret or Token.

Compliant

4.2.5.5 SESSION AUTHENTICATION
If the IdP uses session-maintenance methods (such as cookies) so that after an initial authentication act new Assertions can be issued without the Subject having to re-authenticate, such methods shall use industry standard cryptographic techniques to
ensure that sessions are at least as resistant to attack as initial authentication.

Compliant

4.2.5.6 MITIGATE RISK OF SHARING CREDENTIALS
Measures shall be taken to reduce the risk of a Subject intentionally compromising his or her Credential to repudiate authentication. These should include one or more of the following, as appropriate:

• Periodic confirmations that Subjects understand and will comply with security policy requirements;

• Confirmations of sensitive online transactions through a separate channel (such as e-mail);

• Educate Subjects about threats of Authentication Secret theft from attacks such as phishing;

• Reminders to Subjects that sharing of Credentials is prohibited.

Currently compliant, but we should establish a standard reminder process.

4.2.6 IDENTITY INFORMATION MANAGEMENT
Subject records in the IdPO's IdMS must be managed appropriately so that Assertions
issued by the IdPO's IdP are valid.

Low

4.2.6.1 IDENTITY RECORD QUALIFICATION
If Subject records in an IdMS do not all meet the same set(s) of IAP criteria, then the IdP must have a reliable mechanism for determining which IAQ(s), if any, are associated with each record.

Compliant

4.2.7 ASSERTION CONTENT
The IdPO must have processes in place to ensure that information about a Subject's identity conveyed in an Assertion of identity to an SP is from an authoritative source.

Low

4.2.7.1 IDENTITY ATTRIBUTES
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7fa7383a-9471-461a-80e5-193168299e42"><ac:plain-text-body><![CDATA[The actual meaning of any attribute values identified as attributes recommended for use by InCommon Participants should be consistent with definitions in the InCommon Attribute Summary [InC-AtSum].

Compliant

]]></ac:plain-text-body></ac:structured-macro>

4.2.7.2 IDENTITY ASSERTION QUALIFIER (IAQ)
An IdPO may be certified by InCommon to be able to include one or more InCommon IAQs as part of Assertions. The IdP must not include an InCommon IAQ that it has not been certified by InCommon to assert and must not include an IAQ if that
Assertion does not meet the criteria for that IAP.

This would be new under InCommon Silver.

4.2.7.3 CRYPTOGRAPHIC SECURITY
Cryptographic operations are required between an IdP and any SP. Cryptographic operations shall use industry standard cryptographic techniques.
The Assertion must be either:
• Digitally signed by the IdP; or
• Obtained by the SP directly from the trusted entity (e.g., the IdP or Attribute Service) using a Protected Channel.

Compliant. We use the second option, using SSL

4.2.8 TECHNICAL ENVIRONMENT
IdMS Operations must be managed to resist various potential threats such as unauthorized intrusions and service disruptions that might result in false Assertions of Identity or other erroneous communications.

We originally said this was Moderate, but I think that it is really Low. All has to do with the stability and resistance to intrusion of AD.

4.2.8.1 SOFTWARE MAINTENANCE
IdMS Operations shall use up-to-date supported software.

Compliant

4.2.8.2 NETWORK SECURITY
1. Appropriate measures shall be used to protect the confidentiality and integrity of network communications supporting IdMS operations. Protected Channels should be used for communications between systems.

2. All personnel with login access to IdMS Operations infrastructure elements must use access Credentials at least as strong as the strongest Credential issued by the IdPO.

Compliant. See answer to 4.2.3.5.

4.2.8.3 PHYSICAL SECURITY
IdMS Operations shall employ physical access control mechanisms to restrict access to sensitive areas, including areas such as leased space in remote data centers, to authorized personnel.

Compliant

4.2.8.4 RELIABLE OPERATIONS
IdMS Operations shall employ techniques to minimize system failures and ensure that any failures are not likely to result in inaccurate Assertions being sent to SPs.

Compliant

Retroactive Certification

It was decided amongst UCTrust workgroup members that we would not include a retroactive re-certification of all subjects. I don't think UCOP would need re-certification anyway.

  • No labels