OpenSSH PKCS#11merge

Peter Stuge stuge-openssh-unix-dev at
Tue Jan 8 15:15:46 EST 2008


On Sat, Sep 29, 2007 at 06:38:57PM +0200, Alon Bar-Lev wrote:
> > You mentioned extending the agent protocol. Can you expand on
> > that a little? Is it really neccessary?

So my point here is that the agent is the only process that can be
trusted to communicated with the user. ssh-add and others that are
talking to the agent may be running somewhere else and may be
compromised. The agent should always have final say.

Compare with how ssh-add -c is implemented. Look for the confirm flag
in ssh-agent.c.

> > Can't the agent figure out when it needs help from the user just
> > from how it is being used without actually being instructed by
> > anyone?

By this I mean that the agent is already able to determine when user
input is required. And there is also an existing mechanism in place
in ssh-agent for acquiring user input.

> This is the major change all smartcard components requires, there
> are some opened issues in bugzilla regarding this.

Which ones do you mean? Please point them out.

> Smartcards are dynamic in nature unlike file based keys, smartcards
> can be removed and inserted by the users, also the session between
> the application and the smartcard is sometime time limited.

ssh-agent already handles limitied lifetime for file based keys. I
think that code can be reused.

> There are two kinds of user prompts that an smartcard enabled
> application needs to have:
> 1. Token prompt - When key should be used but the hardware device
> is not available the application should prompt the user to insert
> his token.

Certainly. I think this should be a prompt just like the one for keys
added with the confirmation constraint.

> This is very important when re-negotiation is performed, as users
> don't expect session disconnect because their token is not
> available.

Hm, which re-negotiation do you mean? AFAIK the user's key is never
used once authenticated between SSH client and server is completed.
Rekeying etc only deals with session keys, right?

> 2. Passphrase prompt - Private key is used first time on session,
> may be triggered when:
> a. A new session is created.
> b. Card was removed and inserted, this actually forces application
> to create a new session.
> c. Provider forces session duration timeout, this also forces
> application to create a new session.

Yup. I think simply calling read_passphrase() in ssh-agent.c is the
best way to do this.

> Because I did not wanted to touch more than I needed, I currently
> implemented these callbacks using external program the ssh-agent
> execute when needed.

No need for the prompt_prog stuff, see the mechanism in readpass.c.

> But a much cleaner solution would be modifying the ssh-agent
> protocol so that it inform the forground application to perform the
> prompt.

Thing is, we do not want the agent to proxy information from the
network to tokens. The agent should read this information directly
from the user.

> BTW: I don't understood why ssh does not execute ssh-agent
> internally if one is not available... GnuPG does this and it seems
> to minimize code duplication...

Probably because the agent causes a considerable change in behavior
when agent forwarding is enabled.

Forcing an agent whenever someone uses a key to authenticate would be
a regression IMO. I like the fact that the agent is optional and
distinct from agent forwarding.


More information about the openssh-unix-dev mailing list