Intent to Ship: CTAP2 credBlob extension

[Adam Langley]

Contact emails

a...@chromium.org

Specification

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-credBlob-extension

API spec

Yes

Summary

CTAP is the protocol used between computers and security keys. CTAP 2.1 defines a security key extension called credBlob that is designed to store a hash value that can be used to authenticate externally provided data. This feature involves plumbing that value through WebAuthn to let the security key see it.

Blink component

Blink>WebAuthentication

TAG review

No movement on WebAuthn TAG review in general: https://github.com/w3ctag/design-reviews/issues/577. No intending to wait.

TAG review status

Pending

Risks

Interoperability and Compatibility

This "feature" just involves plumbing the credBlob extension from WebAuthn to the security key interface. In theory other browser implementations mightn't need explicit support at all as WebAuthn is designed to allow a generic transform from Javascript to CBOR (and back) to transparently support all extensions. However, if Firefox, Safari and others don't work this way (and I suspect they don't) then it's possible that they wouldn't bother to add the plumbing for this extension.

Gecko: No signal Have attempted to contact Mozilla's replacement for J. C. Jones but to no avail. Mozilla are no longer active in the W3C WG either.

Microsoft have, in the past, contributed security key functionality to Firefox and may do so again.

WebKit: No signal

Web developers: No signals (One unrelated web developer reached out to us about wanting this.)

Activation

This feature will depend on users having a suitable security key.

Security

This plumbs an extra value along with a WebAuthn request; a surface which is already exposed.

Debuggability

credBlob support will be added to the virtual authenticator that can be enabled via DevTools. The next revision of the WebAuthn spec should include WebDriver controls to enable support for automated testing.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1191071

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5541178411843584

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ

[Mike West]

On Mon, Mar 22, 2021 at 9:19 PM Adam Langley <a...@chromium.org> wrote:

Contact emails

a...@chromium.org

Specification

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-credBlob-extension

API spec

Yes

Summary

CTAP is the protocol used between computers and security keys. CTAP 2.1 defines a security key extension called credBlob that is designed to store a hash value that can be used to authenticate externally provided data.

Can you elaborate on this use case a bit?

 

This feature involves plumbing that value through WebAuthn to let the security key see it.

Blink component

Blink>WebAuthentication

TAG review

No movement on WebAuthn TAG review in general: https://github.com/w3ctag/design-reviews/issues/577. No intending to wait.

This review request has been sitting around since November. I pinged it, but I agree that we don't need to wait for it to complete at this point.

TAG review status

Pending

Risks

Interoperability and Compatibility

This "feature" just involves plumbing the credBlob extension from WebAuthn to the security key interface. In theory other browser implementations mightn't need explicit support at all as WebAuthn is designed to allow a generic transform from Javascript to CBOR (and back) to transparently support all extensions. However, if Firefox, Safari and others don't work this way (and I suspect they don't) then it's possible that they wouldn't bother to add the plumbing for this extension.

Gecko: No signal Have attempted to contact Mozilla's replacement for J. C. Jones but to no avail. Mozilla are no longer active in the W3C WG either.

https://github.com/mozilla/standards-positions/issues/456 hasn't moved since it was filed in November. It's not precisely this extension, but I pinged it in the hopes of finding a good contact to chat with.

 

Microsoft have, in the past, contributed security key functionality to Firefox and may do so again.

WebKit: No signal

Would you mind dropping a line to webkit-dev@, as requested in https://bit.ly/blink-signals.

 

Web developers: No signals (One unrelated web developer reached out to us about wanting this.)

Activation

This feature will depend on users having a suitable security key.

Security

This plumbs an extra value along with a WebAuthn request; a surface which is already exposed.

The security and privacy teams will meet to discuss this week's intents on Tuesday; my intuition here is that this isn't going to expose data above and beyond what the security key's challenge response is meant to expose, and acts more as a convenience for the developer that allows them to avoid a server-side lookup. Is that more or less accurate?

Debuggability

credBlob support will be added to the virtual authenticator that can be enabled via DevTools. The next revision of the WebAuthn spec should include WebDriver controls to enable support for automated testing.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1191071

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5541178411843584

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLyOW-364XX%2BMtskpY4ovPZBn%3D9S8CSMDU680dpu_Z9e5w%40mail.gmail.com.

[Adam Langley]

On Wed, Mar 24, 2021 at 1:29 AM Mike West <mk...@chromium.org> wrote:

Summary

CTAP is the protocol used between computers and security keys. CTAP 2.1 defines a security key extension called credBlob that is designed to store a hash value that can be used to authenticate externally provided data.

Can you elaborate on this use case a bit?

I think I wrote more in the chromestatus entry but perhaps in a field that isn't included in the intent email.

The situation is that a credential is getting created on a security key via the web, but it'll later be used in a non-web context. In Microsoft's case the credBlob value will be the SHA-256 hash of some Active Directory stuff. When the user is signing into a new laptop then this that serves to convince the new laptop that the information that it's getting over the network isn't lies. It trusts that the legitimate owner inserted their security key, but it doesn't know that the network is friendly.

That is not a precise description, and I might have misunderstood some details! The reason that I think the details are unimportant is that there's already a binary blob that a website sets on a new credential and which is returned when the credential is used: the user handle. So this information could be hacked in there, but Microsoft are doing it more cleanly. The only reason that this involves an IDL change at all is because of the way that authenticator extensions happened to be implemented in Blink.

Gecko: No signal Have attempted to contact Mozilla's replacement for J. C. Jones but to no avail. Mozilla are no longer active in the W3C WG either.

https://github.com/mozilla/standards-positions/issues/456 hasn't moved since it was filed in November. It's not precisely this extension, but I pinged it in the hopes of finding a good contact to chat with.

I think the new Mozilla person for WebAuthn is Daniel Veditz, but I haven't heard from him in a couple of months about this. (Although I completely understand that he's covering a lot of standards for Mozilla and it's perfectly reasonable that WebAuthn isn't his priority.)

Microsoft have, in the past, contributed security key functionality to Firefox and may do so again.

WebKit: No signal

Would you mind dropping a line to webkit-dev@, as requested in https://bit.ly/blink-signals.

https://lists.webkit.org/pipermail/webkit-dev/2021-March/031755.html (and have updated the chromestatus entry with that link).

 

 

Web developers: No signals (One unrelated web developer reached out to us about wanting this.)

Activation

This feature will depend on users having a suitable security key.

Security

This plumbs an extra value along with a WebAuthn request; a surface which is already exposed.

The security and privacy teams will meet to discuss this week's intents on Tuesday; my intuition here is that this isn't going to expose data above and beyond what the security key's challenge response is meant to expose, and acts more as a convenience for the developer that allows them to avoid a server-side lookup. Is that more or less accurate?

It's not quite to avoid a server-side lookup as I understand it (see above), but this is very similar to the user handle value that is already processed in the same way so I don't believe there are any additional security or privacy worries that aren't already covered by WebAuthn.

Cheers

AGL 

[Yoav Weiss]

On Wednesday, March 24, 2021 at 7:47:23 PM UTC+1 Adam Langley wrote:

On Wed, Mar 24, 2021 at 1:29 AM Mike West <mk...@chromium.org> wrote:

Summary

CTAP is the protocol used between computers and security keys. CTAP 2.1 defines a security key extension called credBlob that is designed to store a hash value that can be used to authenticate externally provided data.

Can you elaborate on this use case a bit?

I think I wrote more in the chromestatus entry but perhaps in a field that isn't included in the intent email.

The situation is that a credential is getting created on a security key via the web, but it'll later be used in a non-web context. In Microsoft's case the credBlob value will be the SHA-256 hash of some Active Directory stuff. When the user is signing into a new laptop then this that serves to convince the new laptop that the information that it's getting over the network isn't lies. It trusts that the legitimate owner inserted their security key, but it doesn't know that the network is friendly.

That is not a precise description, and I might have misunderstood some details! The reason that I think the details are unimportant is that there's already a binary blob that a website sets on a new credential and which is returned when the credential is used: the user handle. So this information could be hacked in there, but Microsoft are doing it more cleanly. The only reason that this involves an IDL change at all is because of the way that authenticator extensions happened to be implemented in Blink.

Gecko: No signal Have attempted to contact Mozilla's replacement for J. C. Jones but to no avail. Mozilla are no longer active in the W3C WG either.

https://github.com/mozilla/standards-positions/issues/456 hasn't moved since it was filed in November. It's not precisely this extension, but I pinged it in the hopes of finding a good contact to chat with.

I think the new Mozilla person for WebAuthn is Daniel Veditz, but I haven't heard from him in a couple of months about this. (Although I completely understand that he's covering a lot of standards for Mozilla and it's perfectly reasonable that WebAuthn isn't his priority.)

Microsoft have, in the past, contributed security key functionality to Firefox and may do so again.

WebKit: No signal

Would you mind dropping a line to webkit-dev@, as requested in https://bit.ly/blink-signals.

https://lists.webkit.org/pipermail/webkit-dev/2021-March/031755.html (and have updated the chromestatus entry with that link).

 

 

Web developers: No signals (One unrelated web developer reached out to us about wanting this.)

It's hard to understand from this who wants this to ship and would use it if we do.

You mentioned Microsoft potentially using this (for their corp machines, IIUC). Anyone else that would like to use this?

[Adam Langley]

On Thu, Mar 25, 2021 at 1:55 AM Yoav Weiss <yoav...@chromium.org> wrote:

It's hard to understand from this who wants this to ship and would use it if we do.

You mentioned Microsoft potentially using this (for their corp machines, IIUC). Anyone else that would like to use this?

As far as I'm aware the answer is Microsoft at the moment. As noted, WebAuthn already has one of these values, the user handle, and one value should serve nearly all needs. It seems some complex deployments want a second such value rather than trying to overload the existing one, and that seems fine?

(The majority of WebAuthn Level 2 and CTAP 2.1 are addressing edge cases needs like this. It's a cleanup cycle after Level 1 and CTAP 2.0.)

Cheers

AGL 

[Akshay Kumar]

The use case description above is quite accurate. Microsoft wants to use this functionality in Active Directory scenario for machine joining purpose. And the functionality is similar to user-handle but in a more clean way. During credential creation, a small blob containing server identity is put on the security key.  Then user goes to provision some machine in OOBE context and system components uses this identity for verification purpose. 

We very much intend to use this feature. Let us know if you need more details. 

Thanks

Akshay

Microsoft.

[Mike West]

LGTM1. Thanks for following up with our friends in the TAG, and for giving me more insight into the use cases.

-mike

[Yoav Weiss]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/59b2ea32-6c99-4c19-a654-bd811fbf6de3n%40chromium.org.