Re: Comments to WD-01

On 9/15/16, 2:27 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com> wrote:
>
>Regarding the attack by adding an extra ScopedCredentialInfo: where would
>this be added?
>- If the bad guy is in the browser, he could just replace the
>ScopedCredentialInfo instead of adding a new one.

yep.

>- If the bad guy is on the network, he has to intercept and modify https
>traffic.
>- If the bad guy is on the authenticator or on the server, it's all moot
>anyways.

agreed.

So yeah, if there's man-in-the-browser, all bets are off, so guarding
against that is not part of our threat model.


>-----Original Message-----
>From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
>Sent: Thursday, September 15, 2016 11:38 AM
>To: Vijay Bharadwaj <vijaybh@microsoft.com>; Yaron Sheffer
><yaron_sheffer@intuit.com>; public-webauthn@w3.org
>Subject: Re: Comments to WD-01
>
>
>> On 9/14/16, 1:06 PM,
>> "Vijay Bharadwaj" <vijaybh@microsoft.com> replied:
>>> Yaron had written:
>> 
>> [...]
>
>Yes, thanks Yaron for your detailed review.
>
>I agree with Vijay's replies, the below are only the items where I have
>something to additionally note...
>
>>> * 4.1.1 step #4: do we define any mandatory-to-implement algorithms
>>> or credential types? It's hard to get interoperability if we don't.
>> 
>> I believe the goal was to wait for initial implementations, and then
>> assess the state of algorithm support. Only one credential type is
>> supported for now, so that one is okay.
>
>Note that we could denote Credential.type as referring to the union of
>signature format, crypto (eg hash) algs, etc. And then we have agility by
>defining new Credential.types that represent different combinations of
>those things. 
>
>
>>> * 4.6: both authenticatorData and clientData are sent to the RP as
>>> serialized JSON. This creates a potential security vulnerability,
>>> because parsing of JSON dictionaries that contain duplicate
>>> occurrences of the same key is undefined (RFC 7159, Sec. 4), so one
>>> parser can pick the first value for a key and a different parser, the
>>> last value. As a result with a maliciously crafted string, the
>>> authenticator could authenticate one identity, while the RP would
>>> think another identity was authenticated.
>> 
>> I would like to understand your attack better. It seems like the only
>> way to end up with this problem is to send two signatures, one from
>> each authenticator. But in that case both identities are in fact
>> authenticated, so allowing any one of them to be authenticated is not
>> bad.
>
>I made a quick attempt to work through how such an attack might work (in
>the case of a man-in-the-middle (eg MITM in-browser)), and do not see how
>it could occur for a getAssertion() call (aka authn) if the
>ScopedCredential's public key was properly registered with the RP (tho i
>could be wrong...).
>
>Though, for makeCredential() (aka registration) I wonder whether the
>concern might be that such an attacker could, e.g., add their own,
>second, ScopedCredentialInfo object to the overall returned object, and
>due to JSON parser difference on the server-side, the server might pick
>and use the attacker-controlled ScopedCredentialInfo object rather than
>the legit one (I poked thru WebIDL ecmascript binding and AFAICT the JSON
>serialization of the result of makeCredential() would be an JSON object)..
>
>{ "scopedCredentialInfo": {...},  // legit
>  "scopedCredentialInfo": {...}   // MITM attacker-supplied
>}
>
>Such an attack seems like it may be nominally possible because, not only
>due to JSON-parser issues, webauthn presently does not integrity-protect
>the entire object returned by makeCredential() (nor getAssertion()), tho
>maybe I'm missing something.
>    
>
>>> * 5.1.1: when we require user consent, we should specify what
>>> information must be available (displayed) to the user. E.g. the
>>> reDisplayName and the displayName values. Maybe also the RP ID.
>> 
>> An authenticator may not even have a display. Alternatively, an
>> authenticator could be configured so it only accepts requests for a
>> specific RP ID.These seem to be implementation issues for an
>> authenticator to sort out.
>
>Though, this may be implementation guidance/advice we could nominally
>supply.
>
>see, e.g., https://tools.ietf.org/html/rfc6797#section-11 and
>https://tools.ietf.org/html/rfc6797#section-12 for example server and
>user agent impl guidance that might be provided in a https-based protocol
>spec (tho the latter spec is not otherwise topically related to the
>webauthn spec).
>
>
>>> * 8.5: The Location Extension seems to conflict with privacy
>>> constraints in mobile operating systems, where a user can allow
>>> location information to each application. How do we allow the user to
>>> give consent to each RPID separately to access location data?
>>
>> Managing this is left up to the clients. Clients can strip this
>> extension from sites that do not have permissions to location data.
>
>This sort of item is perhaps a candidate for Impl considerations.
>
>
>> * 8.6: please provide a reference to the "FIDO Registry of Predefined
>> Values".
>>
>> JeffH was working on this IIRC.
>
>Actually, I've been working on different, webauthn-created, registries.
>
>What Yaron is referring to are three citations in the new UVM extension
>of the FIDO Registry spec. I had not yet noticed them.  I submitted issue
>#200 and am happy to address it.
>
>
>hth,
>
>=JeffH
>
>
>
>
>
>

Received on Thursday, 15 September 2016 21:32:33 UTC