RP and FIDO server responsibilities

[Alexandre B.]

Hello, FIDO team.

After extensively reading the FIDO protocols, I'm afraid I still didn't understand the specific reponsibilities of RP and FIDO server.

Is it possible to run each one in a separated environment as an individual server or is this a wrong understanding of the FIDO server architecture?

Many thanks,

Alexandre B.

[John Kemp]

It may be *possible* to run each in a separate environment, but it is not necessarily advisable.

The FIDO protocol itself occurs between the FIDO Client and the FIDO Server. The FIDO RP has no official FIDO role.

However, communication must occur between the RP and the FIDO server, and that communication should be secure. This, to me anyway, says that the FIDO RP should be very closely tied to the FIDO server. The diagrams in https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-overview-v1.0-ps-20141208.html#fido-uaf-high-level-architecture show the FIDO server as part of the relying party. But how the RP and the FIDO server communicate is out of scope for FIDO itself, so other interaction patterns might be possible. Security would be a question in such scenarios.

Cheers,

- johnk

>
> Many thanks,
> Alexandre B.
>
> --
> 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 http://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/6daccdad-a516-4380-bcc4-f957083fd975%40fidoalliance.org.

[Alexandre B.]

Very clear, John.

Thank you very much for your help!

Regards,

Alexandre

[Arshad Noor]

Hi Alexandre,

Your understanding is fine.  You can separate the RP application and the FIDO server into two separate environments if your FIDO server supports such a capability (through some IPC/RPC mechanism).

From a responsibilities point-of-view, the RP application is responsible for business functionality, while the FIDO server is delegated the mechanics of dealing with the FIDO protocols - no different from how a web-application might be responsible for handling an e-commerce transaction but delegating the e-mail to an Message Transfer Agent (MTA) for delivering the mail.

This is precisely how we've implemented our U2F server - as a webservice callable over SOAP/REST from an RP application that may be executing anywhere over the network.

Arshad Noor
StrongAuth, Inc.

[Arshad Noor]

John,

I'm curious: can you elaborate on the risks between the RP application
and the FIDO server that causes you to recommend that its "not
necessarily advisable" to run the RP application and the FIDO server in
separate environments?

Based on my understanding of the protocols, all else being equal (and
reasonably secure), what can someone do in the middle of an RP-FS
communication path that makes local IPC more secure than RPCs?

Arshad Noor
StrongAuth, Inc.

[John Kemp]

> On Jun 18, 2015, at 8:26 PM, Arshad Noor <arsha...@strongauth.com> wrote:
>
> John,
>
> I'm curious: can you elaborate on the risks between the RP application and the FIDO server that causes you to recommend that its "not necessarily advisable" to run the RP application and the FIDO server in separate environments?

If I have a FIDO server running in a web server, and my FIDO RP is treated as a “web client” over the open Internet, it is exposed to many more security issues than if the FIDO server is running on the same machine and being called with an API available only to a piece of software on the exact same machine. Or if the FIDO server is a library compiled directly into the FIDO RP, and the RP communicates via programming language API calls.

Basically, every time you separate two components via either a local network, or the Internet, you have to be careful about providing adequate security between those components, as the "security domains" of the two components might be different. There are security differences between library calls, IPC and RPC.

>
> Based on my understanding of the protocols, all else being equal (and reasonably secure), what can someone do in the middle of an RP-FS communication path that makes local IPC more secure than RPCs?

Which component(s) allows local IPC to occur, and how is it authenticated? Which component(s) allows RPC to occur, and how are requests authenticated? Would it be OK for a “fake” RP to contact the FIDO server? How would that be prevented?

- johnk

>
> Arshad Noor
> StrongAuth, Inc.
>
> On 06/18/2015 04:46 PM, John Kemp wrote:
>>> On Jun 18, 2015, at 7:18 PM, Alexandre B. <alexandr...@gmail.com> wrote:
>>>
>>> Is it possible to run each one in a separated environment as an individual server or is this a wrong understanding of the FIDO server architecture?
>> It may be *possible* to run each in a separate environment, but it is not necessarily advisable.
>>
>

> --
> 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 http://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/558361AE.8010806%40strongauth.com.

[Alexandre B.]

Thank you very much, Arshad!

You've added important points that will be important for me.

Best,

Alexandre B.

[Arshad Noor]

On 06/19/2015 03:33 AM, John Kemp wrote:

On Jun 18, 2015, at 8:26 PM, Arshad Noor <arsha...@strongauth.com> wrote:

John,

I'm curious: can you elaborate on the risks between the RP application and the FIDO server that causes you to recommend that its "not necessarily advisable" to run the RP application and the FIDO server in separate environments?

If I have a FIDO server running in a web server, and my FIDO RP is treated as a “web client” over the open Internet, it is exposed to many more security issues than if the FIDO server is running on the same machine and being called with an API available only to a piece of software on the exact same machine. Or if the FIDO server is a library compiled directly into the FIDO RP, and the RP communicates via programming language API calls. 

Basically, every time you separate two components via either a local network, or the Internet, you have to be careful about providing adequate security between those components, as the "security domains" of the two components might be different. There are security differences between library calls, IPC and RPC. 

I am familiar with the security requirements for disparate machines to communicate with each other, John; this is why I prefaced my query with the statement "all else being equal (and reasonably secure)".  Having transport security and authenticated webservices is not only reasonable, but in this day and age, only a complete idiot would implement something without these security functions.

Given that, IMO there is little risk in separating the RP application and the FIDO server.  In fact, the separation gives you all the benefits we have derived from distributed computing architectures over the last 3 decades: immense scalability, high-availability, functional specialization, fault-isolation, and last, but not least, the ability to churn out RP applications faster, cheaper, better. 

While I realize you may be voicing your personal opinion, IMO, as Editor of FIDO Alliance Specifications, the Alliance should NOT be recommending specific implementation strategies unless they are backed by empirical evidence - it has the effect of biasing people new to FIDO.  If the Alliance wants to put out guidance on implementation strategies, then it should be done as a formal white-paper with pros/cons for each design fully spelled out and with all assumptions defined; otherwise, it should be left up to FIDO implementers to promote their case.

Thanks.

Arshad Noor
StrongAuth, Inc.

[Adam Powers]

Let me see if I can split the difference between John and Arshad and add a little color to the conversation. I can think of three possible architectures:

1. You are a small service provider running a small, single website with built-in authentication (maybe a local business or a small website).

2. You are a large corporation running a high-volume service with lots of requirements around security and scalability, and you manage your own accounts and authentications (think “Google” or “AT&T”).

3. You are a online service service that allows login-through third-party services (like pretty much every service that allows “Login with Facebook” or “Login with OpenID”).

In the first scenario, it would be acceptable and perhaps even preferable to have the RP and authentication software in a single service — it’s easier to deploy and manage a single server with a single service rather than managing multiple moving pieces, especially for non-technical users.

In the second scenario, while technically possible to have both the RP and the FIDO server running on the same machine, it violates best practices. Most enterprise architecture requirements will separate out authentication from web sites / web services so that: 1) if a web server has compromised security, it doesn’t expose the authentication service to undue risk; 2) web servers can be horizontally scaled and authentication services can be horizontally scaled independently of each other; 3) modularity of authentication and services allows reuse of authentication across services; etc.

Finally, in the third scenario, it would be technically impossible to have the authentication service running on the same same server as the website — one company is providing authentication and another is providing the website content.

Note that I am using “authentication service” as a synonym for “FIDO Server” and “website” as a synonym for “Relying Party”.

Bottom line is that both John and Arshad are right: John, in thinking of the second or third scenarios, is right that you would want to (or must) keep them separate. Arshad is right that from the perspective of FIDO specifications, there is no reason to limit or restrict FIDO from supporting any deployment architectures.

I hope that helps.

Adam

 

 

 

 

 

On Jun 19, 2015, 9:36:35 AM, Arshad Noor <arsha...@strongauth.com> wrote:

---

--
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 http://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/55844513.9060007%40strongauth.com.

[John Kemp]

Hi Arshad,

Although I am a FIDO Alliance paid contractor, my views expressed on both this topic, and any other, are my own, and do not represent any Alliance-wide view. They have not been vetted by anyone else, and represent only my experience as an implementer of security systems.

Regards,

- johnk