Can the U2F standard be used by servers to impose a specific category of hardware?

Question

I don't like that browsers, email clients, etc. come bundled with CAs and that there is no emphasis for a more decentralized authentication mechanism. Fortunately, it's not too bad, because at the least, whatever is our favorite platform, we can create our own clients, say an IMAP client, using any programming language we like, say Python, with whatever bundled CAs we like.

It will be too bad that we lose that flexibility and start to depend on new platforms, new USB devices, etc. Sure, it is an open standard, but if it is a part of this open standard, that servers can accept only specific hardware such as special USB devices, then in practice, one programmer will not be able to program a client on the platform of his choice. Sure, any big company would be able to build a device that respects the standard, but still a lot of flexibility would be lost. I am not saying that this is the situation with the new FIDO U2F standard, but I am curious about that.

For me, a good standard must restrict as little as possible both sides. As soon as a "standard" allows one side to impose constraints on the implementation on the other side, even in the name of security, it seems that a fundamental notion of freedom, implicit in the open source original idea, is under attack. This original idea was to allow any programmer to create practical code with as little constraints as possible. It maybe that the situation is as before with CAs for website or email certificates and it is just that the current emphasis in on specific hardware on the client side - that would not be too bad.

My questions:

• How can we build our own clients, using the platform and the language of our choice to connect with any U2F compliant server?
• Is it possible to build, say an IMAP client, on the platform of our choice, to authenticate with any, say IMAP server, that respects the U2F standard?

Answer 1

U2F in and of itself does not provide a protocol for client-server communication. It provides a set of requirements that need to be met in order for the scheme to be considered authenticated. These requirements define a set of messages, but don't define how they get passed from the client to the server and back. As such, the answer to whether you can build a client for any generic server is: no, because there simply isn't a generic protocol. That said, you can certainly build a generic service that can process the messages sent, but you would need to define the mechanism by which the messages are sent.

Given the first answer, the second answer is necessarily no as well. This doesn't mean that you can't strap U2F on top IMAP and have it has an extension, but that naturally means it requires custom code on both sides.

Answer 2

your client side question :

For sure you can build your own FIDO U2F client that can be compatible with many existing FIDO U2F servers implementation. Most of the time for now, FIDO U2F client is : - a desktop Web Browser (Chrome or Firefox) - a mobile browser (Chrome for Android / Authenticator App is also needed fo now but this requirement will disappear) - an Android App (like http://gg.gg/4en0t)

The default transport/protocol is SSL, it makes sens since this FIDO U2F initiative was made to provide easy strong authentication for cloud / web services... so you'll find tons of open source servers implementation, but sadly for now nearly nothing for -outside of a browser- client implementation but it should not be too difficult to implement it. Regarding FIDO U2F servers compatibility, of course the server side should not be setup to discriminate clients (that's why some existing FIDO U2F services are not working with Firefox even if Firefox U2F support is possible through a third party plugin http://gg.gg/4en25).

you server side integration with other services :

You can add FIDO U2F based authentication to existing services like IMAP but it would require to add this feature to both client and server sides. You are not the first one to ask for such a mail client use case... let's hope someone will work on it in the near future.

your last note quoting specifications about "attestation" and "class of device" identification :

on server side, you can retrieve information about the manufacturer of the U2F device through the attestation certificate that come with the identity public key during enrollment. It can be useful to discriminate some client implementation that are known to weak... or simply unknown implementation. For now, on the field, nearly all FIDO U2F servers accept anything, any implementation, nearly noone is using this feature and as far as I know, even the recent meta data service don't give enough information about the "class of device" (too bad, I you ask me). Remember that par is about the FIDO U2F device/authenticator, you should be able to build FIDO U2F client compatible with any FIDO U2F device/authenticator, the optional discrimination will be made on the server side.