Re: [webauthn] agl doesn't understand extensions

Indeed, for any authenticator-processed extensions, the RP can only trust the authenticator output and so that must contain the input to confirm it. For example, in the way that the [txAuthSimple extension](https://w3c.github.io/webauthn/#sctn-simple-txauth-extension) does.

For client extensions, I agree that does imply that the client is trusted but I can imagine that the RP doesn't trust their origin context. (I.e. the RP is a backend system which issues commands, but the webauthn requests are actually made by Javascript running in the origin, which may have been compromised by an XSS attack. I'm not sure to what extent this is a sensible thing to worry about, but I'll take it as a premise.)

In this case, echoing the extension inputs in the CollectedClientData eliminates the possibility that the origin context has manipulated the request. Except:
1. If a compromised origin context is something that we expect to defend against, there are [a lot of fields](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions) in a creation request that are not echoed and so not protected. Thus it seems that if this threat was intended to be addressed, the solution is incomplete and protecting extensions is insufficient.
1. As emlun notes, the client's outputs can still be manipulated by the origin context. So, for example, a compromised origin context could falsely assert that [biometricPerfBounds](https://w3c.github.io/webauthn/#sctn-authenticator-biometric-criteria-extension) were acted upon.
1. The client doesn't echo the extensions as given, rather the subset that it supports. Thus the origin context can suppress extensions and make it look like the client doesn't support them.
1. The instructions say only that the RP should check that the echoed extensions are a subset, but it's unclear if that means that the values must be identical, esp in light of the fact that the RP is also instructed to check that the [authenticator extensions](https://w3c.github.io/webauthn/#dom-collectedclientdata-authenticatorextensions) are a subset, where it cannot check the values. If values aren't checked, a compromised origin context can still manipulate the contents of an extension.
1. Since the CollectedClientData [is JSON serialised](https://w3c.github.io/webauthn/#collectedclientdata-json-serialized-client-data), that means that all extensions have to be JSON—i.e. no ArrayBuffers, WebCrypto objects etc. (Unless we also define a Javascript to JSON mapping for these types.)

I'm still unsure of a purpose for echoing the authenticator extension inputs.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366296231 using your GitHub account

Received on Friday, 16 February 2018 17:05:38 UTC