Requirements for security of MDC, DPK and attestation

[keikoit]

For high assurance services, RPs can accept the minimum requirements that are either

1. (MDC with no attestation) + (DPK with attestation), or
2. (MDC with attestation) + (DPK with no attestation required)

To achieve what RPs need to know about detecting an access from a new device, attestation can be hardware-protected provenance type or integrity-check type provided by platform.
Integrity-check type attestation, e.g.,SafetyNet, Apple attestation, can be userd with DPK by RPs to securely identify an MDC access from a new device IF the platform protects private keys securely.

Reference:
https://docs.google.com/presentation/d/1wy5y0pvdQATmZOfPvljTRtljtiRJmiM_hGTbdYeH5Lo/edit?usp=sharing

[timcappalli]

Hi @keikoit, you marked this as a feature proposal, but I don't see any ask here.

DPK and DPK attestation are already proposed for Level 3 (#1658).

[maxhata]

We want to articulate what the requirements are from security sensitive services and RPs.

[sbweeden]

I concur with the requirements. Many RPs want the one-touch-and-done strong authentication UX that attested, device-bound credentials offer. The spec itself is unlikely to influence whether or not these requirements will ever be met unless certain features, particularly attestation of all authenticators (including platform), are made mandatory-to-implement. Additionally, RPs want to be able to have more influence over the clients credential creation process. At present the opposite is true - the client decides what happens, and RPs are required to adapt to the result.

[Firstyear]

From the view of an RP that has strict certification requirements, I think DPK still isn't enough to make mobile devices trustworthy because they implicitly are binding a credential to a third party account. This makes them ineligible for common criteria authentication systems. I think that for all the effort going into DPK, it's likely we'll see RP's not use it due to it's complexity, and the nature of credentials being synced and third party controlled. So my opinion @keikoit is that you should avoid MDC in high assurance scenarios, in favour of FIDO2 certified keys with strict attestation checks around the AAGUIDS in use. It is far simpler to audit and manage from a risk perspective.

[timcappalli]

Hi all - there is no spec change ask here, so closing the issue.

Based on previous discussions, the requirements for security sensitive services and RPs are well understood, which is why many of the changes in L3 were proposed and added.

I believe this specific conversation is occurring across the FIDO xDWGs and the WebAuthn Community Adoption Group. This repo is for WebAuthn spec issues.

[kkoiwai]

I would like to suggest adding Firstyear's remark to the security consideration section.

From the view of an RP that has strict certification requirements, I think DPK still isn't enough to make mobile devices trustworthy because they implicitly are binding a credential to a third party account. This makes them ineligible for common criteria authentication systems. I think that for all the effort going into DPK, it's likely we'll see RP's not use it due to it's complexity, and the nature of credentials being synced and third party controlled. So my opinion @keikoit is that you should avoid MDC in high assurance scenarios, in favour of FIDO2 certified keys with strict attestation checks around the AAGUIDS in use. It is far simpler to audit and manage from a risk perspective.

[timcappalli]

IMO, this should go in FIDO Alliance deployment guidance, not the WebAuthn specification, but I'd be interested to hear others' opinions on this.

[kkoiwai]

Could you please reopen this issue, or shall I post a new one?

[timcappalli]

Please update the title and original description to more accurately represent the ask.

[emlun]

I agree with @timcappalli - I don't think it's the spec's role to suggest how outside regulations or certifications should judge the features of the spec. DPK is complex, yes, and if anything is unclear we should fix that of course, but I see no reason we should caution against its use.

[emlun]

2022-11-16 WG call: Given the inactivity we'll close this again, until discussion continues.