Using CTAP2 credentials via CTAP1

[Fabian Henneke]

Is there any reason why a credential generated using CTAP2 should not be made available for authentication requests via CTAP1 (assuming that the registration ceremony did not use any extensions which impose restrictions on credential usage)? 

I am asking this question since the CTAP2 and WebAuthn specification seem to only discuss the opposite situation (credentials initially created via CTAP1 being used for authentications via CTAP2). This question has been the topic of a SoloKey issue, where a decision was made to add support for accessing CTAP2 credentials via CTAP1. I personally don't see any issue with that, but would like to get official feedback on this.

[Ackermann Yuriy]

CTAP1 U2F responses are being re-encoded in CBOR CTAP2 structures. This is possible because FIDO2 servers can support U2F CTAP attestation. CTAP2 has a lot more features, fields, etc, that needed to its processes, such clientpin, uv, rk etc etc etc. So there is no way to encode CTAP2 back to CTAP1 RAW, but CTAP1 can be encoded in CTAP2 CBOR.

Regards. Yuriy

On Thu, 31 Oct 2019 at 1:31 AM, Fabian Henneke <fabian....@gmail.com> wrote:

Is there any reason why a credential generated using CTAP2 should not be made available for authentication requests via CTAP1 (assuming that the registration ceremony did not use any extensions which impose restrictions on credential usage)? 

I am asking this question since the CTAP2 and WebAuthn specification seem to only discuss the opposite situation (credentials initially created via CTAP1 being used for authentications via CTAP2). This question has been the topic of a SoloKey issue, where a decision was made to add support for accessing CTAP2 credentials via CTAP1. I personally don't see any issue with that, but would like to get official feedback on this.

--
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/76bb7102-20c7-4d3f-a5b1-fc83e5904877%40fidoalliance.org.

--

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

[Fabian Henneke]

I'm sorry, I should have formulated my question more carefully: I am interested in the situation where an authenticator speaks both CTAP1 and CTAP2, but a credential has been created via the CTAP2 protocol. Is it fine for the authenticator to make this credential (i.e., its key material) available also for requests coming in via CTAP1?

[Ackermann Yuriy]

No. U2F must have its own keystore. The client will send request with keyid to both U2F and FIDO2 authrs on the device.

[Fabian Henneke]

Do you know what the reasoning for this requirement is? Are there any concrete security concerns when U2F can use the FIDO2 keystore (at least if no extensions were used when the key was generated)?

I am asking because a common keystore would resolve a big usability issue: At the moment, many browsers support CTAP2 via the HID transport, but I don't know of any example of a mobile browser with CTAP2 support via NFC. Hence, for an authenticator that can do both HID and NFC and lists both CTAP2 and CTAP1 as supported protocols, keys registered via HID (and hence CTAP2) are currently unavailable for authentication via NFC. This is also why SoloKey decided in favor of a common keystore.

[Ackermann Yuriy]

Security requirements

[Fabian Henneke]

I read through the FIDO Security Reference and the FIDO Authenticator Security Requirements (L1), but couldn't find a reference to this requirement. Do you know where this is discussed or at which certification level it starts to become relevant, if not at L1?

Thank you very much for your help in this (and other) matters!

[Fabian Henneke]

I just verified that a "Security Key by Yubico" (Firmware version 5.0.2) accepts U2F sign requests for a UV-enabled credential initially created via CTAP2. So it seems that it is not just the Solo that has a keystore shared between U2F and FIDO2.

On Thursday, October 31, 2019 at 2:53:39 PM UTC+1, Fabian Henneke wrote:

I read through the FIDO Security Reference and the FIDO Authenticator Security Requirements (L1), but couldn't find a reference to this requirement. Do you know where this is discussed or at which certification level it starts to become relevant, if not at L1?

Thank you very much for your help in this (and other) matters!

On Thu, Oct 31, 2019, 11:22 Ackermann Yuriy <ackerma...@gmail.com> wrote:

Security requirements

On Thu, 31 Oct 2019 at 2:07 PM, Fabian Henneke <fabian....@gmail.com> wrote:

Do you know what the reasoning for this requirement is? Are there any concrete security concerns when U2F can use the FIDO2 keystore (at least if no extensions were used when the key was generated)?

I am asking because a common keystore would resolve a big usability issue: At the moment, many browsers support CTAP2 via the HID transport, but I don't know of any example of a mobile browser with CTAP2 support via NFC. Hence, for an authenticator that can do both HID and NFC and lists both CTAP2 and CTAP1 as supported protocols, keys registered via HID (and hence CTAP2) are currently unavailable for authentication via NFC. This is also why SoloKey decided in favor of a common keystore.

On Thu, Oct 31, 2019, 10:18 Ackermann Yuriy <ackerma...@gmail.com> wrote:

No. U2F must have its own keystore. The client will send request with keyid to both U2F and FIDO2 authrs on the device.

On Thu, 31 Oct 2019 at 12:45 PM, Fabian Henneke <fabian....@gmail.com> wrote:

I'm sorry, I should have formulated my question more carefully: I am interested in the situation where an authenticator speaks both CTAP1 and CTAP2, but a credential has been created via the CTAP2 protocol. Is it fine for the authenticator to make this credential (i.e., its key material) available also for requests coming in via CTAP1?

On Thu, Oct 31, 2019 at 8:32 AM Ackermann Yuriy <ackerma...@gmail.com> wrote:

CTAP1 U2F responses are being re-encoded in CBOR CTAP2 structures. This is possible because FIDO2 servers can support U2F CTAP attestation. CTAP2 has a lot more features, fields, etc, that needed to its processes, such clientpin, uv, rk etc etc etc. So there is no way to encode CTAP2 back to CTAP1 RAW, but CTAP1 can be encoded in CTAP2 CBOR.

Regards. Yuriy

On Thu, 31 Oct 2019 at 1:31 AM, Fabian Henneke <fabian....@gmail.com> wrote:

Is there any reason why a credential generated using CTAP2 should not be made available for authentication requests via CTAP1 (assuming that the registration ceremony did not use any extensions which impose restrictions on credential usage)? 

I am asking this question since the CTAP2 and WebAuthn specification seem to only discuss the opposite situation (credentials initially created via CTAP1 being used for authentications via CTAP2). This question has been the topic of a SoloKey issue, where a decision was made to add support for accessing CTAP2 credentials via CTAP1. I personally don't see any issue with that, but would like to get official feedback on this.

--
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+unsubscribe@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/76bb7102-20c7-4d3f-a5b1-fc83e5904877%40fidoalliance.org.

--

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

--

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

[Emil Lundberg]

Yes. As you've discovered, there's no technical reason this can't work in the authenticator layer. In the client layer, however, things are different because of the format difference between U2F AppID and WebAuthn RP ID. The WebAuthn API has an extension for backwards compatibility with U2F AppID, but U2F does not have a similar capability for forward compatibility with WebAuthn RP ID.

Emil Lundberg

Software Developer | Yubico

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/55b516b3-7e4f-4e3d-b192-35ef1dd512ee%40fidoalliance.org.