Overview

The Assurance Framework used within the AAF is the NIST Electronic Authentication Guideline – NIST SP 800-63-2. The NIST guideline forms the basis of many assurance frameworks used internationally and was selected with a view to being interoperable with other federations.

Prerequisites

The following outlines the various levels of Security and the assertions that are required for each particular level. Currently the AAF only deals with LoA1 and LoA2

Level 1

No specific requirement, however some effort should be made to uniquely identify and track applications.

Level 2

For electronic transactions, the Applicant shall identify himself/herself in any new transaction (beyond the first transaction or encounter) by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or physical address of record. For physical transactions, the Applicant shall identify himself/herself in person by either using a secret as described above, or by biometric verification (comparing a captured biometric sample to a reference biometric sample that was enrolled during a prior encounter).

Level 3

For electronic transactions, the Applicant shall identify himself/herself in each new electronic transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or physical address of record. Permanent secrets shall only be issued to the Applicant within a protected session. For physical transactions, the Applicant shall identify himself/herself in person by either using a secret as described above, or through the use of a bio-metric that was recorded during a prior encounter. Temporary secrets shall not be reused. If the CSP issues permanent secrets during a physical transaction, then they shall be loaded locally onto a physical device that is issued in person to the Applicant or delivered in a manner that confirms the address of record.

Level 4

Only physical transactions apply. The Applicant shall identify himself/herself in person in each new physical transaction through the use of a biometric that was recorded during a prior encounter.17 If the CSP issues permanent secrets, then they shall be loaded locally onto a physical device that is issue The following checklists are to assist Identity Providers in determining whether they meet the requirements for issuing LoA1 and LoA2.

The requirements are a summary from NIST SP 800-63-2* (available fromhttp://csrc.nist.gov/publications/PubsSPs.html). Please refer to the NIST document for more complete information, clarification, and context regarding the requirements. The relevant document page numbers are listed beside each requirement for your reference.

Identity Providers only need to meet these requirements for those users for whom they are asserting a given level of assurance.

For LoA2, a Compliance Statement confirming compliance to the NIST requirements must be submitted to the AAF and made available to other subscribers upon request as outlined in Figure 1.

* Over time NIST may release updated versions of NIST SP 800-63. Subscribers should always check for the latest version of the standard.

Details

Process for moving to LoA1

Identity Providers asserting LoA1 are required to follow the NIST SP 800-63-2 standard for LoA1. The AAF does not require the Subscriber to submit a Compliance Statement stating that the requirements of the NIST standard have been met for LoA1.

As an Identity Provider, if you do not meet all requirements for LoA1 under Token and Credential Assurance, you should assert a value of 0 for this.

Process for moving to LoA2

Identity Providers asserting LoA2 are required to follow the NIST SP 800-63-2 standard for LoA2. Figure 1 outlines the steps to begin asserting LoA2 for users in your IdP. Note that you do not need to meet LoA2 requirements for all users in your IdP, only for those users for whom you are asserting LoA2. Before an IdP can begin asserting LoA2 they must review the LoA Practice Statement (link TBA) outlining the processes, and a Compliance Statement (link TBA) stating that the requirements of the NIST standard have been met.

What Identity Providers need to do

The following checklists are to assist Identity Providers in determining whether they meet the requirements for issuing LoA1 and LoA2.

Identity Providers only need to meet these requirements for those users for whom they are asserting a given level of assurance. For LoA2, a Compliance Statement confirming compliance to the NIST requirements must be submitted to the AAF and made available to other subscribers upon request as outlined in Figure 1.

* Over time NIST may release updated versions of NIST SP 800-63. Subscribers should always check for the latest version of the standard.

LoA 1 requirements checklist

Registration and identity-proofing requirements (eduPersonAssurance = urn:mace:aaf.edu.au:iap:id:1)

NIST page#	Requirement
N/A	Document your processes for issuing credentials. Note this is a baseline requirement for complying with the AAF Federation Rules. There are no additional requirements for identity proofing at Level 1.

Tokens and token and credential management requirements (eduPersonAssurance = urn:mace:aaf.edu.au:iap:authn:1)

NIST page#	Requirement
51	User passwords must be at least 6 characters (or alternatively a randomly generated PIN of 4 or more digits).
51	You have implemented a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the user’s account to 100 or fewer in any 30-day period.
64	Password files are protected by access controls that limit access to administrators and only to those applications that require access.
64	Password files do not contain the plaintext passwords. Typically they contain a one-way hash of the password.

LoA 2 requirements checklist

Registration and identity-proofing requirements (eduPersonAssurance = urn:mace:aaf.edu.au:iap:id:2)

NIST page#	Requirement
33	The applicant has undergone an in-person registration process at your organisation during which they have demonstrated possession of a valid current primary government picture ID that contains their picture and either their address of record or their nationality of record – in other words, either a driver’s license or a passport.
33	During the registration process the Registration Authority (RA) at your organisation inspects the applicant’s photo ID, compares the picture to the applicant, and records the ID number, the address, and the date of birth.
33	If the photo ID appears to be valid and the photo matches the applicant, then a) If personal information in records includes a telephone number or e-mail address, the CSP issues credentials in a manner that confirms the ability of the Applicant to receive communications at phone number or email address associated with the Applicant in records. Any secret sent over an unprotected session shall be reset upon first use; or b) If ID confirms address of record, RA authorizes or CSP issues credentials. Notice is sent to address of record, or; c) If ID does not confirm address of record, CSP issues credentials in a manner that confirms the claimed address.
35	If the registration process, identity proofing, token creation/issuance and credential issuance take place as separate physical encounters or electronic transactions, you have ensured the same party acts as applicant throughout the processes using the following method: The applicant identifies himself in any new electronic transaction by presenting a temporary secret which was established during a prior transaction of encounter, or sent to the applicant’s phone number, email address, or physical address of record. The applicant identifies himself in person by either using a secret as described above, or through the use of a biometric characteristic that was recorded during a prior encounter (such as a student/staff card displaying their photo).
31	You have followed the documented processes in a practice statement that demonstrates these requirements are met.

Tokens and token and credential management requirements (eduPersonAssurance = urn:mace:aaf.edu.au:iap:authn:2)

NIST page#	Requirement
51	User passwords must be at least 8 characters (or alternatively a randomly generated PIN of 6 or more digits).
51	You have implemented a dictionary or composition rule to constrain user-generated passwords.
51	You have implemented a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the user’s account to 100 or fewer in any 30-day period.
64	Password files are protected by access controls that limit access to administrators and only to those applications that require access.
64	Password files do not contain plaintext passwords or secrets. Two alternative methods may be used to protect them: they may be concatenated to a variable salt and then hashed, or stored in encrypted form and the needed secret decrypted only when immediately required for authentication.
65	Long term shared authentication secrets, if used, are never revealed to any other party except verifiers operated by the CSP.
65	You have established policies for renewal and re-issuance of tokens and credentials including the following elements: a. The claimant must demonstrate proof of possession of the unexpired current token prior to allowing renewal and re-issuance. b. Passwords are not renewed; they are re-issued c. After expiry of the current token and any grace period, renewal and re-issuance are not allowed. d. Upon re-issuance, token secrets are not set to a default or reused in any manner. e. All interactions occur over a protected channel such as SSL/TLS.
65	You revoke credentials and tokens within 72 hours after being notified that a credential is no longer valid or a token is compromised to ensure that a claimant using the token cannot successfully be authenticated.
65	You maintain a record of the registration, history, and status of each token and credential (including revocation) for seven years and six months beyond the expiration or revocation (whichever is later) of the credential.
N/A	You have confirmed in a Compliance Statement that the processes and requirements in the AAF Practice Statement are met.

What Service Providers need to do?

It is the Service Provider’s responsibility to determine the level of assurance required to allow access to their services. An example of a process that could be used for this can be found in the Australian Government’s National eAuthentication Framework (NeAF) at http://agict.gov.au/files/2012/04/NeAFFramework.pdf. See Section 3, Step 2: Determine the assurance level requirements, on page 14. The NeAF levels of assurance 1-4 are consistent with the levels defined by NIST.

As a Service Provider, you should be aware there are two values of eduPersonAssurance you should consider. In addition there is information about the authentication instance found in AuthnContext asserted in the SAML transaction.

Frequently Asked Questions

Why should my organisation move to LoA2?

Moving to LoA2 will enable your users to access services that require this level of assurance. These services are likely to include those associated with:

RDSI
NeCTAR
AURIN
CSIRO

Other research services

The ability of AAF IdPs to support LoA2 will also raise the overall level of trust in the federation, making it a more attractive authentication option for other service providers.

My organisation can only meet requirements for Level 1 at this time. Does that mean we’re not compliant with the Federation Rules?

No. The AAF Federation Rules do not require subscribers to comply with a particular level of assurance; only to be able to provide the core attributes that contain LoA information.

The purpose of the framework is to allow your organisation to describe the processes you have used to identify and authenticate users, using a standard vocabulary. Service providers can then use this information to determine whether to allow the user access to their service. If you only meet the requirements for Level 1, that is fine. However it does mean that your users will not be able to access services that require higher levels.

If some of our users need to access a service that requires Level 2, do we have to meet Level 2 requirements for all of our users?

No. If only a small number of your users need to access Level 2 services – some research staff members, for example – you can meet the Level 2 requirements for those users only and continue to assert a Level 1 for the rest of your users.

How often do I need to submit a Compliance Statement?

You will need to submit your initial Compliance Statement before you can commence asserting LoA2. The AAF will require subsequent Annual Compliance statements (including the LoA clause) to be submitted by June 30 each year as part of the annual compliance process.

Asserting the Assurance Framework