Security Global Forum

This article is the third in a technical series on configuring and using #FIDO2capabilities in ISAM 9.0.7. If you haven’t already done so, please read and complete the exercises in my first and second FIDO2 technical articles as here I’ll be picking up where the second article left off.

What authenticator is that?

Let’s take another look at the registration table for FIDO2 registrations as available at the end of the second technical article in this FIDO2 series:

Notice the empty “Brand” column? This column is used to display information about the make and model of the authenticator used for a particular registration, however it can only be populated if two conditions hold true:

1. During registration, the authenticator returned attestation data in the FIDO2 message payload. Whether or not this occurs comes down to several factors including:
   a) Does the authenticator support attestation.
   b) Does the request to the authenticator for registration include an indication that attestation is desired (this is part of the WebAuthn API, and by default the ISAM registration page sets attestationConveyancePreference to “direct”, which means to ask for attestation).
   c) Does the user consent to allowing attestation data to be shared with the server (recall the “Allow” dialog in Chrome during registration that I mentioned in the first article).
2. The FIDO2 server can correlate the attestation data back to information in a metadata document stored on the server (we don’t have any of these yet).

So far our configuration and the example authenticator I’ve been using (Mac Touchbar on Chrome) does support the collection of attestation data, but how can we show/prove this?

There is actually a lot more information available in a registration record than is currently displayed in the out-of-the-box device management page we have been using. If you recall at the very end of my last FIDO2 article, we added a fido2LoginDetails attribute to the credential during FIDO2 authentication. The attribute value gives us a hint as to other available information. I’ve taken the value of that attribute from my environment, and extracted one part of the JSON object called “registration”, pretty-printed it and reproduced here:

Notice the aaGuid? This is a FIDO2 concept and stands for Authenticator Attestation Globally Unique Identifier. You can read more about the technical details of an AAGUID in the metadata specification here.

Also notice the attestationType. A type of "Self" actually indicates that there is not actually any proof that the authenticator is the make/model it claims to be via the AAGUID – it’s by the client (browser) self-asserted using a self-signed certificate. Even so, if all we are doing is using the AAGUID for friendly display purposes of what we believe the registration claims to be, it’s still a nice-to-have. You can read a lot more about attestation types and their relative strength in this FIDO Alliance article.

In our case, what we want is a FIDO2 metadata file (read about metadata files in this specification if you want the details) that can provide some brand information for display in the registrations page. Typically you would get this from the vendor of the authenticator, and if you have used an authenticator from another vendor (for example a Yubikey), you should do that. To the best of my knowledge, Google does not provide one for the self-attested Chrome+MacTouchbar platform authenticator, but we can make one up ourselves. The bare minimum format that should be provided for ISAM’s consumption is something like this:

{
"description": "Google Chrome Mac Touchbar",
"aaguid":"adce0002-35bc-c60a-648b-0b25f1f05503",
"protocolFamily": "fido2",
"attestationRootCertificates": [],
"attestationTypes": [15880],
"icon": "https://www.google.com/chrome/static/images/chrome-logo.svg"
}

The icon can be a URL like I’ve shown above, or a data:image with the embedded base64 content of an image included (that is common in most vendor-provided metadata). The attestationRootCertificates is empty because the attestation type is "Self" attestation and there is no trust root. The attestationTypes values come from the FIDO Metadata Statement specification and in this case the value of 15880 matches that for self attestation, also known as basic_surrogate.

In other authenticator vendor metadata would typically contain one or more real root CA certificates.

For now, let’s create a file (I’ve called google-madeup-metadata.json) with the content above and upload it to ISAM’s FIDO2 metadata repository, then edit our RP to use it, as shown:

Be sure to save your RP, deploy changes, and publish the configuration.

Now refresh emily’s view of the device management page: https://www.iamlab.ibm.com/mga/sps/mga/user/mgmt/html/device/device_selection.html

Notice that the registration now shows branding information since we have been able to associate the AAGUID from the registration with a Metadata file that is enabled for the relying party configuration.

Try a usernameless login flow (https://www.iamlab.ibm.com/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:fido2usernameless) as emily, and inspect the value of the fidoLoginDetails attribute – you’ll see it contains more information now, including the details of the metadata document with which the registration is associated.

Please Note: Hopefully this helps you understand that it is possible to code in Javascript any enforcement policy you wish that is related to the metadata associated with a registration – during either registration or authentication flows.

Restricting registration to only metadata-attested authenticators

When you were editing the relying-party configuration, did you notice the Metadata Enforcement checkbox?

Try turning that on in your relying-party configuration, and disabling the use of the google metadata document we just uploaded. Then, as emily, delete and attempt to re-create your registration. You’ll notice ISAM rejects the registration attempt because it cannot be linked back to metadata.

The Metadata Enforcement check is only done by ISAM during registration flows. You could also enforce it during authentication flows (for example if you removed use of a metadata document after some users had already registered those types of authenticators) by crafting some code in the mediator during assertion results. I’ll leave this as an exercise for you to try if interested.

Other FIDO2 Relying-Party configuration options

There are several other panels in the relying-party editor wizard that you can take a look at. I find these are relatively self-explanatory and cover topics like:

• Supported attestation types and formats. These provide coarse-grained registration policy.
• The algorithm list that ISAM supports for FIDO2 authenticators that will be returned in attestation and assertion options requests.
• Some specific parameters for Android SafetyNet attestation (used by Chrome browser on Android phones)
• Permitted web origins (mostly you just set this to the top-level URL of your website)

There is one other non-obvious configuration item for a relying-party in ISAM, called Administrative Group. This is related to consumers of the FIDO2 service outside of ISAM itself, and their ability to make FIDO2 server calls on behalf of any username. We’ll see this in action in a future article.

What’s next?

There are still a few more FIDO2 topics to explore including support for consuming the FIDO2 service from outside of the AAC / WebAuthn relying party support built into ISAM itself. In my next article I think I’ll cover the web services interface to the ISAM FIDO2 service, which will also be a good starting point for talking about non-WebAuthn clients of FIDO2.

Originally Published: 6/25/2019