[Cryptography] SRP for mutual authentication - as an alternative / addition to certificates?

[Thierry Moreau]

On the relevance of the fidoalliance.org initiative,

On 08/12/15 04:56, Ben Laurie  and Tony Arcieri wrote:
>
>
> On Wed, 12 Aug 2015 at 02:24 Tony Arcieri <bascule at gmail.com
> <mailto:bascule at gmail.com>> wrote:
>
>     On Wed, Aug 5, 2015 at 11:51 AM, Ben Laurie <ben at links.org
>     <mailto:ben at links.org>> wrote:
>
>         I use one of those, but it doesn't really help with my other
>         devices.
>
>
>     U2F is just a protocol. Your "other devices" could also act as U2F
>     tokens themselves (e.g. your SmartWatch could act as a U2F token for
>     your SmartPhone).
>
>
> I don't wear a watch.
>
>     Or (potentially) something like a Yubikey could provide U2F over
>     Bluetooth or NFC.
>
>
> I'm not sure potential logins are much use to me. :-)
>
>
>         And I'm screwed if I lose it (well, I'm not, because I'll be
>         given another, but if I were a member of the public I would be).
>
>
>     Buy two and keep another as a backup, then revoke the first when you
>     lose it.
>
>
> So, if I'm on holiday, I do without access for the remaining 2 weeks?
>
>     But losing credentials is a general problem with any authentication
>     system.
>
>
> True, but that doesn't give you a licence to ignore it.
>

My two points: 1) general feedback of UAF / U2F
2) specific comment on Ben objections

1) general feedback

 From a very superficial look at the technology, the UAF / U2F approach 
has some good points:

- by relying on a public key digital signature for routine 
authentication (login), it rests on a very effective password phishing 
countermeasure (maybe the only effective countermeasure),

- it uses client private signature keys without the concept of client 
security certificate, something I refer to as the "first party 
certification" paradigm,

- it managed to get some momentum as an industry alliance.

It may also have limitations:

- the proof of possession at the registration phase provides no 
protection against impersonation attack at this phase,

- while the client side device (could be a software emulation) is touted 
as requiring a form of biometric or PIN enablement, this requirement is 
hardly enforceable by the protocol.

Both of these limitations appear minor if we envision the technology as 
a replacement for password-only authentication for minimal security 
applications, but may become more serious when the added security 
attracts higher valued services and/or when the added perceived security 
induces a relaxation of vigilance for the limitations.

2) Specific comment on recovery of lost authenticator

The client-side implementation may include private signature key backup 
facilities. Obviously, there is an implicit vulnerability with this 
avenue, but nonetheless that's an ever-present mitigation strategy for 
the ever present operational threat of a private key loss incident.

Maybe Ben should have figured it by himself; likely he did but was 
arguing from an ordinary user perspective.

The UAF / U2F approach seems to defer the difficult user interface for 
managing a private signature key to the implementation at the client 
side. Do we have some anecdotal experience in user interface for 
managing bare private keys (not linked to a security certificate, and 
without cryptoperiod expiration requirements)?

- Thierry Moreau