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:
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.
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). |
|
|
ü |
|
|
|
|
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). |
|
|
|
ü |
|
|
|
Require activation of the credential within a time period specified in the Credential Policy.
|
|
|
ü |
|
|
|
|
Require activation of the credential within a time period specified in the
Certificate Policy. |
|
|
|
ü |
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
|
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. |
|
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. |
|
4.4.1.2 |
|
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 |
|
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion: |
Y |
|
|
Y |
63A#0700 |
e) |
|
top management's acceptance of the documented risk analysis and selected treatment is maintained and retained; |
63 rev.3
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion from: |
Y |
|
|
Y |
63A#0710 |
|
|
For each comparable alternative applied the CSP SHALL also: |
63 rev.3
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion: |
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
|
|
Risk Acceptance and Compensating Controls |
Assessor-introduced criterion: |
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. |
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
|
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
|
||
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
|
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 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. |
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 |
|
|
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.
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 703 851 6813 |