Re: [FIDO-DEV] Digest for fido-dev@fidoalliance.org - 14 updates in 2 topics

64 views

Skip to first unread message

鬼澤紗代子

unread,

Dec 1, 2020, 8:11:37 AM12/1/20

to fido...@fidoalliance.org

不正アクセスなのですか？

2020年12月1日(火) 午前7:58 <fido...@fidoalliance.org>:

fido...@fidoalliance.org Google Groups

Topic digest
View all topics

Question on authenticatorGetInfo and UV - 12 Updates

Fido2 not working in chromium source - 2 Updates

Question on authenticatorGetInfo and UV

nuno sung <nuno...@egistec.com>: Nov 30 04:48AM -0800

Hi

The uv option id in getInfo response means the authenticator has any *Built-in
User Verification method - **The authenticator supports a built-in
on-device user verification method like fingerprint or has a input UI with
secure communication to the authenticator.*

The uv option key in makeCred and getAssert commands means the
platform/client/browser send this command to authenticator with requesting *Some
form of User Verification. *The authenticator must do this before returning
any positive responses. *Some form of User Verification *can be either
*clientPIN* or above *Built-in User Verification method .*
*ClinetPIN *here means the one of using authenticatorClientPIN (0x06)
relative sub-commands , I don't know what external PIN you mean exactly.

el...@transmitsecurity.com 在 2020年11月30日星期一上午1:13:27 [UTC+8] 的信中寫道：

Eldan Ben Haim <el...@transmitsecurity.com>: Nov 30 03:04PM +0200

So to confirm, if an authenticator didn't return the UV flag in getInfo,
but does support PIN, it's OK to pass the uv option in makeCred or
getAssert to require client PIN?

Ackermann Yuriy <ackerma...@gmail.com>: Nov 30 03:11PM +0200

There are two versions of UV in specs: Internal Capability and indication.

UV Internal Capability means that authenticator supports some form of the
*internal* user verification method, hence UV in the GetInfo.options. If
you set UV option in the makeCredential/getAssertion you will indicate to
the authenticator that you want it to perform some form of the *internal*
user verification.

Now there are other types of user verification, such as external ClientPin1
protocol. Those methods are managed via their own interface, such as
PinAuth interface, and are indicated in the GetInfo their own way, such as
getInfo.pinProtocols.

The Indication UV is just a flag in the authenticatorData.flags that
*Indicates* if ANY UV was performed, Internal or External.

Regards. Yuriy

Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand <https://github.com/herrjemand>
twitter: @herrjemand <https://twitter.com/herrjemand>
medium: @herrjemand <https://medium.com/@herrjemand>

On Mon, 30 Nov 2020 at 15:04, Eldan Ben Haim <el...@transmitsecurity.com>
wrote:

Eldan Ben Haim <el...@transmitsecurity.com>: Nov 30 03:14PM +0200

Thank you, this is what I understand from the spec. So based on what you're
saying, the answer to my very specific question is -- if an authenticator
doesn't return UV in getInfo, but does return indication of support for
clientPIN, it is perfectly fine to require UV on e.g getAssertion. That's
how I understand this based on the answers here, however it seems we've run
into different behavior with Yubikey firmware 5.2.7; I'm trying to
understand if the issue is with the firmware or our understanding.

On Mon, Nov 30, 2020 at 3:12 PM Ackermann Yuriy <ackerma...@gmail.com>
wrote:

John Bradley <ve7...@ve7jtb.com>: Nov 30 10:16AM -0300

NO!!!

In CTAP2.0 if the authenticator dosen't support uv in the getInfo
options member and the uv options key is present (True or False) in a
getAssertion/makeCredential the Authnenticator MUST return a
CTAP2_ERR_UNSUPPORTED_OPTION error.

From the spec

"If the options parameter is present, process all the options. If the
option is known but not supported, terminate this procedure and return
CTAP2_ERR_UNSUPPORTED_OPTION"

Not all authenticators correctly impliment the error. Safari had this
bug for a while and only worked bio authenticators for a while if the RP
sent UV required in WebAuthn.

Please don't repeat that bug.

Regards

John B.

On 11/30/2020 10:04 AM, Eldan Ben Haim wrote:

Ackermann Yuriy <ackerma...@gmail.com>: Nov 30 03:18PM +0200

No no.

If GetInfo.option.uv is False, then authenticator does not support Internal
UV, so you can't call UV flag in the GetAssertion/MakeCredential. However
you can achieve UV by calling it with PinAuth. So Yubikey behaviour is
correct.
Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand <https://github.com/herrjemand>
twitter: @herrjemand <https://twitter.com/herrjemand>
medium: @herrjemand <https://medium.com/@herrjemand>

On Mon, 30 Nov 2020 at 15:14, Eldan Ben Haim <el...@transmitsecurity.com>
wrote:

Ackermann Yuriy <ackerma...@gmail.com>: Nov 30 03:18PM +0200

Yeah, what John said *)

Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand <https://github.com/herrjemand>
twitter: @herrjemand <https://twitter.com/herrjemand>
medium: @herrjemand <https://medium.com/@herrjemand>

Eldan Ben Haim <el...@transmitsecurity.com>: Nov 30 03:21PM +0200

At least based on the answers in this thread, I think it would be prudent
to clarify the spec on this.

Eg “if the option is is known but not supported (as reported by getInfo),
....”

Also it creates a bit of asymmetry between the fact that you’re not allowed
to request UV but will get UV in the response... (assuming that’s the case)

AND I would clarify in the example for the UV field in the request
description (which explicitly talks about PIN) that the reference to PIN is
made to an authenticator built in PIN capability (Eg input device).

Makes sense?

John Bradley <ve7...@ve7jtb.com>: Nov 30 10:23AM -0300

The Yubikey is spec compliant.

It is required to return a error by the spec.

Platforms MUST not send the uv option key if uv is not present and true
in get Info.

In CTAP2.0 if clientPin is present and true in getInfo Options then the
platform should use getPINToken to get a token and use that for
makeCredenital/GetAssertion.

If both uv and clientPin are true in getInfo, the platform first tries
with the uv option key, then if it receves a pin_required error it falls
back to getPinToken because internal UV has failed.

I admit it is underspecified in CTAP2.0, but we hope to improve it in
CTAP2.1 coming soon in RD02.

Regards

John B.

On 11/30/2020 10:14 AM, Eldan Ben Haim wrote:

John Bradley <ve7...@ve7jtb.com>: Nov 30 10:26AM -0300

All coming in CTAP2.1 RD02. If you are a Fido member look at the
working draft. The Review draft should be ready in the next week but
needs appoval for publication.

On 11/30/2020 10:21 AM, Eldan Ben Haim wrote:

Ackermann Yuriy <ackerma...@gmail.com>: Nov 30 03:40PM +0200

The specs are actually clear on that
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential

Here is a diagram as well:

[image: UserVerificationFlowForTheCTAP2Clients.png]
Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand <https://github.com/herrjemand>
twitter: @herrjemand <https://twitter.com/herrjemand>
medium: @herrjemand <https://medium.com/@herrjemand>

Eldan Ben Haim <el...@transmitsecurity.com>: Nov 30 06:23PM +0200

Yes. the diagram describes this clearly. Perhaps you can consider adding it
to the spec and removing some specific parts I highlighted that could be
(and were, obviously by more than one party) easily interpreted otherwise.

On Mon, Nov 30, 2020 at 3:40 PM Ackermann Yuriy <ackerma...@gmail.com>
wrote:

Back to top

Fido2 not working in chromium source

Techiezen <techiez...@gmail.com>: Nov 30 03:01AM -0800

Hi, thanks for your reply.
Call to Google play services is happening. But the reply from the server is
an error.
Maybe the application has to be registered somewhere?

Thanks again,
Techiezen

On Friday, November 27, 2020 at 3:13:22 PM UTC+1 Dominik Schürmann wrote:

John Bradley <ve7...@ve7jtb.com>: Nov 30 11:53AM -0300

The WebAuthn API can be used by any app.

There are special permissions required for browsers if they are going to
specify arbitrary RPID.

Not unreasonably any malicious application with the ability to specify
arbitrary RPID could act as a manin the middle and cause verry bad
things to happen.

If you don't care about access to the platform authenticator you could
use a third party lib to talk to a external key.

The Android WebAuthn API dosen't currently support CTAP2 so if you need
PIN support a third party SDK is your only option.

If you want to be put on the permissions list for the WebAuthn API
unrestricted access like FireFox (was Mozilla broke it) , brave and
Edge you need to contact the Chrome team who manage the list.

Regards

John B.

On 11/30/2020 8:01 AM, Techiezen wrote:

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to fido-dev+u...@fidoalliance.org.