AppID empty scenario

[Dalys Sebastian]

Hi,

I have a question on the AppID and FacetID specification.

If the AppID is null or empty, or if AppID=FacetID, the specification asks to continue with normal processing. Why is this so? Malicious apps could attempt to bypass the security mechanism built into the https-URL trustedFacetId verification, by provding an empty appID?

From the specs:

1. If the AppID is not an HTTPS URL, and matches the FacetID of the caller, no additional processing is necessary and the operation may proceed.
2. If the AppID is null or empty, the client must set the AppID to be the FacetID of the caller, and the operation may proceed without additional processing.

How is the security guaranteed in the cases above? Just wanted to get your thoughts here. 

Thanks,
Dalys

[Dirk Balfanz]

+Juan Lang +Alexei Czeskis 

Hi there, 

I'll start out by mentioning that the AppID/FacetID mechanism is not a security mechanism, but a privacy mechanism. The security of the protocol is achieved by including the FacetID (origin) of the caller in the client data, thus ensuring that one (malicious) origin cannot impersonate another.

Rather, the AppID/FacetID mechanism is a *privacy* mechanism, guaranteeing that one (malicious) origin cannot learn the public key that the user agent (or FIDO Authenticator) uses with another origin. The AppID is essentially a way to "name" the key that the FIDO Authenticator should use. So, what would a successful attack on this mechanism look like? Malicious origin malicious.com would have to trick the FIDO Authenticator into using a key that it normally uses with example.com. The only way malicous.com can do that is by using an AppID that (1) is also used by example.com and (2) includes malicious.com as one of the facets. Using an empty AppID doesn't do that, because in that case the AppID will be considered to be malicious.com (without any further processing), which is not used by example.com. The same is true for the URL https://malicious.com.

Does that make sense?

Juan, Alexei: the text in the spec seems not quite right. Instead of saying: "If the AppID is not an HTTPS URL, and matches the FacetID of the caller, no additional processing is necessary and the operation may proceed," shouldn't it say: "If the AppID matches the FacetID of the caller, no additional processing is necessary and the operation may proceed" ?

Dirk.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/60d3af09-3353-4483-9e77-ca1a0b6eb056%40fidoalliance.org.

[Dalys Sebastian]

Hi Dirk,

Thank you for the great explanation. It really makes sense now.

Thanks,
Dalys

---

From: 'Dirk Balfanz' via FIDO Dev (fido-dev) <fido...@fidoalliance.org>
To: Dalys Sebastian <sebasti...@yahoo.com>; FIDO Dev (fido-dev) <fido...@fidoalliance.org>; "juan...@google.com" <juan...@google.com>; "acze...@google.com" <acze...@google.com>
Sent: Tuesday, August 23, 2016 12:58 AM
Subject: Re: [FIDO-DEV] AppID empty scenario

+Juan Lang +Alexei Czeskis 

Hi there, 

I'll start out by mentioning that the AppID/FacetID mechanism is not a security mechanism, but a privacy mechanism. The security of the protocol is achieved by including the FacetID (origin) of the caller in the client data, thus ensuring that one (malicious) origin cannot impersonate another.

Rather, the AppID/FacetID mechanism is a *privacy* mechanism, guaranteeing that one (malicious) origin cannot learn the public key that the user agent (or FIDO Authenticator) uses with another origin. The AppID is essentially a way to "name" the key that the FIDO Authenticator should use. So, what would a successful attack on this mechanism look like? Malicious origin malicious.com would have to trick the FIDO Authenticator into using a key that it normally uses with example.com. The only way malicous.com can do that is by using an AppID that (1) is also used by example.com and (2) includes malicious.com as one of the facets. Using an empty AppID doesn't do that, because in that case the AppID will be considered to be malicious.com (without any further processing), which is not used by example.com. The same is true for the URL https://malicious.com/.

Does that make sense?

Juan, Alexei: the text in the spec seems not quite right. Instead of saying: "If the AppID is not an HTTPS URL, and matches the FacetID of the caller, no additional processing is necessary and the operation may proceed," shouldn't it say: "If the AppID matches the FacetID of the caller, no additional processing is necessary and the operation may proceed" ?

Dirk.

On Mon, Aug 22, 2016 at 9:12 AM 'Dalys Sebastian' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:

Hi,

I have a question on the AppID and FacetID specification.

If the AppID is null or empty, or if AppID=FacetID, the specification asks to continue with normal processing. Why is this so? Malicious apps could attempt to bypass the security mechanism built into the https-URL trustedFacetId verification, by provding an empty appID?

From the specs:

1. If the AppID is not an HTTPS URL, and matches the FacetID of the caller, no additional processing is necessary and the operation may proceed.
2. If the AppID is null or empty, the client must set the AppID to be the FacetID of the caller, and the operation may proceed without additional processing.

How is the security guaranteed in the cases above? Just wanted to get your thoughts here. 

Thanks,
Dalys

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/60d3af09-3353-4483-9e77-ca1a0b6eb056%40fidoalliance.org?utm_medium=email&utm_source=footer.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit

https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CADHfa2DOoF4nVoPkZ1wxO%2BCofsc8Bq%2Beh0NxGgWtCrwGmBi6ug%40mail.gmail.com?utm_medium=email&utm_source=footer

.

[Suresh Ramalingam]

Hello, 

Just a quick question here, I am trying to send https url in appId field, but fido client is not accepting https url.

Any suggestions please.

Regards

Lokesh

[Ki-Eun Shin]

Hi 

You need to check followings first.

4.1.6 TLS Protected Communication

NOTE

In order to protect the data communication between FIDO UAF Client and FIDO Server a protected TLS channel must be used by FIDO UAF Client (or User Agent) and the Relying Party for all protocol elements.

1. The server endpoint of the TLS connection must be at the Relying Party
2. The client endpoint of the TLS connection must be either the FIDO UAF Client or the User Agent / App
3. TLS Client and Server should use TLS v1.2 or newer and should only use TLS v1.1 if TLS v1.2 or higher are not available. The "anon" and "null" TLS crypto suites are not allowed and must be rejected; insecure crypto-algorithms in TLS (e.g. MD5, RC4, SHA1) should be avoided [[SP 800-131A]].

We recommend, that the

1. TLS Client verifies and validates the server certificate chain according to [RFC5280], section 6 "Certificate Path Validation". The certificate revocation status should be checked (e.g. using OCSP [RFC2560] or CRL based validation [RFC5280]) and the TLS server identity should be checked as well [RFC6125].
2. TLS Client's trusted certificate root store is properly maintained and at least requires the CAs included in the root store to annually pass Web Trust or ETSI (ETSI TS 101 456, or ETSI TS 102 042) audits for SSL CAs.

Thanks.