MDS Validations during Authentication

[Thamindu Dilshan Jayawickrama]

Hi,

According to the literature I could found so far, being FIDO compliant only expects, metadata validations during device registration. The mds3 spec has also mentioned only about attestation validations.

The metadata statements contains the "Trust Anchor" required to validate the attestation object, and they also describe several other important characteristics of the authenticator.

Also the metadata service tests in FIDO conformance test tool only check for the device registration flow.

1. Does this mean being FIDO compliant doesn't require metadata validations during authentication?

2. Can metadata of already registered device being invalidated after certain time period? Isn't this a valid scenario?

I'm bit confused on above too questions and I believe second one is a valid concern. Appreciate your help to get this cleared.

Thanks

[Paul Van Staden]

1. Does this mean being FIDO compliant doesn't require metadata validations during authentication?

Yes. Due to the way encryption and cryptographic proof is used, once you are done with the key exchange and validation it can use  the cryptography correctly.

2. Can metadata of already registered device being invalidated after certain time period? Isn't this a valid scenario?

Yes it can, you are supposed to keep the AAGUID as part of the registered token. When you process the metadata update you should be able to invalidate a registered token based on the metadata.

Tokens can get compromised in a variety of ways, most of them are hardware manufacturer compromises. Imagine somewhere a token signing key gets compromised.

[Philipp Junghannß]

how should one go tho about invalidation, especially if a user has only keys from the same vendor/type that got invalidated?

also on what criteria does one even invalidate a token based on the MDS in the first place, is there a flag somewhere in the MDS (maybe even an entry that's currently revoked one could use as example)

Regards

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/2282383e-143f-4d0e-8a75-bffe3e73acd0n%40fidoalliance.org.

[DUBOUCHER Thomas]

Hi,

 

Metadata are expected to be updated depending on several external causes: e.g. negative, authenticator compromise, trust anchor revocation or positive, authenticator certification, trust anchor rotation.

 

As such, Relying Parties are expected to poll the Metadata Service ~once a day.

 

Also, the attestation is done only during registration, but it is expected that Relying Parties track the registration data – once an authenticator metadata is changed, Relying Parties should update the status of authenticator that have been previously registered.

 

For instance, if an authenticator is compromised, e.g. leaked attestation private key, the metadata will be updated to reflect this information. Upon polling the metadata, the Relying Party seeing that the authenticator is compromised, could go through all registered authenticators of the same model, revoke them, and notify the user of the revocation.

 

Best regards,

 

--

Thomas Duboucher

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/2d33455d-f870-4d80-9790-607553ca0977n%40fidoalliance.org.

[John Bradley]

It is also a good idea to keep the attestation certificate as well as the AAGUID.

If a batch key is compromised only that batch needs to be considered for revocation.   

The status report https://fidoalliance.org/specs/mds/fido-metadata-service-v3.0-ps-20210518.html#statusreport-dictionary 

Should contain the base64 encoded certificate for the impacted batch, so If you have the certificate you only need to be concerned about keys that match and not every key with that AAGUID.

Batches are typically 100,000 keys and an AAGUID may represent many millions of keys depending on the vendor. 

Also while you may want to block registration for keys in that batch going forward, you may not want to revoke a registration that happened before the compromise.

There are other status entries that might trigger some action, eg titan BLE U2F keys did have a security issue that caused a recall/replacement key to be sent.

Regards

John B.

[Thamindu Dilshan Jayawickrama]

Hi all,

Thanks for the valuable explanations. 

Adding some context to @thomas's answer, according to FIDO docs, there's no need to fetch mds endpoints that frequently and they recommended of 1 month time interval.

However by inspecting some sample mds data I obtained, next update is to come in 10-11 months period. 

Regards,

Thamindu

[John Bradley]

MDS3 is updated every day.   MDS2 which is no longer updated had a monthly cycle. 

Some sites that might be filtering uncertified authenticators may want to force a refresh if they see a unknown AAGUID.

I believe some people using it for eIDAS are required to check for revocations and security issues dayly.  

However most RP should be fine with once a month as long as they are not filtering unknown AAGUID.

John B