Mailing List Archive

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





--- Comment #42 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-18 15:22:25 ---
Hello,

People are using smartcards without an agent. This is why I added
support for agent-less PKCS#11 as parameter -#.

Working in tty mode will not allow the askpass to work, although I have
an ncurses askpass implementation that is working, people want to use
OpenSSH without UI.

I wanted to replace current smartcard implementation with standard one,
without changing the way people use it. Andreas Jellinghaus was one of
the people who insisted that nobody will use this unless agent-less
configuration is supported.

Making OpenSSH support several agents is great! People will love it,
especially these who use OpenPGP smartcards and use the gnupg's
scdaemon.

But for this to be valid OpenSSH should provide a development
environment for agents, so that it will be easy to implement and
maintain an agent. For example, an agent library and headers with more
or less static interface should be installed with OpenSSH.

I already maintain gnupg's scdaemon replacement for PKCS#11 [1] as
Werner do not agree to merge PKCS#11 into mainline. And as there is no
agent library available I need to chase gnupg implementation and copy
relevant parts each time.

But there something to learn from gnupg... it always uses the agent, if
there is none it executes one for the current session. This allows
having simpler utilities and also the agent functionality without
modifying the utilities. Maybe you need to do the same for OpenSSH, so
that the whole private key logic will exist in one place. This and
multiple agent support will allow to extend OpenSSH better.

But while thinking of extending OpenSSH, a better test case for proper
agent support would be to allow, for example, X.509 patch to exist as a
separate agent. And maybe extend the agent interface to allow adding
new authentication algorithms. Then I am sure I will be able to provide
and external PKCS#11 agent implementation, as other people may provide
external GSSAPI agent implementation or any other.

Thanks,

[1] http://gnupg-pkcs11.sourceforge.net/

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #43 from Damien Miller <djm@mindrot.org> 2008-06-18 15:34:50 ---
Ok, supporting multiple agents is easy and I will try to get this done
by the next release.

Providing a support library for external agents is a little more
tricky, but I think this can be accomplished relatively soon. The first
steps are:

1. Documenting the agent protocol
2. Implementing a library for working with the ssh wire protocol and
cryptographic primitives
3. Writing a skeleton agent that implements most of the agent protocol

I had already planned to do #1 as part of my effort to document all
that is undocumented in OpenSSH's implementation of the SSH protocols.
I have most of #2 done already (as part of a wider project), but it
still needs some work (in particular it doesn't support SSH1). #3 is
as-yet unstarted, but the agent is a simple program so it wouldn't take
too long once #2 is finished.

I disagree that agent-only configurations are useless. The agent can
communicate via X11 or other means; I think perhaps people are looking
at the limited nature of the existing SSH_ASKPASS and thinking that it
is all that is possible. Your ncurses UI is a great idea too.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #44 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-18 15:56:06 ---
So please at least consider the following improvement to the agent
protocol: Acquire information from the user.

When the agent needs passphrase or acknowledgment it will have the
ability to forward it to the caller program. Two types of prompts need
to be supported, string and password.

This way, when an agent needs passphrase or in PKCS#11 case prompt for
user to insert his token, the caller program may be used in order to
prompt the user for this information.

Also, please also consider adding configuration file support to the
agent as well, in the same manner other OpenSSH tools use configuration
files.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #45 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-18 18:41:39 ---
An alternative to providing user interaction in agent protocol is to
forward $(tty) to the agent, so ncurses application can do its
interaction from the origin tool terminal.

What I fear is a user working in multi terminal environment, having
agent running in one terminal and ssh in another terminal, the ssh is
waiting for the agent, while the agent is waiting for user input at
other invisible terminal. The user is not notified, and from his
perspective it looks like that ssh is not responding.

The current agent-less mode makes it much more simple to solve this
without a change in the agent protocol.

Also please expose the agent the buffer interface, and the uuencode.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #46 from Damien Miller <djm@mindrot.org> 2008-06-29 00:14:55 ---
As a first step, I have documented the protocol used between ssh and
ssh-agent in the file PROTOCOL.agent. It will be available from:

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD

once the mirror catches up and will be in the openssh-5.1 distribution.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #47 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-29 03:32:51 ---
I am not sure I understand what you are doing. But I do understand that
I and users are going to miss another merge window.

You left the current *SMARTCARD calls to the agent, while if you truly
wish to provide a way for people to add new agents you need to abstract
the agent, and leave only relevant required messages.

Also there is the issue of providing the agent with some variables,
such as active tty. I thought you are going to address this.

Imaging you going to split up the ssh-agent (and ssh-add) into separate
package. And review the protocol using this assumption. Calls made by
ssh-add may be agent specific and should not be documented here.

However, if you are going to keep current smartcard parameters in ssh
command-line, the smartcard commands should be documented, but I will
never be able to provide users with the same level of solution in agent
only implementation.

For example... Adding a new command of "set property" and add ssh
configuration option "AgentProperty". Then users will be able to enter
something like:

ssh -o AgentProperty=smartcard-key:reader_id,pin,key_constraints host

[or adding this to ssh_config]

This will allow external implementation to work without modifying the
protocol, for example:

ssh -o AgentProperty=pkcs11-add-provider:provider host

And also solve the tty issue simply as tty= attribute may automatically
be set by all utilities.

I think that merging PKCS#11 patches provides the best solution until
the agent implementation may truly be separated.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #48 from Damien Miller <djm@mindrot.org> 2008-06-29 10:08:07 ---
If you are going to implement a standalone agent, then you need to
understand the protocol that it will need to speak. My last message
just announced that documentation for the protocol is ready. The was
the first action that I described in comment #43. The goal is to enable
people like yourself to write agents (other may like to, e.g. write GUI
agents), not to separate ssh-agent from OpenSSH.

BTW I'm not sure that I agree that you need any more message types than
already exist to implement a pkcs11-agent.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #49 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-29 15:06:00 ---
Hello,

I expected that part of the work of multiple agents and formalizing the
protocol is reviewing the protocol in order to make it suitable for
external implementations, not just documenting what you have, as this
was not written in order to be external protocol. Take for example the
tty issue, until agent only solution may be used in console only mode
properly, there will be a need to patch the tools anyway.

For agent to work properly with ssh, only the following command may be
used (ssh2):
SSH2_AGENTC_REQUEST_IDENTITIES (add tty field)
SSH2_AGENTC_SIGN_REQUEST (add tty field)
SSH2_AGENTC_REMOVE_IDENTITY
SSH2_AGENTC_REMOVE_ALL_IDENTITIES
SSH_AGENTC_GET_PROPERTY (new)
SSH_AGENTC_SET_PROPERTY (new)

All the other (add, delete) are implementation specific. All
implementation specific can go into the get/set property messages. If
you do this, then people may write external agents as there will be no
dependencies between the client implementation and new agent features.

Please review the implementation at attachment#1495 and see the
messages I use:
SSH_AGENTC_PKCS11_ADD_PROVIDER
SSH_AGENTC_PKCS11_ADD_ID
SSH_AGENTC_PKCS11_REMOVE_ID

The remove id may be shared, but the format of the other two is
different than current messages, please tell me where I am wrong.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #50 from Damien Miller <djm@mindrot.org> 2008-06-29 18:25:21 ---
I don't think the protocol should be modified to accept a tty channel.
The SSH agent protocol allows for forwarded operation though hosts that
may not be completely trustworthy. Passing a pin though for frequent
operations like listing identities or private key operations increases
the likelihood that is will be exposed.

Better IMO to cache the pin in the agent at the time the key is added -
this is what the existing smartcard support does. Caching the pin in
the agent is no additional security risk - if the agent host were
compromised then an attacker could just as easily steal the pin when it
was used.

As for other protocol extensions - please keep it simple for now. Part
of the difficulty with merging the existing pkcs#11 patch is that it
touches much more than it strictly needs to. Better to start simple and
add features based on clear need.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #51 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-30 03:52:57 ---

Hello,

(In reply to comment #50)
> I don't think the protocol should be modified to accept a tty channel.
> The SSH agent protocol allows for forwarded operation though hosts that
> may not be completely trustworthy. Passing a pin though for frequent
> operations like listing identities or private key operations increases
> the likelihood that is will be exposed.

How do you propose solving the issue of console only mode without
touching the client? Currently the agentless mode is the only solution
for this one.

> Better IMO to cache the pin in the agent at the time the key is added -
> this is what the existing smartcard support does. Caching the pin in
> the agent is no additional security risk - if the agent host were
> compromised then an attacker could just as easily steal the pin when it
> was used.

Wrong.
Caching smartcard PIN is none standard, unexpected and unsecure. It is
part of the problem in current implementation. People implement
external patches to fix this behavior [1], [2].

Smartcard usage best practice forces re-authentication after smartcard
is powered off (removed and inserted), or when smartcard session
duration expires.

Also, implementation should allow re-authentication for each
application instance/type.

> As for other protocol extensions - please keep it simple for now. Part
> of the difficulty with merging the existing pkcs#11 patch is that it
> touches much more than it strictly needs to. Better to start simple and
> add features based on clear need.

I add all feature based on clear need. Hardware cryptography best
practices are different than software ones.

The PKCS#11 patch touches exactly the same locations of current
smartcard implementation, this in order to provide full replacement and
allow its removal in future. While adding support for expected behavior
of re-authentication and prompt the user to insert token if needed.

I will be more than happy to reduce the size of the patch! But I won't
compromise on security, as the target of hardware cryptography is to
improve security level of OpenSSH not provide "nice" feature to the
list.

[1]
http://www.opensc-project.org/opensc/browser/trunk/src/openssh/README
[2]
http://www.opensc-project.org/opensc/browser/trunk/src/openssh/ask-for-pin.diff

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #52 from Damien Miller <djm@mindrot.org> 2008-06-30 07:46:28 ---
(In reply to comment #51)
> > Better IMO to cache the pin in the agent at the time the key is added -
> > this is what the existing smartcard support does. Caching the pin in
> > the agent is no additional security risk - if the agent host were
> > compromised then an attacker could just as easily steal the pin when it
> > was used.
>
> Wrong.
> Caching smartcard PIN is none standard, unexpected and unsecure. It is
> part of the problem in current implementation. People implement
> external patches to fix this behavior [1], [2].

Can you offer a rationale for why this is insecure? I think I have
given a good argument for why caching the pin gives no additional
security risk, while passing it though does.

> Smartcard usage best practice forces re-authentication after smartcard
> is powered off (removed and inserted), or when smartcard session
> duration expires.

What defines a "smartcard session"?

As for poweroff/removal, the cleanest way to deal with these is simply
to invalidate all keys that were hosted on the card and force the user
to re-add them.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #53 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-06-30 16:03:05 ---
(In reply to comment #52)
> What defines a "smartcard session"?

The provider/card derived from security constraint for key usage. For
example, there are keys that may only be used once after authentication
or there may be a timeout of 1 minutes for private key operations and
then force re-authentication.

> As for poweroff/removal, the cleanest way to deal with these is simply
> to invalidate all keys that were hosted on the card and force the user
> to re-add them.

This is the source of the difference between hardware cryptography and
software cryptography.

In many cases the smartcard is also used in order to open the door to
one's office. So even when you go to drink some water you have to take
the smartcard with you. And if you have several computers (disconnected
from each other) you need to remove the card from one computer and
insert it into another to switch computers.

Removing and inserting smartcard is frequent, forcing the user to take
action or invalidate sessions because of it makes the complex
environment to be even more difficult to handle.

Just imagine that you need to re-add keys to the agent every time you
return to your computer after being away from it even few steps!

Specifying the PIN when you add the key into the agent will be good as
long as the smartcard is not removed. It is security risk as if one
find other smartcard and plug it in, he should not be able to use its
resources.

The behavior of dynamic "need token", "need passphrase" was
successfully tested and accepted by users who use this patch, use the
OpenVPN, GnuPG scd do ask passphrase correctly but fails if token is
not available (but it does not have sessions), eCryptfs, QCA based
(PSI, Iris and I hope soon KDE).

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #54 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-07-07 14:57:28 ---
Well... I see I missed another merge window. And from what I understand
you are not going to replace the proprietary smartcard support into
standard one.

Maybe I am doing something wrong. I will post a message in the mailing
list requesting some help.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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





--- Comment #55 from Alon Bar-Lev <alon.barlev@gmail.com> 2008-07-07 15:09:53 ---
comment#51: Add reference of bug#608, and also bug#69 for partial vt
operation.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs