Whishlist for next-gen card

[NdK]

Il 01/03/2015 21:54, Peter Lebbing ha scritto:

> No, I'm talking about that as well. And I don't think the fingerprint of
> the host is part of the signed data or the signature. Why do you think the
> fingerprint of the host is part of that?
Because I didn't remember well the SSH protocol...

> By /host/ authentication I mean that you verify that the host your are
> connecting to is in fact the host you wanted to connect to; and /that/ is
> through the public key of the host, of which you can verify the fingerprint.
> Let's call this keypair A.
That gets verified during initial key setup.

> After you've verified the fingerprint, a copy of the hosts' public key, A, is
> stored in ~/.ssh/known_hosts on your client machine.
Ok, just something to help the user avoid a verification step every time.

> But when the host is authenticating that you are in fact the user you are
> claiming to be, you sign a challenge that only you could sign because you have
> the private key, let's call it B. That is /user/ authentication.
Ok.

> The host checks that your public key B is in ~/.ssh/authorized_keys on the
> server machine; if so, you're authenticated.
Ok.
But the signature contains the session identifier (called H in RFC4257
sec 8), that is derived from the initial key exchange (that should then
be partially handled by the card as well). Luckily there's no need to
recalculate it when keys are refreshed (RFC4257, sec 7.2), so it's
one-time penalty.

So the "card" should receive (and handle) the key exchange, prompting
the user to accept the public key the server sent and then allow the
auth key to just sign data where the session id is the one it
calculated. Might be non-banal to handle concurrent ssh sessions with
overlapping key exchanges (card generates a "blob" --might be
symmetrically encrypted with a key only known to the card-- that's
"cached" by ssh and passed back to the card when a new auth signature is
requested for an existing session id?).

BYtE,
 Diego.