RE: Comments to WD-01

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.
- 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.

-----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:28:18 UTC