AAF Assurance Framework
The Assurance Framework used within the AAF is the NIST Electronic Authentication Guideline – NIST SP 800-63-1. The NIST guideline forms the basis of many assurance frameworks used internationally and was selected with a view to being interoperable with other federations.
Within the AAF, assurance is separated into two concepts. Two values are asserted in the eduPersonAssurance attribute, one for each of these concepts.
- Identity Assurance: The strength of the processes used to identify the user at the time of user registration. This is indicated by a value asserted in the eduPersonAssurance attribute of the format urn:mace:aaf.edu.au:iap:id:.[level], where level is a value from 1 to 2.
- Token and Credential Management Assurance: The strength of the token used and the strength of the processes used to manage tokens and credentials. This is indicated by a value asserted in the eduPersonAssurance attribute of the format urn:mace:aaf.edu.au:iap:authn:[level], where level is a value from 0 to 2.
Together, these two values make up the Level of Assurance (LoA) associated with a user’s authentication.
Note that additional information about the particular authentication instance may be obtained from the value of AuthnContext asserted as part of the SAML transaction.
This AAF Assurance Framework is for Level of Assurance (LoA) 1 and LoA 2. Over time the AAF may amend this Framework to include other assurance levels.
Process for moving to LoA1
Identity Providers asserting LoA1are required to follow the NIST SP 800-63-1 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-1 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 submit a Practice Statement documenting their processes, and a Compliance Statement stating that the requirements of the NIST standard have been met.
Figure 1: Process for moving to LoA2
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.
The requirements are a summary from NIST SP 800-63-1* (available from http://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 Practice Statement documenting your processes 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)|
|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)|
|49||User passwords must be at least 6 characters (or alternatively a randomly generated PIN of 4 or more digits).||49||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.||62||Password files are protected by access controls that limit access to administrators and only to those applications that require access.||62||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)|
|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 documented your 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)|
|49||User passwords must be at least 8 characters (or alternatively a randomly generated PIN of 6 or more digits).|
|49||You have implemented a dictionary or composition rule to constrain user-generated passwords.|
|49||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.|
|62||Password files are protected by access controls that limit access to administrators and only to those applications that require access.|
|62||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.|
|63||Long term shared authentication secrets, if used, are never revealed to any other party except verifiers operated by the CSP.|
|63||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.
|63||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.|
|63||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.|
|You have documented your processes in a practice statement that demonstrates these requirements 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://www.finance.gov.au/e-government/security-and-authentication/docs/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 LoA 2?
Moving to LoA 2 will enable your users to access services that require this level of assurance. These services are likely to include those associated with:
- Other research services
The ability of AAF IdPs to support LoA 2 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 to be submitted by June 30 each year as part of the annual compliance process.
How can I find out more information?
Contact AAF support at: http://support.aaf.edu.au.