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 18:38:13 UTC