Folks, In our last meeting and the emails that follow several of us made reference to those items that the IAWG should address under the current charter and under the current schema. Several folks suggested that they had a list in their head or in more tangible forms. My understanding remains that the IAWG retained the bulk of the old charter because the existing criteria continues to need maintenance and we do not have an understanding of the new schema and processes nor a charter that has been updated to reflect that new schema and processes - meanwhile CSPs continue to want to be assessed and certified. Below please find my best summary of the maintenance topics pertaining to the current process; which I assume will continue to operate until there is a transition to whatever comes next. It is also my understanding that the schedule for that transition may be soon; but it also may not. I would suggest that, at our next meeting, we create and prioritize a task list, as we have in the past. Please consider the list below suggestions. Although I consider it a much lesser priority, we have also, from time to time, been asked to comment on various other international or otherwise related documentation and schema. I believe we would be better positioned to do such things, if we had a list of pending issues and could track our priorities and the status of each item through to implementation. Hunting through my notes, I have: • What is our long-term plan for passkeys in 63-3? With regard to passkeys; the notice had been published but I do not believe we have identified our long-term approach, especially given that the current indication is that 63-4 will look the same, with the same un-assessable criteria. We had been looking at some draft criteria but had not identified an approach around the un-assessables. We have members that think passkeys are critical (starting with NIST). Also, since the notice was published it has been leveraged one or twice and those assessments have highlighted additional criteria which may need to be included. • OP_SAC criteria with conflicting numbers were identified OPB#0490 Receive acknowledgement of receipt of the credential before it is activated and its directory status record is published (and thereby the subscription becomes active or re-activated, depending upon the circumstances of issue). • OPB#0480 OPB#0490 Receive acknowledgement of receipt of the hardware token before it is activated and the corresponding certificate and its directory status record are published (and thereby the subscription becomes active or re-activated, depending upon the circumstances of issue). • OPB#0490 OPB#0500 Require activation of the credential within a time period specified in the Credential Policy. • OPB#0490 OPB#0500 Require activation of the credential within a time period specified in the Certificate Policy. • • 63A#0180 – additional breakdown to better reflect the ‘Implementation Resources’ document and to facilitate component proofing services which may provide specific capability for particular forms of evidence and their validation/applicant verification. I believe we discussed and agreed in principle that we could breakdown the strength of evidence criteria to support component systems. 63A#0180 The CSP SHALL collect from the Applicant / Service Consumer at least the following strength of evidence, as determined by the further requirements in Table 5-1: See comment in Guidance for 63A#0040 63A#0180 a) One piece of SUPERIOR evidence; OR 63A#0180 b) One piece of SUPERIOR or STRONG evidence IF the evidence’s issuing source, during its identity proofing event, confirmed the claimed identity by collecting two or more forms of SUPERIOR or STRONG evidence AND the CSP validates the evidence directly with the issuing source; OR This criterion encompasses the strength of identity evidence STRONG+ listed in NIST SP 800-63-3 Implementation Resources. 63A#0180 c) Two forms of evidence comprising of: PREV: Two pieces of STRONG evidence; OR 63A#0180 c) i) A first piece of STRONG evidence; AND 63A#0180 c) ii) A second piece of STRONG evidence. OR 63A#0180 d) Three forms of evidence comprising of: PREV: One piece of STRONG evidence plus two pieces of FAIR evidence. 63A#0180 d) i) One piece of STRONG evidence; AND 63A#0180 d) ii) A first piece of FAIR evidence; AND 63A#0180 d) iii) A second piece of FAIR evidence. • 63A# proposed new criteria to address the inclusion of ‘Comparable Alternatives’ per 63 rev.3 §5.4. Discussion started but not concluded. These criteria were developed for and successfully used in an assessment, accepted by the ARB accepted the criteria and the service was Approved. This change would formalize the criteria and make them available to all CSPs. It would also apply a consistent basis by which Comp.Alts could be assessed, rather than them being determined by individual assessors or even proposed/argued by CSPs. 4.4.1.2 (IAL2) Evidence Collection Requirements Y 63A#0190 The CSP SHALL document its justification, for each form of evidence it recognises and collects in fulfilling its CrP and these criteria, of how the strength of the evidence it collects satisfies the qualities identified in Table 5‑1 [see worksheet 63A_T5-1]. Assessor-introduced criterion Y 63A#0192 If the CSP has elected to apply a 'Comparable Alternative' means of recognising evidence in 63A#0190 it SHALL fulfill criteria 63A#0700 and 63A#0710. 4.4.1.3 (IAL2) Validation Requirements The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG. Y 63A#0200 The CSP SHALL, at a minimum, validate identity evidence at the same strength as that at which the evidence was collected. Kantara-specific requirement Y 63A#0210 The CSP SHALL document its justification, for each form of evidence it recognises and collects in fulfilling its CrP and these criteria, of how the strength of validation of the evidence it collects satisfies the qualities identified in Table 5‑2 [see worksheet 63A_T5-2]. Assessor-introduced criterion Y 63A#0212 If the CSP has elected to apply a 'Comparable Alternative' means of recognising evidence in 63A#0210 it SHALL fulfill criteria 63A#0700 and 63A#0710. The following criteria have been composed to allow the selection and use of a 'Comparable Alternative' form of evidence iaw §5.4 of NIST SP 800-63 rev.3. 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: Agencies SHALL demonstrate comparability of any chosen alternative, to include any compensating controls, when the complete set of applicable SP 800-63 requirements is not implemented. Y Y 63A#0700 The CSP SHALL justify any 'Comparable Alternative' form of evidence selection and validation, at either IAL2 or IAL3, as necessary for the applicable IAL, by ensuring that: 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document both the justification for any departure from normative requirements and detail the compensating control(s) employed. Y Y 63A#0700 a) an analysis of the risk(s) addressed by the NIST-specified controls and the degree of residual risk its implementation would achieve is determined and documented; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 b) an analysis of the risk(s) that may be introduced through the use of the alternative controls is determined and documented; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 c) different risks that may be introduced through the use of the alternative controls have been taken into account; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 d) controls have been selected and implemented such that the same or better net identity-proofing risk management and treatment is achieved; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: Expecting that any such measures must be recognised and approved by the service provider's senior management. Y Y 63A#0700 e) top management's acceptance of the documented risk analysis and selected treatment is maintained and retained; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0710 For each comparable alternative applied the CSP SHALL also: 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: As the basis for the client agency to determine that these measures meet their requirements Y Y 63A#0710 a) make available to the Service Consumers the results of its determination of comparability, as required by 63#5.4.01 a) to e) inclusive; and 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: To facilitate the client agency's ability to correctly use the comparable alternative Y Y 63A#0710 b) document any requirements for application of the comparable alternative so as to ensure that comparability is achieved in a Service Consumer's use of the service. • Clarifying edits for 63A T5-2 63A-T5-2#strg b) The CSP can demonstrate that the evidence which it has collected has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). The CSP can demonstrate that the evidence which it has collectaccepted has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). 63A-T5-2#supr a) The CSP can demonstrate that the evidence which it has collected has been confirmed as genuine by trained personnel and the use of appropriate technologies, including the integrity of any physical and cryptographic security features; The CSP can demonstrate that the evidence which it has collectaccepted has been confirmed as genuine by trained personnel and the use of appropriate technologies, including the integrity of any physical and cryptographic security features; 63A-T5-2#supr b) The CSP can demonstrate that the evidence which it has collected has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). The CSP can demonstrate that the evidence which it has collectaccepted has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). • Clarifying edits for 63A T5-3 63A-T5-3#strg a) ii) biometric comparison of the applicant to the identity evidence. Biometric comparison performed remotely SHALL adhere to all criteria 63A#0620 to 63A#0680 inclusive. biometric comparison of the applicant to the strongest piece of identity evidence provided to support the claimed identity. Biometric comparison performed remotely SHALL adhere to all criteria 63A#0620 to 63A#0680 inclusive. • 63B#0120 – FIPS 140 “verifier" 63B#0120 is taken word for word from 800-63B and requires “verifiers to meet FIPS 140 Level 1 or higher.” However, “verifiers” generally refers to an organization, typically the CSP. FIPS 140 is Security Requirements for devices, specifically cryptography. It seems most likely that the intention was to require cryptographic authenticators that meet FIPS 140. Should clarity or guidance be added to this criteria? 63B#0120 Federal agencies SHALL only operate verifiers which have been validated as meeting FIPS 140 Level 1 or higher. • 63B#0510 – What comes after 100 The criteria say, “The Verifier SHALL implement a rate-limiting mechanism which protects against online guessing attacks and limits consecutive failed authentication attempts on a single account to no more than 100.” In 800-63-3 this is given as, “Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.” The literal translation of this would be that after 100 failed attempts we would turn off an account and never speak to them again. Another reading would be that we make them reidentify, or we allow them to use a different factor, as described in 63B#1810, or they can reset their password. Naturally, into this ambiguity, CSPs like to insert creative thinking, including delays of between 20 second and a month, progressive delays and other forms of recovery. I would argue most of these exceed the current language and many of these vastly exceed the intention and the spirit of the criteria. Should the criteria identify what happens after 100 or provide guidance? 63B#0510 The Verifier SHALL implement a rate-limiting mechanism which: 63B#0510 a) protects against online guessing attacks; 63B#0510 b) limits consecutive failed authentication attempts on a single account to no more than 100. 63B#1460 The CSP SHALL limit consecutive failed authentication attempts on a single account to no more than 100. OPF#0070 Limit the number of failed authentications attempts to no more than 100 in any 30-day period. * 63A#0680, zeroizing the biometric sample –The IAWG discussed but I don’t think we concluded if we should leave in a clearly wrong but workable criteria or correct it (probably by Withdrawing it as not applicable to the identity proofing process). 63A#0680 The CSP SHALL zeroize the biometric sample (including any associated biometric data) immediately after any training or research data has been derived. With regard to zeroizing the biometric sample (63A#0680); I believe the criteria is flawed by virtue of some poor wording from NIST and the fact that the criteria as actually from 63B and dropped into 63A. The poor wording gives us a loophole by virtue of its odd wording, which sort of makes the criteria harmless, although I believe the more rigorous approach would be to withdraw it, as we have other imported 63B criteria. * Validation at Strong SP 800-63 and Kantara require that “The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG.(63 4.4.1.3; see also 63A#0200)” This is compared with verification which is only compared to the strongest piece of identity evidence. (63 5.3.1). Validating evidence at STRONG requires having “all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s).” AAMVA allows verification of DLs but there is no issuing, authoritative, or even credible source would validate a Permanent Resident Card, Native American Enhanced Tribal Card, “Enhanced ID cards,” U.S. Military ID, Permanent Resident Card or Native American Tribal Photo Identification Cards? Consequently, calling them SUPERIOR or STRONG isn’t really meaningful, if they cannot be validated that way. (There are some cool implementations that can read a passport and verify digital signatures, but for PIV, CAC, PIV-I (and TWIC?) you are going to need a card reader, so that mostly leaves out unsupervised. I think validating a digital signature is a fairly strong validation, even if it does not really COMPARE information with an issuing or authoritative source? Things really seemed odd to me, when we came to the conclusion that you would have to consider a US Navy CAC card a “FAIR” piece of evidence, because the DoD doesn’t validate CAC cards. ) For an unsupervised proofing, and working from NIST’s notional strength of evidence page, which TWO items can you compare with information held by an issuing or authoritative source? US Passport SUPERIOR Foreign e-Passport SUPERIOR Personal Identity Verification (PIV) card SUPERIOR Common Access card (CAC) SUPERIOR Personal Identity Verification Interoperable (PIV-I) card SUPERIOR Transportation Worker Identification Credential (TWIC) SUPERIOR Permanent Resident Card SUPERIOR Native American Enhanced Tribal Card SUPERIOR REAL ID cards STRONG+ Enhanced ID cards STRONG+ U.S. Uniformed Services Privilege and Identification Card (U.S. Military ID) STRONG+ Permanent Resident Card STRONG Native American Tribal Photo Identification Card STRONG Driver’s License or ID card (REAL ID non-compliant) STRONG Jimmy [cid:image001.jpg@01DB9DC2.0A456D60] Jimmy Jung www.Slandala.com<http://www.slandala.com/> 703 851 6813
In our effort to bring formalism to the IAWG, I may have gone overboard, but below please find the 63B#0120 – FIPS 140 “verifier" criteria update, requested in the last meeting Jimmy [cid:image003.jpg@01DBA202.03DAB220] Jimmy Jung www.Slandala.com<http://www.slandala.com/> 703 851 6813 PS - in the first paragraph of draft 63B-4, 2.2.2; does replay-resistant and authentication intent apply to all AAL2 or just authenticators procured by federal agencies? Change summary: Clarify the use of the term “Verifiers” in 63B#0120. Discussion: 63B#0090 Federal agencies SHALL only procure authenticators which have been validated as meeting FIPS 140 Level 1 or higher. 63B#0120 Federal agencies SHALL only operate verifiers which have been validated as meeting FIPS 140 Level 1 or higher. 63B#0120 is taken word for word from 800-63B and requires “verifiers to meet FIPS 140 Level 1 or higher.” It seems likely that this is a companion to 63B#0090 which requires authenticators that meet FIPS 140, indicating that the authenticator and the verifier should BOTH operate at FIPS 140; however, “verifiers” generally refers to an organization, typically the CSP. FIPS 140 identifies Security Requirements for devices, specifically cryptography; applying it as a criteria to an organization is awkward. In 63B#0090, the NIST language and our guidance ONLY applies this to authenticators “procured” by federal agencies; allowing for “bring-your-own” authenticators that do not meet FIPS 140. Which is to say, the criteria specifically allows authenticators in 63B#0090 that do not meet the criteria of 63B#0120. The following options are suggested for consideration: 1. Identify 63B#0120 as redundant with 63B#0090 2. Address this incongruity in the guidance 3. Tailor 63B#0120 to the “transaction”(i.e., the verification, vs the verifier) and the just the authenticators in 63B#0090 4. OK, option 4 should probably be option 3, but I didn’t look at draft 63-4 until later – steal language from Draft 63-4 (which may still need some tinkering) It should be noted that this only applies to federal agencies (and we do have agencies with or applying for certification). Specific Changes: OPTION 63B tag index KI_criterion (text in red in this column are revisions this version) Note - guidance will be added as KI-IAWG members develop it in response to usage & experience 1 63B#0120 Withdrawn - addressed by 63B#0090 2 63B#0120 Federal agencies SHALL only operate verifiers which have been validated as meeting FIPS 140 Level 1 or higher. As described in 63B#0090, this is intended to exempt user-provided (“bring-your-own) authenticators from having to meet the FIPS 140 requirements, particularly on the government-to-public use case. 3 63B#0120 Federal agencies SHALL verify FIPS 140 Level 1 (or higher) authenticators using equivalent cryptography. 4 63B#0120 Cryptography used by verifiers operated by or on behalf of federal agencies at AAL2 SHALL be validated to meet the requirements of [FIPS140] Level 1. As described in 63B#0090, this is intended to exempt user-provided (“bring-your-own) authenticators from having to meet the FIPS 140 requirements, particularly on the government-to-public use case. Original references: KIAF-1440 [cid:image002.png@01DBA202.03DAB220] 63B-3 4.2.2 Authenticator and Verifier Requirements Cryptographic authenticators used at AAL2 SHALL use approved cryptography. Authenticators procured by government agencies SHALL be validated to meet the requirements of FIPS 140 Level 1. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise of the platform in which they are running (e.g., by malware) and SHOULD NOT complete the operation when such a compromise is detected. At least one authenticator used at AAL2 SHALL be replay resistant as described in Section 5.2.8. Authentication at AAL2 SHOULD demonstrate authentication intent from at least one authenticator as discussed in Section 5.2.9. Communication between the claimant and verifier (the primary channel in the case of an out-of band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to MitM attacks. Verifiers operated by government agencies at AAL2 SHALL be validated to meet the requirements of FIPS 140 Level 1. DRAFT 63B-4 2.2.2.Authenticator and Verifier Requirements Authenticators used at AAL2 SHALL use approved cryptography. Cryptographic authenticators procured by federal agencies SHALL be validated to meet the requirements of [FIPS140] Level 1. At least one authenticator used at AAL2 SHALL be replay-resistant, as described in Sec. 3.2.7. Authentication at AAL2 SHOULD demonstrate authentication intent from at least one authenticator, as discussed in Sec. 3.2.8. Communication between the claimant and verifier SHALL occur via one or more authenticated protected channels. Cryptography used by verifiers operated by or on behalf of federal agencies at AAL2 SHALL be validated to meet the requirements of [FIPS140] Level 1. When a biometric factor is used in authentication at AAL2, the performance requirements stated in Sec. 3.2.3SHALL be met, and the verifier SHALL determine that the biometric sensor and subsequent processing meet these requirements. Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5. Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems. In all cases, verifiers SHOULD encourage the use of phishing-resistant authentication at AAL2 whenever practical since phishing is a significant threat vector.
In his first item below (“What is our long-term plan for passkeys in 63-3?”) Jimmy referred to the need to think beyond the immediate utility of the published Notice KI#2024-01. I actually think there are two action items here. The first is a short-medium term question which is to address the long-term plan, but he alludes to a more pressing concern in his last sentence (“Also, …”) which I believe should be taken on as an immediate action. The IAWG did not conclude its discussion regarding which criteria this Notice should include and I ask that this week’s meeting considers this as a priority since the Notice is being applied in current Assessments and needs to be re-issued to include those additional criteria. As a starter, I believe the following criteria should be added to a revised Notice: #0780, #0790, #0800, #1630, #1640, #1710. Other members may consider further criteria to be eligible. Thanks, Richard G. WILSHER CEO & Founder, Zygma Inc. www.Zygma.biz +1 714 797 9942 From: Jimmy Jung [mailto:jimmy.jung@slandala.com] Sent: Wednesday, 26 March, 2025 00:25 To: IAWG Subject: [WG-IDAssurance] An IAWG open/actionable list Folks, In our last meeting and the emails that follow several of us made reference to those items that the IAWG should address under the current charter and under the current schema. Several folks suggested that they had a list in their head or in more tangible forms. My understanding remains that the IAWG retained the bulk of the old charter because the existing criteria continues to need maintenance and we do not have an understanding of the new schema and processes nor a charter that has been updated to reflect that new schema and processes - meanwhile CSPs continue to want to be assessed and certified. Below please find my best summary of the maintenance topics pertaining to the current process; which I assume will continue to operate until there is a transition to whatever comes next. It is also my understanding that the schedule for that transition may be soon; but it also may not. I would suggest that, at our next meeting, we create and prioritize a task list, as we have in the past. Please consider the list below suggestions. Although I consider it a much lesser priority, we have also, from time to time, been asked to comment on various other international or otherwise related documentation and schema. I believe we would be better positioned to do such things, if we had a list of pending issues and could track our priorities and the status of each item through to implementation. Hunting through my notes, I have: · What is our long-term plan for passkeys in 63-3? With regard to passkeys; the notice had been published but I do not believe we have identified our long-term approach, especially given that the current indication is that 63-4 will look the same, with the same un-assessable criteria. We had been looking at some draft criteria but had not identified an approach around the un-assessables. We have members that think passkeys are critical (starting with NIST). Also, since the notice was published it has been leveraged one or twice and those assessments have highlighted additional criteria which may need to be included. · OP_SAC criteria with conflicting numbers were identified OPB#0490 Receive acknowledgement of receipt of the credential before it is activated and its directory status record is published (and thereby the subscription becomes active or re-activated, depending upon the circumstances of issue). ü OPB#0480 OPB#0490 Receive acknowledgement of receipt of the hardware token before it is activated and the corresponding certificate and its directory status record are published (and thereby the subscription becomes active or re-activated, depending upon the circumstances of issue). ü OPB#0490 OPB#0500 Require activation of the credential within a time period specified in the Credential Policy. ü OPB#0490 OPB#0500 Require activation of the credential within a time period specified in the Certificate Policy. ü · 63A#0180 – additional breakdown to better reflect the ‘Implementation Resources’ document and to facilitate component proofing services which may provide specific capability for particular forms of evidence and their validation/applicant verification. I believe we discussed and agreed in principle that we could breakdown the strength of evidence criteria to support component systems. 63A#0180 The CSP SHALL collect from the Applicant / Service Consumer at least the following strength of evidence, as determined by the further requirements in Table 5-1: See comment in Guidance for 63A#0040 63A#0180 a) One piece of SUPERIOR evidence; OR 63A#0180 b) One piece of SUPERIOR or STRONG evidence IF the evidence’s issuing source, during its identity proofing event, confirmed the claimed identity by collecting two or more forms of SUPERIOR or STRONG evidence AND the CSP validates the evidence directly with the issuing source; OR This criterion encompasses the strength of identity evidence STRONG+ listed in NIST SP 800-63-3 Implementation Resources. 63A#0180 c) Two forms of evidence comprising of: PREV: Two pieces of STRONG evidence; OR 63A#0180 c) i) A first piece of STRONG evidence; AND 63A#0180 c) ii) A second piece of STRONG evidence. OR 63A#0180 d) Three forms of evidence comprising of: PREV: One piece of STRONG evidence plus two pieces of FAIR evidence. 63A#0180 d) i) One piece of STRONG evidence; AND 63A#0180 d) ii) A first piece of FAIR evidence; AND 63A#0180 d) iii) A second piece of FAIR evidence. · 63A# proposed new criteria to address the inclusion of ‘Comparable Alternatives’ per 63 rev.3 §5.4. Discussion started but not concluded. These criteria were developed for and successfully used in an assessment, accepted by the ARB accepted the criteria and the service was Approved. This change would formalize the criteria and make them available to all CSPs. It would also apply a consistent basis by which Comp.Alts could be assessed, rather than them being determined by individual assessors or even proposed/argued by CSPs. 4.4.1.2 (IAL2) Evidence Collection Requirements Y 63A#0190 The CSP SHALL document its justification, for each form of evidence it recognises and collects in fulfilling its CrP and these criteria, of how the strength of the evidence it collects satisfies the qualities identified in Table 5‑1 [see worksheet 63A_T5-1]. Assessor-introduced criterion Y 63A#0192 If the CSP has elected to apply a 'Comparable Alternative' means of recognising evidence in 63A#0190 it SHALL fulfill criteria 63A#0700 and 63A#0710. 4.4.1.3 (IAL2) Validation Requirements The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG. Y 63A#0200 The CSP SHALL, at a minimum, validate identity evidence at the same strength as that at which the evidence was collected. Kantara-specific requirement Y 63A#0210 The CSP SHALL document its justification, for each form of evidence it recognises and collects in fulfilling its CrP and these criteria, of how the strength of validation of the evidence it collects satisfies the qualities identified in Table 5‑2 [see worksheet 63A_T5-2]. Assessor-introduced criterion Y 63A#0212 If the CSP has elected to apply a 'Comparable Alternative' means of recognising evidence in 63A#0210 it SHALL fulfill criteria 63A#0700 and 63A#0710. The following criteria have been composed to allow the selection and use of a 'Comparable Alternative' form of evidence iaw §5.4 of NIST SP 800-63 rev.3. 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: Agencies SHALL demonstrate comparability of any chosen alternative, to include any compensating controls, when the complete set of applicable SP 800-63 requirements is not implemented. Y Y 63A#0700 The CSP SHALL justify any 'Comparable Alternative' form of evidence selection and validation, at either IAL2 or IAL3, as necessary for the applicable IAL, by ensuring that: 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document both the justification for any departure from normative requirements and detail the compensating control(s) employed. Y Y 63A#0700 a) an analysis of the risk(s) addressed by the NIST-specified controls and the degree of residual risk its implementation would achieve is determined and documented; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 b) an analysis of the risk(s) that may be introduced through the use of the alternative controls is determined and documented; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 c) different risks that may be introduced through the use of the alternative controls have been taken into account; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0700 d) controls have been selected and implemented such that the same or better net identity-proofing risk management and treatment is achieved; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: Expecting that any such measures must be recognised and approved by the service provider's senior management. Y Y 63A#0700 e) top management's acceptance of the documented risk analysis and selected treatment is maintained and retained; 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion from: The agency SHALL implement procedures to document (etc.) Y Y 63A#0710 For each comparable alternative applied the CSP SHALL also: 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: As the basis for the client agency to determine that these measures meet their requirements Y Y 63A#0710 a) make available to the Service Consumers the results of its determination of comparability, as required by 63#5.4.01 a) to e) inclusive; and 63 rev.3 5.4 Risk Acceptance and Compensating Controls Assessor-introduced criterion: To facilitate the client agency's ability to correctly use the comparable alternative Y Y 63A#0710 b) document any requirements for application of the comparable alternative so as to ensure that comparability is achieved in a Service Consumer's use of the service. · Clarifying edits for 63A T5-2 63A-T5-2#strg b) The CSP can demonstrate that the evidence which it has collected has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). The CSP can demonstrate that the evidence which it has collectaccepted has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). 63A-T5-2#supr a) The CSP can demonstrate that the evidence which it has collected has been confirmed as genuine by trained personnel and the use of appropriate technologies, including the integrity of any physical and cryptographic security features; The CSP can demonstrate that the evidence which it has collectaccepted has been confirmed as genuine by trained personnel and the use of appropriate technologies, including the integrity of any physical and cryptographic security features; 63A-T5-2#supr b) The CSP can demonstrate that the evidence which it has collected has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). The CSP can demonstrate that the evidence which it has collectaccepted has had all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s). · Clarifying edits for 63A T5-3 63A-T5-3#strg a) ii) biometric comparison of the applicant to the identity evidence. Biometric comparison performed remotely SHALL adhere to all criteria 63A#0620 to 63A#0680 inclusive. biometric comparison of the applicant to the strongest piece of identity evidence provided to support the claimed identity. Biometric comparison performed remotely SHALL adhere to all criteria 63A#0620 to 63A#0680 inclusive. · 63B#0120 – FIPS 140 “verifier" 63B#0120 is taken word for word from 800-63B and requires “verifiers to meet FIPS 140 Level 1 or higher.” However, “verifiers” generally refers to an organization, typically the CSP. FIPS 140 is Security Requirements for devices, specifically cryptography. It seems most likely that the intention was to require cryptographic authenticators that meet FIPS 140. Should clarity or guidance be added to this criteria? 63B#0120 Federal agencies SHALL only operate verifiers which have been validated as meeting FIPS 140 Level 1 or higher. · 63B#0510 – What comes after 100 The criteria say, “The Verifier SHALL implement a rate-limiting mechanism which protects against online guessing attacks and limits consecutive failed authentication attempts on a single account to no more than 100.” In 800-63-3 this is given as, “Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.” The literal translation of this would be that after 100 failed attempts we would turn off an account and never speak to them again. Another reading would be that we make them reidentify, or we allow them to use a different factor, as described in 63B#1810, or they can reset their password. Naturally, into this ambiguity, CSPs like to insert creative thinking, including delays of between 20 second and a month, progressive delays and other forms of recovery. I would argue most of these exceed the current language and many of these vastly exceed the intention and the spirit of the criteria. Should the criteria identify what happens after 100 or provide guidance? 63B#0510 The Verifier SHALL implement a rate-limiting mechanism which: 63B#0510 a) protects against online guessing attacks; 63B#0510 b) limits consecutive failed authentication attempts on a single account to no more than 100. 63B#1460 The CSP SHALL limit consecutive failed authentication attempts on a single account to no more than 100. OPF#0070 Limit the number of failed authentications attempts to no more than 100 in any 30-day period. * 63A#0680, zeroizing the biometric sample –The IAWG discussed but I don’t think we concluded if we should leave in a clearly wrong but workable criteria or correct it (probably by Withdrawing it as not applicable to the identity proofing process). 63A#0680 The CSP SHALL zeroize the biometric sample (including any associated biometric data) immediately after any training or research data has been derived. With regard to zeroizing the biometric sample (63A#0680); I believe the criteria is flawed by virtue of some poor wording from NIST and the fact that the criteria as actually from 63B and dropped into 63A. The poor wording gives us a loophole by virtue of its odd wording, which sort of makes the criteria harmless, although I believe the more rigorous approach would be to withdraw it, as we have other imported 63B criteria. * Validation at Strong SP 800-63 and Kantara require that “The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG.(63 4.4.1.3; see also 63A#0200)” This is compared with verification which is only compared to the strongest piece of identity evidence. (63 5.3.1). Validating evidence at STRONG requires having “all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s).” AAMVA allows verification of DLs but there is no issuing, authoritative, or even credible source would validate a Permanent Resident Card, Native American Enhanced Tribal Card, “Enhanced ID cards,” U.S. Military ID, Permanent Resident Card or Native American Tribal Photo Identification Cards? Consequently, calling them SUPERIOR or STRONG isn’t really meaningful, if they cannot be validated that way. (There are some cool implementations that can read a passport and verify digital signatures, but for PIV, CAC, PIV-I (and TWIC?) you are going to need a card reader, so that mostly leaves out unsupervised. I think validating a digital signature is a fairly strong validation, even if it does not really COMPARE information with an issuing or authoritative source? Things really seemed odd to me, when we came to the conclusion that you would have to consider a US Navy CAC card a “FAIR” piece of evidence, because the DoD doesn’t validate CAC cards. ) For an unsupervised proofing, and working from NIST’s notional strength of evidence page, which TWO items can you compare with information held by an issuing or authoritative source? US Passport SUPERIOR Foreign e-Passport SUPERIOR Personal Identity Verification (PIV) card SUPERIOR Common Access card (CAC) SUPERIOR Personal Identity Verification Interoperable (PIV-I) card SUPERIOR Transportation Worker Identification Credential (TWIC) SUPERIOR Permanent Resident Card SUPERIOR Native American Enhanced Tribal Card SUPERIOR REAL ID cards STRONG+ Enhanced ID cards STRONG+ U.S. Uniformed Services Privilege and Identification Card (U.S. Military ID) STRONG+ Permanent Resident Card STRONG Native American Tribal Photo Identification Card STRONG Driver’s License or ID card (REAL ID non-compliant) STRONG Jimmy Jimmy Jung <http://www.slandala.com/> www.Slandala.com 703 851 6813
participants (2)
-
Jimmy Jung -
Richard G. WILSHER (＠Zygma Inc.)