Slashdot Mirror

← Back to Stories (view on slashdot.org)

SSH Key Management Part 2

Posted by Hemos on from the making-secure dept.

LKH writes "The second part of Daniel Robbins' ssh key management articles is up at developer works. Daniel covers passphrase-less authentication using keychain."

1 of 109 comments (clear)

  1. Agent risks by Dr.+Tom · · Score: 5, Insightful
    Agent systems are interesting, and there is something to be said about the trend from simple server/client systems to server/agent/client systems. Agents can be very helpful in brokering transactions locally that involve sensitive information, or information that needs to be accessed repetitively.

    However, agents can be complex to install and configure, and can potentially decrease security. The agent knows all your secrets, after all. Especially, using non-local agents is highly inadvisable.

    It is also worth pointing out that agents can be used with password based systems as well. Unfortunately, SSH implementations are only using agents for key management. It is possible, and highly desirable when a chain of hosts is involved, for the remote side to contact your local agent to manage a remote passphrase-based authentication, using a protocol such as SRP that doesn't leak. An SRP agent would live on your desktop, present a familiar interface that is unambiguous, and provide secure authentications network wide, even chained. You never enter or store any security information on any host other than your own local client (this also solves all traffic analysis attacks based on password length).

    A well designed agent needs to be a library, with pluggable user interfaces that are adapted for all the different GUI/CLI systems out there. Agent interfaces need to be familiar and distinct. There is a huge risk in communicating with an agent over a CLI, for example, when you can't distinguish the agent's prompts from the server's prompts. Ideally, agents should be started and configured automatically on the client machine by the client software. Sensitive information should time out.

    You also don't want your agent to become a huge database of fluff with things like addresses and phone numbers. Use a database for that, and equip your database with an agent, and your agents with protocols that let them perform client/agent/agent/server transactions (with only LOCAL agents of course).

    MS's Passport, for example, violates all these rules. It's non-local, it's full of tons of information that's irrelevent to most transactions, and the interface is variable and confusing.

    It would be great if projects like OpenSSH develop (or use) full-blown agents and agent protocols that allowed these features. I for one would be interested in hearing about general purpose client/agent/server architectures and protocols that have already been developed for use in Free Software projects, and/or TLS-based protocols that use agents. Any ideas?