[Bug 2319] [PATCH REVIEW] U2F authentication

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Matt Johnston <matt at ucc.asn.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matt at ucc.asn.au

--- Comment #10 from Matt Johnston <matt at ucc.asn.au> ---
(I'm looking at
https://datatracker.ietf.org/doc/draft-josefsson-secsh-u2f/?include_text=1
)

I think it would be worth using the 32 byte "challenge" to bind the
authentication to the current SSH session. Otherwise an attacker
running a SSH server can get their clients to sign a response for
another server if they know an entry from authorized_keys (because of
origin/appid of ssh://localhost)?

Maybe something like

challenge = chal_sess_hash | 16_random_bytes

where chal_sess_hash is a 16 byte truncated sha256 hash of
      string    session identifier
      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "u2f"

The client MUST check that the first 16 bytes is correct - that's
slightly more complexity (decoding JSON) though the code's already
there for the server. 

That would also improve resistance to MITM even if the server hostkey
is compromised/ignored. Existing SSH public key authentication does
that by including the sessionid in the hash being signed (rfc4253 page
9).

For integration with SSH I think a constant origin/appid string is
probably useful - people expect to be able to connect to a host at
varying IPs/hostnames. Copy/pasting from one host's authorized_keys to
another is also common practise.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.