[Auth] Symmetric vs Asymmetric

[nigelcearnshaw]

These comments relate to the authentication discussion of the open screen protocol. In particular I wanted to comment on the symmetric vs asymmetric discussion from the last F2F meeting.

Symmetric

In the symmetric case of pre-shared passwords (PAKE) you envisage the browser and receiver each generating some common undisclosed encryption key for transferring the data (say, presentation). However, in order that no one can impersonate a known receiver there is a conundrum in that on the one hand the receiver’s password is a controlled secret, and yet on the other, any controller must readily know it.

Given this it seems that the shared secret must be created and introduced at the time of use, for example is created and typed in to the receiver and the controller by the user. Once the PAKE protocol has established and verified the shared (encryption) secrets the authentication process is over, and the passwords can be destroyed. Since J-PAKE claims forward secrecy there is now no further opportunity to intercept the authentication protocol and so the time of attacks limited. Consequently, the number of digits that comprise the password can be relatively small and easily typed.

The idea of a permanent pre-shared secret password appears a contradiction in this context since it needs to be readily extracted to use the authentication protocol and once extracted can be shared in a manner that jeopardises the nature of the Open Screen Protocol. Exhibiting the password on the screen is making a secret passcode public and the process useless. A short term secret maybe sufficiently secret over the critical time.

Asymmetric

Briefly considering asymmetric cryptography rather than symmetric secrets, there could be a public key associated with the receiver which can be shared, though there is still the problem of binding the public key to a known receiver. It could be a fixed label – but labels can be changed. It could be displayed through a UI but it will not lend itself to being easily typed/copied into the controller. A fingerprint can be exposed, though it would have to be independently regenerated for verification within the protocol from the public key value presented over the network, say using a self-signed certificate. In this way the device display acts as its own CA. This does imply the user can independently access the fingerprint (i.e., is in the same room as the target display), so has the same restriction as the symmetric password case. It also requires manufacturers to embed (or provide some way of subsequently updating/embedding) a private key which is often an overhead that is difficult.

Contrast this with the symmetric PAKE protocol in which the passwords are delivered to the receiver and controller (or generated by the receiver and copied to the controller) by a trusted agent (i.e., human user) who has access to both and is effectively an out of band registration agent for the imminent session.

Is this reasoning consistent with your current thinking?

[markafoltz]

We investigated using PSK with TLS 1.3 and decided it wasn't suitable for this application. The current authentication proposal (in Section 8) is a mutual authentication handshake that generates a shared secred for symmetric encryption based on an ephemeral passcode that the human user must convey from one agent to the other. I believe that is similar to your "Symmetric" scenario above.

@pthatcherg is working on the details of the authentication protocol and may be able to offer more detailed thoughts.

[markafoltz]

I believe the current spec addresses the question above of "how does the shared secret work." See in particular:

https://w3c.github.io/openscreenprotocol/#authentication-with-spake2 https://w3c.github.io/openscreenprotocol/#security-ui https://w3c.github.io/openscreenprotocol/#appendix-c

If there are additional questions after reviewing the current draft, feel free to file new issues.