ESR update for CMFA

[woodbe]

I posted the current ESR as an asciidoc file. What I am not sure of, regarding integrating CMFA, is whether I should create a full new section regarding CMFA (duplicating the description, use cases, etc), or merge them into the current sections, probably under subheadings.

I think a full section may be better, since it would provide an easier look at each one, but could go either way.

Does anyone have a preference?

[n-kai]

@woodbe

I agree to create a full new section regarding CMFA so that the CCDB can easily recognize what the new one that they have to review and authorize is.

[n-kai]

I have a question about CMFA usage.

First of all, it’s better to define concrete CMFA usage or use case that cover the stakeholder's interest and we should define threats, security objectives and requirements in the ESR based on such use cases.

According to *1) DISA later identified walking gait as a particularly important biometric because facial or fingerprint recognition in a tactical environment is challenging when warfighters are wearing gloves, goggles and helmets.

*1) https://defensesystems.com/articles/2019/02/06/dod-mobile-biometric-id.aspx

If the CMFA should work in such environment, some factors like keyboard typing and biometric such as face and eye can’t be used for CMFA.

The following is an example how the CMFA works under such condition.

1. User unlock the device using biometrics before wearing gloves, goggles and helmets.
2. The device remains unlocked as long as it connects a trusted Wi-Fi network
3. If the connection is broken, the device tries to continuously authenticates a user using second factors such as gait or activity patterns
4. The device locks when there is no input from sensors (i.e. device stand still) for certain amount of time
5. If the anomaly is detected, the device locks or request an additional input (e.g. air written signature) to continuously authenticate a user

Based on the above use case, ESR can define the following security requirements. 1) Secure connection to the Wi-Fi (See 2) 2) Required accuracy of second factor authentication (gait or activity pattern) (i.e. FAR/FRR) (See 3) 3) Secure configuration of inactivity time (e.g. don’t allow too long inactivity time) (See 4) 4) Required accuracy of backup factor authentication (e.g. air written signature) (i.e. FAR/FRR) (See 3) 5) Detection of observation-based attack (e.g. observing and reproducing in-air handwriting)

Brian’s proposal (Continuous Multi-Factor Authentication Proposal, June 24, 2020) also defines the CMFA usage but I am not sure if it cover the DoD’s interest (or should the iTC defines such use case imaging how the CMFA can be used in various environment?)

[woodbe]

I agree that is one of the scenarios, but I have also been told about others that aren't "in the field". One I have heard of is someone at base (for simplicity here, I'm going to assume permanent, like the Pentagon or at the home base when not deployed). So once the device has determined their identity, maintaining it allows access to other things, like doors (i.e. NFC/BLE to a badge reader) or to a computer (likely BLE, but not sure). Here though, things like the Wi-Fi would be more prevalent (since the base would likely be covered by it), but other sensors, such as face/fingerprint are more applicable because they aren't deployed.

So while I completely agree that the above is a difficult scenario, it isn't the only one I have heard from the DOD.

[n-kai]

There are several ways of doing CMFA (see *1) but we can’t develop the cPP/SD that can cover all variation. So we have to limit our focus to a few use cases that our stakeholders are really care about to save our resource.

*1) https://arxiv.org/pdf/2001.08578.pdf

[woodbe]

I agree we can't cover everything, but I also don't think we can handle this in a way that provides a vendor with the ability to handle different scenarios.

[n-kai]

Do you mean that we should handle only those use cases you proposed in "Continuous Multi-Factor Authentication Proposal, June 24, 2020" because the use case only use reliable authentication factor like Bluetooth connectivity? I understand that motion based authentication (e.g gait or activity pattern) can't achieve high performance (i.e. low FAR/FRR).

[gfiumara]

If added, I think it's necessary to have CMFA in a separate section.

Do we still call this a "Biometric Product" in that case? CMFA uses biometric products as one form of authentication, but I have a hard time aligning network connectivity, etc. with biometrics.

Regarding use cases, DISA has a promo video with several: https://vimeo.com/244398484

[woodbe]

My thinking, at this point, is that we actually create a full, second ESR that governs the CMFA. My initial thinking had been that we could readily modify the ESR, just a few additions, and it would be good. But on looking at the content more, it looks more appropriate to create a second ESR, independent from the one we used for the current cPP. While I think all the stuff we have is a great template (and may make it quicker to completion than the initial docs), I think this pretty much needs to be considered an independent effort.

I don't know if that will cause problems, overall. For example, do we need to get the CCDB to approve a new ESR (which is probably the real issue, since we have been told that modifications to the existing one is already OK without their approval), but it may also allow for parallel work if CMFA draws in other interested parties that aren't interested specifically in the biometrics side of things (not sure if that would happen, but it could).

Thanks for the video, I will check it out.

I created a new label for CMFA Use Case so we can specifically filter for them more easily.

[n-kai]

@woodbe I hear the CCDB will ask iTCs about their future plans through the CCUF and our feedback will be discussed at the CCUF-CCDB joint session at November. If you input this CMFA work to the CCDB, we should recommend the CCDB to review the updated ESR when it's available and issue the new position statement if schemes can support this new activity.

[woodbe]

Yes, I will add this to my short presentation. I haven't started working on it yet, but this would be one of the primary topics (in addition to the PAD toolboxes).