Bug#482806: [openssh] openssh-pki packages creation and state of the art for a more secure OpenSSH
Package: openssh
Severity: wishlist
--- Please enter the report below this line. ---
Howdy !
I dare to add a new wish about OpenSSH, though it is not totally unrelated to
two other recent ones (about smartcards [1] and LDAP [2])... Well, I certainly would not do that without (good, I hope) reasons, which I will try to describe in this (a bit long, I fear - please dont flee!) analysis of the situation I could come up with...
First, there is this quite old official sort-of-support for opensc... but it is not as functionnal as it may seem : it doesn't alter the askpass mechanism, thus fails at loading a private key necessiting a PIN, as it cannot ask for it...
For this to operate smoothly, it takes a patch ; this patch can be found, for instance through apt source, under ./opensc-0.11.1/src/openssh if you get the sources of opensc... and the README mentions clearly that "this patch can add the desired functionality, but [that] it is a crude hack, not meant to be added to openssh releases."
Is this what we really want in a Debian package ?
On the other hand, direct OpenSC support is not what tends to be adopted nowadays... OpenSC implements a whole lot of things, among which PKCS#11 (cryptographic operations requests) and PKCS#15 (data storage), which is great, because maintenance times may force us to directly interact with the datas stored (though not necessarily being able to extract it ; we may simply ask to clear a store, change a pin, extract a public key, etc...); but for authentication, signatures, or ciphering, only PKCS#11 support is needed...
... which is the case for what concerns the smartcard part of my wish... a lot of projects now use or have patches for simple PKCS#11 support, be it through libp11 [3] or pkcs11-helper [4] : OpenSSL, OpenVPN, GnuPG, or... OpenSSH...
One individual is remarkably implied in the quest to bring support for PKCS#11 in free softwares that would benefit from it : Alon Bar-Lev, who has participated in bringing this kind of feature in a lot of softwares [5], maintains a patch that seems to bring a cleaner smartcards support in portable OpenSSH [6].
One advantage of this one towards the dependency hell problematic is that it seems to only, and cool thing - not statically, depend on pkcs11-helper...
The man tries to have his work integrated upstream, but OpenSSH developpement is not so easy to get in, as one may guess ;) . Though he's been in touch with Damien Miller on openssh-unix-dev, this kind of features does not seem to attract that much attention from upstream, who doesn't seem to consider this as a priority of any kind (one must confess they are already busy adding very cool features, such as native chrooting of SSH environment, starting from 4.8p1)...
So instead of having to resort to the "crude hack" from OpenSC sources, if smartcards support should be brought to OpenSSH at the moment, I guess it would have to be through the work of Alon Bar-Lev.
Well... here it is for smartcards... but I guess the problematic is larger... OpenSSH is a very cool and useful piece of software, but maintenability of the keys on a lot of machines is a really heavy task... Alon Bar-Lev pertinently writes on his project page that "People who use PKCS#11 most likely use it in X.509 environment and they wish to use the same identities also with openssh"...
Which leads us to a PKI problematic... if smartcard support (typically RSA 2048 bits keys on Cryptoflex E-Gate 32k, which is all that I found being freely supported with large keys on Linux) could have helped not exposing keys like in the very recent OpenSSL entropy problem, it is of no help in distributing keys accross a lot of machines, which is what this incident has most certainly forced a lot of people to do...
To my knowledge, there are two patch-sets that provide distribution of the public keys that are authorized to be used, and listings of those that are not, both resorting on LDAP.
First one is the LPK patch [7]... sad thing is that it is loosing the support from Inverse Path Ltd, due to the lack of answers from upstream to their merge request, though writer's support will apparently still exist... but above all, I must confess I don't know anything about the compatibility with Alon's patch, so I cannot really advocate in favor of this one or not...
Other one is Roumen Petrov's OpenSSH X.509 patch [8]. Cool thing about this one : Alon Bar-Lev works with him, and patches seem to be made to integrate well together. It adds support for X.509 certificate, which allows to manage the identity inside the key/certificate, and can even get the valid/revoked certificates from an LDAP server (if activated on the ./configure)... though I haven't found a lot of information about the dependency this one may require (a quick look at Gentoo's ebuild, that can activate either LPK's, either Roumen's, patch, but not both at the same time, which is perfectly undestandable, doesn't seem to suggest any kind of mandatory dependency)... and though there are still a few "todo" to achieve (quite minor, IMHO).
To be fair, there also has been a patch from Daniel Hartmeier, together with a validation daemon [9], that has been written, but it did not came into upstream either...
Anyway, I guess the situation could be resumed to this :
- "opensc" configure option is old and requires a "crude hack", thus should not be considered for integration (as advertised in OpenSC sources README);
- pkcs11 patch seems to be the way, but is not upstream yet;
- people wishing to use PKCS#11 devices are prone to be in a PKI and may want more features;
- there are also two sets of patches that allow LDAP management, and one of them is tailored to work well with PKCS#11's one;
... which in turn, makes me think of what is possible, in order to take the state of the art in consideration :
- invalidate wishes for old and hackish "opensc" flag (reasonable, I guess);
- integrate PKCS#11 patch in OpenSSH, as it doesn't bring static dependencies, though it is not upstream (not very at ease with this one, personnally... OpenSSH is so crucial that it is a risky path, and OpenSSL problem showed how hazardous, though well-intentioned, upstream patching can be dangerous on crucial elements);
- create new additionnal packages (openssh-pki and openssh-server-pki) that would bring PKCS#11, X.509 and OpenLDAP public keys distribution (after having chosen between LPK and Roumen's patch, the latter being notoriously compatible with PKCS#11 support) to those who are willing to accept external patchsets for this kind of functionnalities...
...I guess feasability about long-term maintenance should at least be discussed with the authors of the patches : but they really seem cooperative, and willing to have their work used, reviewed and told about, so... Alon had proposed Gentoo to maintain the integration of his patch, instead of using the hack from OpenSC sources, and not-upstream patch addition to the standard package has naturally been refused (which doesn't prevent them to propose the hackish opensc way)... but if everyone ignores any initiative of the kind, it will end up with people giving up, like Inverse Path Ltd did...(clearly, I would love to see these two packages created);
- work with upstream patchers, if Debian maintainers feel necessary to modify certain things before begining to package (obvious mitigation faint ;) );
- clearly tell that there won't be any kind of support for this kind of features until it is integrated upstream, and let users on their own, having to recompile or switch to other distros, may it be at the price of some "crude hack" and chainsawed-homemade-packets&co-crafting (I particularly fear that answer)...
Sorry for this long message (and for its redundancy, well, kind of, as I propose a different path, with two other recent wishes), but as I am thinking of buying some smartcards, just to play with (basically, I intend to take two Cryptoflex E-gate 32k [10], with an Eutronsec SIM+Classic Smart Card+USB flash drive reader, that complies with CCID standard [11]... this reader is sooooo sexy), I am naturally coming across the possibilities... and the lack of it in OpenSSH is a major frustration to me... it is now years since I periodically come across this kind of wishes in bugreports, but it is the first time I really inform myself as much, and think of effectively buying a crypto device...
So I felt I should share the information I gathered about what can be done right now, and the constraints it implies...
... there is a real demand for this (at least 4 years of people dreaming about this kind of thing in this list, though it must be recognized that implementations are still young and not officially supported, which can be mitigated by the facts that some people are working to answer the problematic, and that things now seem better than they may have been, as "serious" patches, ie pretending to be usable, at least do exist) and I wish it could be answered in Debian (or explicitely be told that it definately won't :( ), as this distro has already been able to bring me innovative features that I love (like vserver-enabled-kernel, which is of great use, on machines that do not have enough RAM to have Xen)...
Well... wish is done... any comments?
Aefron.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481769
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481278
[3] http://www.opensc-project.org/libp11/
[4] http://www.opensc-project.org/pkcs11-helper/
[5] http://alon.barlev.googlepages.com/open-source
[6] http://alon.barlev.googlepages.com/openssh-pkcs11
[7] http://dev.inversepath.com/trac/openssh-lpk
[8] http://www.roumenpetrov.info/openssh/
[9] http://undeadly.org/cgi?action=article&sid=20061204161240&mode=expanded
[10] http://www.cryptoflex.com/Products/cards_egate.html
[11] http://www.eutronsec.it/infosecurity/contents/productline/Details.aspx?IDProd=11&IDFamiglia=3&IDDett1lev=931
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.24-1-686
Debian Release: lenny/sid
500 testing security.debian.org
500 testing ftp.fr.debian.org
--- Package information. ---
Depends (Version) | Installed
=======================-+-===========
|
__________________________________________________
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
Reply to: