openssh PKCS#11 support

[Alon Bar-Lev]

Andreas Jellinghaus wrote:
> Hi Alon,
> 
>>I don't agree...
>>You can use self-signed certificates for small scale... You
>>get the same complexity of RSA keys.
> 
> 
> no, for example x.509 patch will still check validity times and
> refuse expired certificates. that is additional complexity.
> 
> think of the horror if your only way to login as root on some
> machine is certificate based, it expires, and now you are no
> longer allowed to login. sorry, but that is not a scenario I want.
> 

Again... I don't agree... You can set the default validFrom, 
validTo of self-signed certificates  to be from beginning of 
time to the end of time. So it will behave exactly the same 
as RSA keys.

>>I think that ssh should use X.509 (self-signed and not) or
>>kerberos identities, TLS as protocol, and PKCS#11 as
>>cryptographic interface... If you drop all proprietary
>>implementations, I think you find a much simpler code and
>>simpler user experience.
> 
> 
> please address only one issue at a time. if the issue is pkcs#11,
> then it should be addressed on base of the current openssh
> code (without x.509) I think. if you bundle several issues you risk
> getting all rejected because of one part.

I don't agree...
If I implement PKCS#11, I should consider how people mostly 
use PKCS#11...
As generic as PKCS#11 is, it is used in X.509 environment 
where it hold a private key and a certificate.

In the none-standard environments (ssh, gpg) people tend to 
use only raw keys.

Part of my mission of adding support for PKCS#11 interface 
to open source applications is to make them more standard, 
so that they can be used in environments where it was 
difficult to be used so far.

>>Anyway... if X.509 patch will not be merged, I will
>>implement RSA only implementation... 
> 
> 
> from my point of view it would be great to have both.
> if pkcs#11 is accepted into openssh, then roumen
> will most likely accept patches to improve x.509 patch
> to play well with pkcs#11, too.

These are not two separate issues. If openssh will not 
support X.509, I will still require X.509 certificate on the 
PKCS#11 token. I will not support a tokens that are outside 
of X.509 world.

> 
>>You run ssh-agent xterm,
> doesn't help me on a console.

You can use ssh-agent ssh.... :)

>>You want to run ssh without ssh-agent...?!?! I
> 
> yes. for example If I'm working at the console of
> one server (plain virtual console, no agent, no X)
> and then need to log in on other machines to get updates
> pulled. I would want to plugin/out my token all the
> time, but rather
> 	ssh -I 0 otherserver
> to login remote.
> 
> that currently works. if you want to replace opensc support,
> the feature set should not shrink.
> 
> true, you can hack work arounds, but that would be still unfriendly
> to the users, when right now they can use "ssh -I 0 ...".

OK... If all be accepted with the agent, I will patch ssh also.
Although I think current design can be improved if ssh-agent 
will be implemented as a library and be used by ssh if it 
cannot find running ssh-agent. There is no point in 
duplicating code...

>>Some help regarding X.509... If that what you meant...
>>You should add the CA into /etc/ssh/ca/ca-bundle.crt (PEM).
>>You should add the following to ~/.ssh/authorized_keys
>>x509v3-sign-rsa subject=/C=XX/CN=YY
> 
> 
> well, that exactly demonstrates that a CA can create man in the
> middle attacks by issuing key/certs to several people with the same
> subject. nobody will notice.
> 
> I like ssh because it is plain, simple, secure. 

You can still use public key hash... I simply don't like 
it... So it only demonstrate that ssh can be plain, simple, 
secure... :)

> but back to the issue: please take a look at pam_pkcs11.
> sure, it is for login, but they have lots of mappers to implement
> such shemas or other ideas. maybe it would be helpful to
> implement the same concepts and make the config look the
> same? would be a nice service for users.

True... pam_pkcs11 did a wonderful work on parsing 
extensions... You can provide it as a library then it can be 
used by many applications.

>>1. ssh-add does not read config file...
> 
> ouch. but does it have to, if it communicates with ssh-agent?
> (or does the agent neither read the config file?)

ssh, ssh-add find their agent by looking on environment 
variables.

>>2. I think that ssh-add should be called in script...
> 
> no issue here. -o SomeOption=somevalue
> should work, I guess?

Not on current up-stream implementation.

>>I don't think it is comfortable for the user to execute
>>commands if he remove/insert his card, and after expiration...
>>Current implementation prompt for PIN (if needed)  when you
>>ssh... I think it is the best.
> 
> 
> sorry, I disagree. the point of the ssh agent if for many people
> so they can create scripts and have non interactive tasks.
> if you suddenly halt somewhere in the middle and prompt
> for pins, you might confuse users and break those scripts.
> people expect it to work. or to fail. but if something hangs
> because input is asked somewhere, that is very, very confusing
> and hard to debug.

1. If you don't askpin program, ssh-agent will fail and 
won't prompt anything.
2. You can config your own askpass program that takes the 
PIN from other place (Like environment or file)

>>If most user think that ssh-agent should forget keys I will
>>alter current behavior.
> 
> if cards are removed? I think so. the current does not,
> which is also ok,  because (at least with usb crypto tokens)
> you can hook to the hotplug event and run ssh-add -D
> and xlock.

Well... I will be glad to receive other comments regarding 
this... I really don't think so...

> btw: I wonder what everyone thinks about this:
> do you think it would be ok security wise, to have a screen
> lock that not only requires card and pin to unlock, but
> also adds the pin to agents like the ssh agent?

I think that unlock should be enough...

>>I prefer options to be clear... Even if I need to type some
>>more... I will be happy to receive more comments on this...
> 
> 
> you could have long+short options like most apps?
> or - my preference - config file options.

All can be provided... But first major issues should be 
agreed upon... (PIN handling, X.509)

Best Regards,
Alon Bar-Lev.