This document discusses the different levels of assurance for digital authentication which range from level 1 to level 3. Level 1 requires either a single or multi-factor authentication, level 2 requires proof of possession and control of two distinct authentication factors, and level 3 requires a hardware based authentication and an authenticator that provides verifier impersonation resistance. This is a detailed document that describes what type of authenticators are permitted for each level, e.g. memorized secret, multi-factor OTP device, or multi-factor cryptographic device. One important note about this document is it applies to digital authentication in a network and does not cover authentication for physical access.
This reading provided an overview of the Digital Identity Guidelines for Authentication and Lifecycle Management. The reading defined Digital Authentication as determining the validity of one or more authenticators used to claim a digital identity, which results in an assertion of the identifier to a relying party. The reading outlined the different types of authentication required for the three levels of Authenticator Assurance. One of the key takeaways that I had was that Table 4-1 gave a very helpful summary of requirements for the three different levels based on a variety of factors. What stood out to me was that there is a good bit of overlap between permitted authenticator types between the three levels, but a lot of differences in the three levels as to how those are used, and the requirements for controls outlined in the table, particularly as you advance from AAL2 to AAL3. I also found it interesting in the reading that biometrics can be used as a factor and not an authenticator itself, largely for the reasons outlined in our Boyle & Panko reading about biometrics.
An often overlooked component of securing the confidentiality, integrity and availability of data is records retention. In my organization, one of my audit areas of purview is Records and Information management including Data Privacy. Therefore, I was happy to see the records retention requirements sections noted for all of the Authenticator Assurance levels. The requirements are the same, regardless of the authentication level, which include compliance with the organization’s own record retention policies which should consider applicable laws, regulations and policies including any applicable National Archives and Records Administration (NARA) retention schedules. In addition, there is a requirement to perform a risk management process for records which includes determining the privacy and security risks to help identify the appropriate retention requirements which must be disclosed to the subscriber in the event the CSP opts to retain
records in the absence of any mandatory requirements. It is important to be transparent to the subscriber in not only the type of data, the manner in which the data is used, and who will have access to the data, but also how long the data will be maintained as well as the method of destruction. Also, listed under the data privacy section is the requirement for the CSP to perform a privacy risk assessment for records retention, which includes the likelihood that records retention could create an issue for the subscriber such as unauthorized access to the information and the impact if this risk is realized.
The proofing requirements specify the acceptability, validation, and verification of the identity evidence that the subscriber will provide to support its identity claim. There are three types of identity assurance levels (IALs) for a subscriber’s identity. IAL1 has not required any link of the applicant to support who you are. Only self-asserted is needed. IAL2 has required evidence supports for either remote or physically present identity proofing. The credential service provider (CSP) can verify the attributes of relying parties (RPs). Identifying attributes must be verified by an authorized and trained credential service provider (CSP) representative. Also, the identity must be physically present.
Sorry to pose the wrong comment. Here is the correct one:
During a subscriber’s authenticator lifecycle, there are different conditions. which might affect the authenticator’s use. Authenticator binding is the authenticators need to bound to subscriber accounts to establish the used to authenticate for that subscriber’s account. Authenticators should be bound to subscriber accounts in two options. One is as a part of enrollment that issuance by the credential service provider (CSP). Another one is it should associate a subscriber-provided authenticator that is acceptable to the credential service provider (CSP). CSPs SHALL maintain a record of all authenticators and determine compliance with requirements at each AAL during the digital identity lifecycle. It can ensure to protect against security attacks (e.g., man-in-the-middle attack）by using authenticated protected channels.
The idea of reauthentication is essential in maintaining the integrity of digital identities. NIST SP 800-63B says that at AAL1 this should happen once every 30 days. I find it interesting because I have multi-factor authentication enabled on all of my online accounts. But for my email, for example, I can’t remember the last time I needed to present all the factors again or even put in my password again. It definitely didn’t happen within the last 30 days. AT AAL2 it’s once every 12 hours and after inactivity of 30 minutes (with one factor to reauthenticate). At AAL3, reauthentication is needed once every 12 hours or after inactivity of 15 minutes (with all factors to reauthenticate).
An interesting takeaway from this reading is authenticator threats and mitigations. These threats include: assertion manufacture or modification, theft, duplication, eavesdropping, phishing, social engineering, etc. MFA, endpoint security, using authenticators that offers verifier impersonation resistance; avoiding the use of authenticators that present risk of social engineering, etc. These threat mitigation strategies will reduce the risk on an attacker compromising the authenticator and masquerading as the authenticator’s owner.
This guideline provides information on the different types of authentication processes. This is referred to as Authentic Assurance Level (AAL). Just like NIST SP 800-63A, AAL also has 3 stages: AAL1 (some assurance), AAL2 (high confidence), and AAL3 (very high confidence); where each level the claimant has a certain amount of trust in control and possession of their authentication. Basically, the stronger the authentication, the more the risk of attacks is reduced.
A number of authenticator assurance levels and permitted authenticator types are included in this document. At each AAL level, the strength in the permitted authenticator types increases. For example, the AAL1 permits memorize secrets, and AAL3 only permits only multifactor authenticator types.
Hi Xiduo. Thank you for providing an overall summary for the NIST SP 800 63B “Digital Identity Guidelines Authentication and Lifecycle Management”. I thought that the guideline was a good companion with the other documents SP 800-63, SP 800-63A, and SP 800-63C. In addition, I think that NIST SP 800 63B was great for providing a guideline on the different types of the authentication process, which can be, used at various authenticator assurance levels. As you indicated AAL3 provides the most security for protecting sensitive data since it requires multi-factor authentication.
Similar to NIST SP 800-63 and SP 800-63A, the document provides technical guidelines to agencies for the implementation of digital authentication. One of the differences is additional details of Authenticator Lifecycle Management – a number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. Throughout the digital identity lifecycle, CSPs maintain a record of all authenticators that are or have been associated with each identity. The record contains the date and time the authenticator was bound to the account. The record also includes information about the source of the binding of any device associated with the enrollment.
Key takeaway from this reading that I found interesting was that when processing requests to change memorized “secrets” , the verifiers are able to compare the new secrets against a list of commonly-used, easily guesssed, or compromised answers. A few of the things they use are: passwords from previous security breaches, dictionary words (to counter dictionary attack), repeitive or sequential characters (ABCDFG, ASDFG, 12345) or context specific words. For example, some people would include the word “Chase” in their password if they were creating a password for their Chase bank account.
An important takeaway that interested me from NIST SP 800 63B “Digital Identity Guidelines Authentication and Lifecycle Management” was that this guideline should be used as a companion with SP 800-63, SP 800-63A, and SP 800-63C. According to the guideline, the ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity. Subscriber authentication is performed by verifying that the applicant controls one or more authenticators also known as tokens. The guideline provides recommendations on the types of authentication process such as choices of authenticators that can be used at various authenticator assurance levels. The document also provides recommendations on the lifecycle of authenticators including revocation due to loss or theft.
After reading the previous two documents on Digital Identity, this one almost felt redundant or that it could’ve been included in the other two. Lifecycle management is just about conceptually the same for most aspects of technology. Digital Identity is not excluded from this.
This document outlines how proper authentication with subjects who use government systems. This document works closely with NIST SP 800-63 and takes a deeper dive into authentication. One aspect I found interesting was section 8.1, which talks about Authenticator threats. Authentication, especially in government systems, is extremely important. The table lists attacks like Side-channel attacks, phishing, and social engineering. Then in section 8.2, Threat mitigation strategies are outlined. Due to the nature of data shared with many government information systems, understanding the threats and threat mitigation strategies is extremely important.
This document just outlines the lifecycle of digital identity management. It goes into depth about the different levels of identity and how often they have to be authenticated to confirm the human identity of the user. It also goes into detail about single-use authentication, multi-factor authentication, etc… In a real-world application, too much authentication becomes burdensome in my opinion. It gets very annoying when I have to type in the code I just got texted to log in or check my email. Additionally, multi-factor authentication just simply isn’t worth it to me when logging onto something menial like Facebook or Twitter. The most annoying part of my morning is having to login 3 times before I can access any of my work. That being said, I am willing to do that for work, but I am not willing to do that every time I log onto Facebook. In my opinion, biometrics would solve the issue of authentication and availability. The face ID on my iPhone is very convenient and extremely reliable as well. I wish Apple would allow me to disable my passcode so I can just log on with only my face.
As someone who works in the Client Services arm of an IT department, I think usability considerations are a very important takeaway from the reading. Information security departments naturally focus on managing risk by implementing cost-effective controls, and the experience of the legitimate users of the information systems is an afterthought. However, ultimately information security teams would not exist if not for the fact that end users need to access information systems to perform their jobs, so it is important to evaluate how much of a burden is placed on the end users as a result of the implemented authentication methods.
Mitchell – I agree with you. In both the 800-63a and 800-63b readings it really stood out to me that there was a lot of consideration given for usability factors. I think it’s an important concept to remember that if the use of a certain security measure is too complex or burdensome (such as a very long, complex password) then it’s ultimately likely to lead to greater risk (for example, users writing down their passwords). I don’t think a lot of organizations do a great job thinking about the usability factors when proposing implementing new processes or controls. Not only is it important to ensuring effective security but it’s also a good starting point to develop training for end-users as new processes and systems are rolled out.
I felt that the records retention section is valuable. As an auditor you should review how long the company is an is supposed to keep their records. Sometimes if the record retention policy is not present, a company may keep their records to long, or not long enough. From a legal perspective, the records retention should be followed, sometimes in the event of a lawsuit, if the documents are available post the retention date then a company may be held liable for the potential judgement for as far back as the records indicate.
Michael, I agree with you. As someone who has worked in audit for a while, records retention is often an overlooked area. I also think you make good points about not just sticking with the minimum record retention requirement but keeping records too long. I have seen situations where records were kept past the retention period and then were allowed to be introduced into evidence for lawsuits. Another trouble area I have seen with records retention is for companies that are heavily involved in mergers and acquisitions, it is often difficult to catalog all of the information that is “coming over” with the acquisition. I’ve seen several messes where a previous company I worked for did not do a good job of inventorying all information that belonged to the acquired institution (digital AND hard copy) and it led to huge messes when trying to ensure the records retention policy was followed.
The authenticator lifecycle management section stood out to me in this reading. The reading noted, many events can occur over the lifecycle of an authenticator that can affect that
authenticator’s use. These events include binding, loss, theft, unauthorized duplication,
expiration, and revocation. Binding refers to the establishment of an association between a specific
authenticator and a subscriber’s account. Loss, theft, and unauthorized duplication refer to authenticators that have been compromised. Expiration refers to authenticators that have been issued with an expiration date, and lastly, revocation refers to authenticators removal of the binding between an authenticator and a credential the CSP maintains. The reading provides details on what should be done in each of these instances.
This document discusses the different levels of assurance for digital authentication which range from level 1 to level 3. Level 1 requires either a single or multi-factor authentication, level 2 requires proof of possession and control of two distinct authentication factors, and level 3 requires a hardware based authentication and an authenticator that provides verifier impersonation resistance. This is a detailed document that describes what type of authenticators are permitted for each level, e.g. memorized secret, multi-factor OTP device, or multi-factor cryptographic device. One important note about this document is it applies to digital authentication in a network and does not cover authentication for physical access.
This reading provided an overview of the Digital Identity Guidelines for Authentication and Lifecycle Management. The reading defined Digital Authentication as determining the validity of one or more authenticators used to claim a digital identity, which results in an assertion of the identifier to a relying party. The reading outlined the different types of authentication required for the three levels of Authenticator Assurance. One of the key takeaways that I had was that Table 4-1 gave a very helpful summary of requirements for the three different levels based on a variety of factors. What stood out to me was that there is a good bit of overlap between permitted authenticator types between the three levels, but a lot of differences in the three levels as to how those are used, and the requirements for controls outlined in the table, particularly as you advance from AAL2 to AAL3. I also found it interesting in the reading that biometrics can be used as a factor and not an authenticator itself, largely for the reasons outlined in our Boyle & Panko reading about biometrics.
An often overlooked component of securing the confidentiality, integrity and availability of data is records retention. In my organization, one of my audit areas of purview is Records and Information management including Data Privacy. Therefore, I was happy to see the records retention requirements sections noted for all of the Authenticator Assurance levels. The requirements are the same, regardless of the authentication level, which include compliance with the organization’s own record retention policies which should consider applicable laws, regulations and policies including any applicable National Archives and Records Administration (NARA) retention schedules. In addition, there is a requirement to perform a risk management process for records which includes determining the privacy and security risks to help identify the appropriate retention requirements which must be disclosed to the subscriber in the event the CSP opts to retain
records in the absence of any mandatory requirements. It is important to be transparent to the subscriber in not only the type of data, the manner in which the data is used, and who will have access to the data, but also how long the data will be maintained as well as the method of destruction. Also, listed under the data privacy section is the requirement for the CSP to perform a privacy risk assessment for records retention, which includes the likelihood that records retention could create an issue for the subscriber such as unauthorized access to the information and the impact if this risk is realized.
Christa,
I also liked that Record Retention was in there. I agree as auditors it is important to review document retention and data privacy. Great point!
The proofing requirements specify the acceptability, validation, and verification of the identity evidence that the subscriber will provide to support its identity claim. There are three types of identity assurance levels (IALs) for a subscriber’s identity. IAL1 has not required any link of the applicant to support who you are. Only self-asserted is needed. IAL2 has required evidence supports for either remote or physically present identity proofing. The credential service provider (CSP) can verify the attributes of relying parties (RPs). Identifying attributes must be verified by an authorized and trained credential service provider (CSP) representative. Also, the identity must be physically present.
Sorry to pose the wrong comment. Here is the correct one:
During a subscriber’s authenticator lifecycle, there are different conditions. which might affect the authenticator’s use. Authenticator binding is the authenticators need to bound to subscriber accounts to establish the used to authenticate for that subscriber’s account. Authenticators should be bound to subscriber accounts in two options. One is as a part of enrollment that issuance by the credential service provider (CSP). Another one is it should associate a subscriber-provided authenticator that is acceptable to the credential service provider (CSP). CSPs SHALL maintain a record of all authenticators and determine compliance with requirements at each AAL during the digital identity lifecycle. It can ensure to protect against security attacks (e.g., man-in-the-middle attack）by using authenticated protected channels.
The idea of reauthentication is essential in maintaining the integrity of digital identities. NIST SP 800-63B says that at AAL1 this should happen once every 30 days. I find it interesting because I have multi-factor authentication enabled on all of my online accounts. But for my email, for example, I can’t remember the last time I needed to present all the factors again or even put in my password again. It definitely didn’t happen within the last 30 days. AT AAL2 it’s once every 12 hours and after inactivity of 30 minutes (with one factor to reauthenticate). At AAL3, reauthentication is needed once every 12 hours or after inactivity of 15 minutes (with all factors to reauthenticate).
An interesting takeaway from this reading is authenticator threats and mitigations. These threats include: assertion manufacture or modification, theft, duplication, eavesdropping, phishing, social engineering, etc. MFA, endpoint security, using authenticators that offers verifier impersonation resistance; avoiding the use of authenticators that present risk of social engineering, etc. These threat mitigation strategies will reduce the risk on an attacker compromising the authenticator and masquerading as the authenticator’s owner.
This guideline provides information on the different types of authentication processes. This is referred to as Authentic Assurance Level (AAL). Just like NIST SP 800-63A, AAL also has 3 stages: AAL1 (some assurance), AAL2 (high confidence), and AAL3 (very high confidence); where each level the claimant has a certain amount of trust in control and possession of their authentication. Basically, the stronger the authentication, the more the risk of attacks is reduced.
A number of authenticator assurance levels and permitted authenticator types are included in this document. At each AAL level, the strength in the permitted authenticator types increases. For example, the AAL1 permits memorize secrets, and AAL3 only permits only multifactor authenticator types.
Hi Xiduo. Thank you for providing an overall summary for the NIST SP 800 63B “Digital Identity Guidelines Authentication and Lifecycle Management”. I thought that the guideline was a good companion with the other documents SP 800-63, SP 800-63A, and SP 800-63C. In addition, I think that NIST SP 800 63B was great for providing a guideline on the different types of the authentication process, which can be, used at various authenticator assurance levels. As you indicated AAL3 provides the most security for protecting sensitive data since it requires multi-factor authentication.
Similar to NIST SP 800-63 and SP 800-63A, the document provides technical guidelines to agencies for the implementation of digital authentication. One of the differences is additional details of Authenticator Lifecycle Management – a number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. Throughout the digital identity lifecycle, CSPs maintain a record of all authenticators that are or have been associated with each identity. The record contains the date and time the authenticator was bound to the account. The record also includes information about the source of the binding of any device associated with the enrollment.
Key takeaway from this reading that I found interesting was that when processing requests to change memorized “secrets” , the verifiers are able to compare the new secrets against a list of commonly-used, easily guesssed, or compromised answers. A few of the things they use are: passwords from previous security breaches, dictionary words (to counter dictionary attack), repeitive or sequential characters (ABCDFG, ASDFG, 12345) or context specific words. For example, some people would include the word “Chase” in their password if they were creating a password for their Chase bank account.
An important takeaway that interested me from NIST SP 800 63B “Digital Identity Guidelines Authentication and Lifecycle Management” was that this guideline should be used as a companion with SP 800-63, SP 800-63A, and SP 800-63C. According to the guideline, the ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity. Subscriber authentication is performed by verifying that the applicant controls one or more authenticators also known as tokens. The guideline provides recommendations on the types of authentication process such as choices of authenticators that can be used at various authenticator assurance levels. The document also provides recommendations on the lifecycle of authenticators including revocation due to loss or theft.
Hi Elias,
After reading the previous two documents on Digital Identity, this one almost felt redundant or that it could’ve been included in the other two. Lifecycle management is just about conceptually the same for most aspects of technology. Digital Identity is not excluded from this.
This document outlines how proper authentication with subjects who use government systems. This document works closely with NIST SP 800-63 and takes a deeper dive into authentication. One aspect I found interesting was section 8.1, which talks about Authenticator threats. Authentication, especially in government systems, is extremely important. The table lists attacks like Side-channel attacks, phishing, and social engineering. Then in section 8.2, Threat mitigation strategies are outlined. Due to the nature of data shared with many government information systems, understanding the threats and threat mitigation strategies is extremely important.
This document just outlines the lifecycle of digital identity management. It goes into depth about the different levels of identity and how often they have to be authenticated to confirm the human identity of the user. It also goes into detail about single-use authentication, multi-factor authentication, etc… In a real-world application, too much authentication becomes burdensome in my opinion. It gets very annoying when I have to type in the code I just got texted to log in or check my email. Additionally, multi-factor authentication just simply isn’t worth it to me when logging onto something menial like Facebook or Twitter. The most annoying part of my morning is having to login 3 times before I can access any of my work. That being said, I am willing to do that for work, but I am not willing to do that every time I log onto Facebook. In my opinion, biometrics would solve the issue of authentication and availability. The face ID on my iPhone is very convenient and extremely reliable as well. I wish Apple would allow me to disable my passcode so I can just log on with only my face.
As someone who works in the Client Services arm of an IT department, I think usability considerations are a very important takeaway from the reading. Information security departments naturally focus on managing risk by implementing cost-effective controls, and the experience of the legitimate users of the information systems is an afterthought. However, ultimately information security teams would not exist if not for the fact that end users need to access information systems to perform their jobs, so it is important to evaluate how much of a burden is placed on the end users as a result of the implemented authentication methods.
Mitchell – I agree with you. In both the 800-63a and 800-63b readings it really stood out to me that there was a lot of consideration given for usability factors. I think it’s an important concept to remember that if the use of a certain security measure is too complex or burdensome (such as a very long, complex password) then it’s ultimately likely to lead to greater risk (for example, users writing down their passwords). I don’t think a lot of organizations do a great job thinking about the usability factors when proposing implementing new processes or controls. Not only is it important to ensuring effective security but it’s also a good starting point to develop training for end-users as new processes and systems are rolled out.
I felt that the records retention section is valuable. As an auditor you should review how long the company is an is supposed to keep their records. Sometimes if the record retention policy is not present, a company may keep their records to long, or not long enough. From a legal perspective, the records retention should be followed, sometimes in the event of a lawsuit, if the documents are available post the retention date then a company may be held liable for the potential judgement for as far back as the records indicate.
Michael, I agree with you. As someone who has worked in audit for a while, records retention is often an overlooked area. I also think you make good points about not just sticking with the minimum record retention requirement but keeping records too long. I have seen situations where records were kept past the retention period and then were allowed to be introduced into evidence for lawsuits. Another trouble area I have seen with records retention is for companies that are heavily involved in mergers and acquisitions, it is often difficult to catalog all of the information that is “coming over” with the acquisition. I’ve seen several messes where a previous company I worked for did not do a good job of inventorying all information that belonged to the acquired institution (digital AND hard copy) and it led to huge messes when trying to ensure the records retention policy was followed.
The authenticator lifecycle management section stood out to me in this reading. The reading noted, many events can occur over the lifecycle of an authenticator that can affect that
authenticator’s use. These events include binding, loss, theft, unauthorized duplication,
expiration, and revocation. Binding refers to the establishment of an association between a specific
authenticator and a subscriber’s account. Loss, theft, and unauthorized duplication refer to authenticators that have been compromised. Expiration refers to authenticators that have been issued with an expiration date, and lastly, revocation refers to authenticators removal of the binding between an authenticator and a credential the CSP maintains. The reading provides details on what should be done in each of these instances.