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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev