openssh PKCS#11 support

[Alon Bar-Lev]

Hello Andreas,

Thank you for your quick feed-back!

Andreas Jellinghaus wrote:
> compile error :)
> 
> gcc 4.0.* (current kubunto 5.10).
> 
> compiles fine with gcc 3.4.

Sorry... I'd put prototype in-side function... Strange that 
gcc 4 does not accept it...
Please tell me if moving "static void usage (void);" to 
global scope helps.

> Some other notes from my side:
>  - a version without x.509 would be great. from my point of view x.509 is
>    something most people don't need and a huge source of complexity
>    with very little benefit. most people work much better with rsa keys only,
>    not with (ca signed) certificates, cert chains, lists of trusted cas, crls,
>    and all the other stuff. for the small scale it is a HUGE overhead with
>    much more cost than pay off.

I don't agree...
You can use self-signed certificates for small scale... You 
get the same complexity of RSA keys.
Then the implementation handles only one format of 
authentication method...

The usage of self-signed certificates should be integrated 
into the ssh-keygen and then it will be as simple as using 
rsa keys.

I hope I won't regret this... But...

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.

Anyway... if X.509 patch will not be merged, I will 
implement RSA only implementation... Although I think it is 
a mistake.

>    ironically now that people use x.509 large scale we see it doesn't work
>    for them either. like the us dod with a CRL > 50 mb or belgium with a
>    similar big CRL. 

This issue can be easily resolved using a proper 
algorithm... If this is the last issue that blocks X.509 
merging, I can work with Rumen in order to hash CRL in order 
to handle large CRLs.

Another approach may be to trust each authorized end 
certificate, and leave out the X.509 hierarchy... You get 
the same management difficulties of RSA keys... But without 
the overhead of X.509.

For a conclusion, if you are open for it... I think we 
should discuses the X.509 issue more deeply...

>  - how can I use the ssh command with my pkcs#11 module?
>    the binary tells me: no support for smart cards. I think it is very
>    important to have direct ssh support, too.

You run ssh-agent xterm, then in the opened xterm you simply 
ssh... Oh... You want to run ssh without ssh-agent...?!?! I 
think you can write a simple script and then use:
$ ssh-agent script

Again... If it is required, I will add this... But maybe a 
better design is to remove all private key code from ssh and 
make ssh fork ssh-agent as a child... Or making ssh-agent a 
library...

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

Also try MandatoryCRL no in /etc/sshd_config

> 
>  - ssh-add: why new --options? openssh has lots of options that
>    can be placed in the config file or given via -o Option=Value.
>    I think it would be very user friendly to be able to put the options
>    in the config file, and then also pass them as usual with -o.

1. ssh-add does not read config file...
2. I think that ssh-add should be called in script...
3. Most of static options (provider, askpin) should be of 
ssh-agent... This is part of my note for maintainers... I 
will read all static options from config file.

>  - I'm not sure why the agent needs the ask pin program. can you
>    explain? (I thought you give the pin when you add a key, and if
>    the card is removed or something like that, the agent simply
>    drops it, so you have to add it again).

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.

If most user think that ssh-agent should forget keys I will 
alter current behavior.

I think a better implementation would be to allow the 
ssh-agent notify ssh that a password is required along with 
a prompt, than ssh will get this password and forward it to 
the agent...

>  - the --pkcs11-add-id option: why not use the "normal"
>     "-s 0" instead of --pkcs11-add-id --pkcs11-slot 0

I wanted to make the interface as generic as I could... Most 
user will NOT use the slot id... Most (I hope) will prefer 
to use the --pkcs11-slot-type label --pkcs11-slot "token 
label" since it will find the right slot based on their 
token label, so they can insert their token to any slot.

In opensc implementation you must specify slot id... So I 
can make an alias and accept -s argument...

> 
>  - are --pkcs11-id-type and --pkcs11-id required? what is the
>    default? could be wrapped into a complex string like
>    "-s 0:id:0" or "-s 0:label:Andreas Jellinghaus" or similar.
>    that would be at least a lot less to type :)

I prefer options to be clear... Even if I need to type some 
more... I will be happy to receive more comments on this...

>  - what exactly does --pkcs11-protected-authentication ?

If you have external key-pad or biometric support, you need 
to pass NULL to C_Login...

> 
> Sorry, need to go now, will test later.

Looking forward!

> 
> Thanks for your patch, great work!

Thanks!

> 
> Regards, Andreas
> 

Best Regards,
Alon Bar-Lev.