[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Damien Miller changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #26 from Damien Miller --- OpenSSH 8.2 will implement U2F authentication using a different approach (see PROTOCOL.u2f in the tree) -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #25 from jordandev...@gmail.com --- So in the interests of keeping this moving I've been chatting with some of the guys above and I thought I’d pick this up and try to push it forward a little. So here’s a recap of what immediate issues seemed outstanding and some possible resolutions/thoughts. 1) It depends on a GPL library which is a licensing conflict we don't want. Libfido2 (https://github.com/Yubico/libfido2) is now BSD. I’ve got an updated patch I’m working on with this library instead. https://bitbucket.org/Jordandev678/ - I could use some testers if anyone is interested. Damien - does that sufficiently knock this concern on the head? 2) The spec is insufficient - we need more than "put this blob from the library that's specified for Javascript on the wire". The spec as it stands now (xml2rfc WIP version also in bitbucket above) breaks it down a little more into the individual fields. That said the fields are the CTAP CBOR format - there isn't really any getting away from that. OpenSSH is always going to be mostly a relay in this process between the client device and the libfido2 sever library. But this is a 'natural' breakdown of the U2F segments for SSH to work with I think. N.B. U2F registration has been kicked out-of-spec (at least for now) so that should simplify things too. One thing at a time! Does that move some way towards making people more comfortable with this? 3) The spec as it stands has some problems. As someone who knows more than U2F than I said (privately): > The draft, as I read it, does not do any validation of the > username provided prior to sending a list of key handles for the > user. This is somewhat of a security concern, since it reduces the > "2F" in universal second factor to a single factor. Personally, > I'm willing to overlook that one a little: if we believe attackers > can easily get at your passwords, then this loss is a small one. The draft does suggest not advertising the u2f method until another has been successfully completed. The patch also won’t run U2F and send the keys until you’ve made it that far in one of the allowed AuthenticationMethod lists. So if you have the setup as “password,u2f” it will never trigger unless you first get a valid username/password combination. I tested attempting to have the client ‘jump-ahead’ and it didn’t seem to work: $ sudo sshd -d -o U2FAuthentication=yes -o AuthenticationMethods=password,u2f $ ssh -p -o PreferredAuthentications=u2f,password jordan@127.0.0.1 true >debug1: userauth-request for user jordan service ssh-connection method none >[preauth] >debug1: authentication methods list 0: password,u2f >debug1: userauth-request for user jordan service ssh-connection method >password [preauth] >debug1: userauth-request for user jordan service ssh-connection method u2f >[preauth] Unless there's a different way to ‘skip ahead’ I don’t know about in OpenSSH (happy to be corrected here) - then I believe this concern is solved practically in the patch. From a specification perspective if people want to make the spec a bit stronger (i.e. SHOULD to MUST) I have no strong objections. Although perhaps there’s merit to catering to people using just U2F keys if they manually configure it as valid method on its own? It's better than keeping an unencrypted key on a USB stick (hey, I’ve seen people do it!). At least with U2F the key can’t be copied of and re-used without the users knowledge. > The other concern I have with their approach is that it doesn't > protect the user's privacy. The regular SSH protocol relies > on a leap of faith, in that neither the client nor the server > have any way to authenticate one another the first time they're > introduced, so one must assume that there's no attacker present > at that time. Still, it's customary for an SSH client to generate > a new key pair for every server it's introduced to, in order for > one server not to be able to correlate one user with another. One > SSH server could reveal a user's public key to another, but that > wouldn't compromise the user's privacy: the client would not use > the key pair for server A with server B. > In U2F, the assumption is that the U2F devices themselves > may be storage-less. As a result, the server sends a "key > handle" to remind the U2F device which key pair to use. The > application parameter is a means by which the key pair is bound > to a particular place. It's the web origin in the case of web > authentication flows. The keys are cryptographically bound to the > application parameter, such that no server that is associated with > a different application parameter can exercise the key. (This > protection relies on a trusted piece of software, i.e. the web > browser in the case of the web, to tell the U2F device which > server it is.) In this way, the key handles are safe: even if > server A reveals the key handle for Alice to server B, server B > can't learn that
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Jon Gjengset changed: What|Removed |Added CC||j...@thesquareplanet.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 labor4 changed: What|Removed |Added CC||schreibti...@labor4.ch -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 mdaniels5...@gmail.com changed: What|Removed |Added CC||mdaniels5...@gmail.com -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 dan...@lbe.rs changed: What|Removed |Added CC||dan...@lbe.rs -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 bugzillamindrot...@unrelated.net.au changed: What|Removed |Added CC||bugzillamindrotorg@unrelate ||d.net.au -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Thomas Jaroschchanged: What|Removed |Added CC||thomas.jaro...@intra2net.co ||m -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 jordandev...@gmail.com changed: What|Removed |Added CC||jordandev...@gmail.com -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Torbjörn Lönnemarkchanged: What|Removed |Added CC||tob...@ryara.net -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 David Langchanged: What|Removed |Added CC||da...@lang.hm --- Comment #24 from David Lang --- Any update on this (either accepting the optional u2f lgpl lib, asking Yubico to allow the BSD license, or writing a replacement)? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 rickard.von.es...@gmail.comchanged: What|Removed |Added CC||rickard.von.es...@gmail.com -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Mike Frysingerchanged: What|Removed |Added CC||vap...@gentoo.org --- Comment #23 from Mike Frysinger --- (In reply to Simon Josefsson from comment #22) OpenSSH is BSD, so GPL-vs-LGPL is kind of splitting hairs. pretty sure "GPL library" was referring to the overall GPL family rather than the GPL subclass (e.g. GPL-2 & GPL-3). openssh does support building/linking against readline which is GPL-2, but in that case there is a BSD replacement available (libedit). they're API compatible, but that's because libedit implemented the readline API (with readline being 15 years old before libedit showed up). at least in most Linux distros, we are linking openssh against readline. so i'm not sure optional support for libu2f is a problem ? it seems a disservice to block support because no one has stepped up to implement a comparable BSD-compatible library. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 sami.lo...@gmail.com changed: What|Removed |Added CC||sami.lo...@gmail.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #22 from Simon Josefsson--- > 1) Tt depends on a GPL library which is a licensing conflict we > don't want. libu2f-host is LGPLv2+. > 2) The spec is insufficient - we need more than "put this blob from > the library that's specified for Javascript on the wire". Which spec are you talking about? U2F itself or the IETF draft? The U2F specifications are unfortunately structured in an unusual way because it is oriented towards web browser based situations. However it is possible to abstract out the relevant details for non-browser scenarios. I agree and admit that this is not the intended scope, but I don't think that should limit further considerations. I am happy to work on clarifying the IETF specification. While at Yubico, I tracked U2F specifications closely and have familiarity with it. > 3) The spec as it stands has some problems. As someone who knows > more than U2F that I said (privately): > > > The draft, as I read it, does not do any validation of the > > username provided prior to sending a list of key handles for the > > user. This is somewhat of a security concern, since it reduces the > > "2F" in universal second factor to a single factor. Personally, > > I'm willing to overlook that one a little: if we believe attackers > > can easily get at your passwords, then this loss is a small one. I don't understand this concern -- yes, you may get access to people's key handles. If that leads to security concerns, there is something really strange going on. Key handles are intended (cryptographically) to only be usable by the key holder. More details please? > > The other concern I have with their approach is that it doesn't > > protect the user's privacy. The regular SSH protocol relies > > on a leap of faith, in that neither the client nor the server > > have any way to authenticate one another the first time they're > > introduced, so one must assume that there's no attacker present > > at that time. Still, it's customary for an SSH client to generate > > a new key pair for every server it's introduced to, in order for > > one server not to be able to correlate one user with another. One > > SSH server could reveal a user's public key to another, but that > > wouldn't compromise the user's privacy: the client would not use > > the key pair for server A with server B. I'm not sure I agree with this reasoning: as far as I recall, the SSH protocol does not guarantee protection of user's privacy. As far as I am aware, it is not standard procedure for SSH clients to generate a new key pair for every server. Maybe the answer to the following question will allow me to understand the concern better: In what way does U2F decrease the user's privacy? > > In U2F, the assumption is that the U2F devices themselves > > may be storage-less. As a result, the server sends a "key > > handle" to remind the U2F device which key pair to use. The > > application parameter is a means by which the key pair is bound > > to a particular place. It's the web origin in the case of web > > authentication flows. The keys are cryptographically bound to the > > application parameter, such that no server that is associated with > > a different application parameter can exercise the key. (This > > protection relies on a trusted piece of software, i.e. the web > > browser in the case of the web, to tell the U2F device which > > server it is.) In this way, the key handles are safe: even if > > server A reveals the key handle for Alice to server B, server B > > can't learn that the key pair is in fact associated with an entity > > of interest to B, because B can't exercise Alice's key handle for > > server A. I agree with this description, FWIW. > > By using a static application parameter, their protocol leaves > > users exposed to a new attack. This would indeed be a flaw in the patch. I agree! I believe it was a known issue, see earlier discussions. > ... which brings me to 4) I'm not familiar enough with U2F to review > it. > > Without a proper specification that has been reviewed by people who > are properly familiar with U2F and a way to remove the licensing > conflict, please do not expect any progress here. Thanks. Hopefully we can get more eyes on the draft itself and people can start to test the patch a bit more. I fully agree that this is not a done deal, however, I believe we are getting there! Thanks, /Simon -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #21 from Damien Miller--- A few people have asked (well, complained) why this hasn't been committed. The answer is basically that: 1) Tt depends on a GPL library which is a licensing conflict we don't want. 2) The spec is insufficient - we need more than "put this blob from the library that's specified for Javascript on the wire". 3) The spec as it stands has some problems. As someone who knows more than U2F that I said (privately): > The draft, as I read it, does not do any validation of the > username provided prior to sending a list of key handles for the > user. This is somewhat of a security concern, since it reduces the > "2F" in universal second factor to a single factor. Personally, > I'm willing to overlook that one a little: if we believe attackers > can easily get at your passwords, then this loss is a small one. > > The other concern I have with their approach is that it doesn't > protect the user's privacy. The regular SSH protocol relies > on a leap of faith, in that neither the client nor the server > have any way to authenticate one another the first time they're > introduced, so one must assume that there's no attacker present > at that time. Still, it's customary for an SSH client to generate > a new key pair for every server it's introduced to, in order for > one server not to be able to correlate one user with another. One > SSH server could reveal a user's public key to another, but that > wouldn't compromise the user's privacy: the client would not use > the key pair for server A with server B. > > In U2F, the assumption is that the U2F devices themselves > may be storage-less. As a result, the server sends a "key > handle" to remind the U2F device which key pair to use. The > application parameter is a means by which the key pair is bound > to a particular place. It's the web origin in the case of web > authentication flows. The keys are cryptographically bound to the > application parameter, such that no server that is associated with > a different application parameter can exercise the key. (This > protection relies on a trusted piece of software, i.e. the web > browser in the case of the web, to tell the U2F device which > server it is.) In this way, the key handles are safe: even if > server A reveals the key handle for Alice to server B, server B > can't learn that the key pair is in fact associated with an entity > of interest to B, because B can't exercise Alice's key handle for > server A. > > By using a static application parameter, their protocol leaves > users exposed to a new attack. (some of the details about how SSH works wrt user key exposure in the above are incorrect, but the broader point still stands.) ... which brings me to 4) I'm not familiar enough with U2F to review it. Without a proper specification that has been reviewed by people who are properly familiar with U2F and a way to remove the licensing conflict, please do not expect any progress here. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Fernando Herrerachanged: What|Removed |Added CC||fherr...@onirica.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Fabian Peter Hammerlechanged: What|Removed |Added CC||fabian.hamme...@gmail.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Vincent Brillaultchanged: What|Removed |Added CC||g...@lerya.net --- Comment #20 from Vincent Brillault --- Compilation fails for me when kerberos support is enabled due to: In file included from auth-u2f.c:48: ./monitor_wrap.h:64:1: error: unknown type name 'OM_uint32' OM_uint32 mm_ssh_gssapi_server_ctx(Gssctxt **, gss_OID); (And several other similar errors). Quick fix on my side to get it to compile: add '''#include "ssh-gss.h"'''. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Jakub Jelenchanged: What|Removed |Added Attachment #2710|0 |1 is obsolete|| --- Comment #18 from Jakub Jelen --- Created attachment 2782 --> https://bugzilla.mindrot.org/attachment.cgi?id=2782=edit U2F patch @ master My previous patch was missing few files (that you could get from the original patch) and therefore few people wrote me. Adding rebased patch to current master with all the files. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #19 from mm...@e-motz.com --- (In reply to Jakub Jelen from comment #18) > Created attachment 2782 [details] > U2F patch @ master > > My previous patch was missing few files (that you could get from the > original patch) and therefore few people wrote me. Adding rebased > patch to current master with all the files. This resolved the aforementioned errors for me. After completing u2f support on both client and server, however, There still seems to be problems. qr@host:~$ ssh -o U2FMode=registration vpn > /tmp/u2f-key.pub sign_and_send_pubkey: signing failed: unexpected internal error qr@vpn's password: The terminal becomes frozen at this point and the tmp file is created, but is blank. Is there any client side configuration that needs to be modified for U2F support or could the issue be somewhere else? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 mm...@e-motz.com changed: What|Removed |Added CC||mm...@e-motz.com --- Comment #17 from mm...@e-motz.com --- A couple of things to mention here, the patch has failed in two different files, which I manually patched, patching file readconf.c Hunk #1 succeeded at 150 (offset 1 line). Hunk #2 succeeded at 199 (offset 1 line). Hunk #3 succeeded at 927 (offset 29 lines). Hunk #4 succeeded at 1673 (offset 52 lines). Hunk #5 FAILED at 1851. Hunk #6 succeeded at 2345 (offset 55 lines). 1 out of 6 hunks FAILED -- saving rejects to file readconf.c.rej readconf.c.rej: --- readconf.c +++ readconf.c @@ -1851,6 +1869,10 @@ fill_default_options(Options * options) options->tun_remote = SSH_TUNID_ANY; if (options->permit_local_command == -1) options->permit_local_command = 0; + if (options->u2f_authentication == -1) + options->u2f_authentication = 1; + if (options->u2f_mode == NULL) + options->u2f_mode = strdup("authentication"); if (options->use_roaming == -1) options->use_roaming = 1; if (options->visual_host_key == -1) patching file sshkey.c Hunk #3 FAILED at 117. Hunk #4 succeeded at 515 (offset -3 lines). Hunk #5 succeeded at 797 (offset -3 lines). Hunk #6 succeeded at 1276 (offset -4 lines). Hunk #7 succeeded at 2016 (offset -3 lines). Hunk #8 succeeded at 2158 (offset -3 lines). Hunk #9 succeeded at 2212 (offset -3 lines). 1 out of 9 hunks FAILED -- saving rejects to file sshkey.c.rej sshkey.c.rej: --- sshkey.c +++ sshkey.c @@ -117,6 +122,7 @@ static const struct keytype keytypes[] = { # endif /* OPENSSL_HAS_NISTP521 */ # endif /* OPENSSL_HAS_ECC */ #endif /* WITH_OPENSSL */ + { "ssh-u2f", "U2F", KEY_U2F, 0, 0 }, { NULL, NULL, -1, -1, 0 } }; and while trying to make openssh the following errors are produced and am unable to solve qr@vpn:~/openssh $ make (cd openbsd-compat && make) make[1]: Entering directory '/home/qr/openssh/openbsd-compat' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/qr/openssh/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I. -I/usr/local/include/u2f-host -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c sshkey.c -o sshkey.o sshkey.c:65:17: fatal error: u2f.h: No such file or directory #include "u2f.h" ^ compilation terminated. Makefile:155: recipe for target 'sshkey.o' failed make: *** [sshkey.o] Error 1 -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Adam Goodechanged: What|Removed |Added CC|a...@spicenitz.org | -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 bugme...@mailinator.com changed: What|Removed |Added CC||bugme...@mailinator.com --- Comment #16 from bugme...@mailinator.com --- (In reply to Han-Wen Nienhuys from comment #11) > Regarding registration: I think it should not be part of the spec. > > Once the user is properly authenticated through some mechanism, > there are other ways to set up an entry in .ssh/authorized_keys, > including executing a shell command "echo >> > .ssh/authorized_keys" (this requires no support from the server), or > sending a global request with some serialized data attached. I second this, focusing on auth only would speed up the process of ever getting this reviewed and merged. Registration could be added as a standalone tool, look at ssh-copy-id for example. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Les Akerchanged: What|Removed |Added CC||m...@lesaker.org -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Georg Sauthoffchanged: What|Removed |Added CC||mind...@georg.so -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 wik...@metacode.biz changed: What|Removed |Added CC||wik...@metacode.biz -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #15 from Simon Josefsson--- I'm happy to update the RFC draft, or let others join as co-authors to update it, but I'm worried that 1) the draft drifts away from what is implemented (although I'm not certain what the status is of the draft), and 2) that we are not getting closure on what should actually go into the protocol. Please email offlist if you want to help the effort, or feel free to bring this up on the ietf-ssh mailing list and suggest what should change in the latest draft and why. If there is a patch to go with the suggestion, that usually wins :-) /Simon -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #14 from Adam Goode--- Is there a new version of the RFC draft in the works? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Adam Goodechanged: What|Removed |Added CC||a...@spicenitz.org -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Troy Readychanged: What|Removed |Added CC||t...@troyready.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Jakub Jelenchanged: What|Removed |Added CC||jje...@redhat.com --- Comment #13 from Jakub Jelen --- Created attachment 2710 --> https://bugzilla.mindrot.org/attachment.cgi?id=2710=edit patch rebased to current upstream I did informal review of the patch from comment 4, rebased it to current upstream version and tested with yubikey neo. It worked well and I also like the idea. There are few things to note: * There is non-complete client option u2f_authentication, which is used for allowing this type of authentication on client. This should be covered in config parser and also documented in ssh_config (fixed) * Build with gssapi was failing, because of undefined symbols in monitor_wrap.c (included from auth-u2f.c). Added missing include ssh-gss.h. (fixed) * some functions from sshconnect2.c and ssh-u2f.c have wrong interface for ssh_dispatch_set. Changing void to int and adding appropriate return value.(fixed) * SSL_load_error_strings function is used, but header providing this function is not included. Adding appropriate include. (fixed) Still there are some TODO comments, that should be taken care of. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Tobias Florekchanged: What|Removed |Added CC||mind...@ibotty.net --- Comment #12 from Tobias Florek --- Is there some progress being made? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 m...@mikedoherty.ca changed: What|Removed |Added CC||m...@mikedoherty.ca -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 semenko n...@semenkovich.com changed: What|Removed |Added CC||n...@semenkovich.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Peter Moody mind...@hda3.com changed: What|Removed |Added CC||mind...@hda3.com -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 maze+bugzilla-mindrot-...@strahlungsfrei.de changed: What|Removed |Added CC||maze+bugzilla-mindrot-org@s ||trahlungsfrei.de -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Mantas M. graw...@gmail.com changed: What|Removed |Added CC||graw...@gmail.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Han-Wen Nienhuys hanw...@gmail.com changed: What|Removed |Added CC||hanw...@gmail.com --- Comment #11 from Han-Wen Nienhuys hanw...@gmail.com --- Regarding registration: I think it should not be part of the spec. Once the user is properly authenticated through some mechanism, there are other ways to set up an entry in .ssh/authorized_keys, including executing a shell command echo .ssh/authorized_keys (this requires no support from the server), or sending a global request with some serialized data attached. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Matt Johnston m...@ucc.asn.au changed: What|Removed |Added CC||m...@ucc.asn.au --- Comment #10 from Matt Johnston m...@ucc.asn.au --- (I'm looking at https://datatracker.ietf.org/doc/draft-josefsson-secsh-u2f/?include_text=1 ) I think it would be worth using the 32 byte challenge to bind the authentication to the current SSH session. Otherwise an attacker running a SSH server can get their clients to sign a response for another server if they know an entry from authorized_keys (because of origin/appid of ssh://localhost)? Maybe something like challenge = chal_sess_hash | 16_random_bytes where chal_sess_hash is a 16 byte truncated sha256 hash of stringsession identifier byte SSH_MSG_USERAUTH_REQUEST stringuser name stringservice name stringu2f The client MUST check that the first 16 bytes is correct - that's slightly more complexity (decoding JSON) though the code's already there for the server. That would also improve resistance to MITM even if the server hostkey is compromised/ignored. Existing SSH public key authentication does that by including the sessionid in the hash being signed (rfc4253 page 9). For integration with SSH I think a constant origin/appid string is probably useful - people expect to be able to connect to a host at varying IPs/hostnames. Copy/pasting from one host's authorized_keys to another is also common practise. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #9 from Simon Josefsson si...@josefsson.org --- Btw, I've updated the draft a bit -- see earlier URL. I'm not sure if this bug report is the best place for design discussions, but I believe one aspect of Michael's protocol should be discussed further. Maybe this protocol shouldn't do U2F registration. The U2F Registration can happen out-of-band using some command line tools (see our u2f-host and u2f-server projects). The reason why I decided to put registration into the protocol is that it makes the entire process of starting to use U2F _much_ simpler and more robust against human mistakes. If we provide U2F, but it’s hard to use, nobody will use it. Sure -- and it enables the SSH server to perform various other checks on the U2F registration too, similar to how U2F is done on the web. I think I changed my mind on this, although I'm not yet certain I like how the user has to perform manual tasks after the registration step is completed. It feels that either U2F registration is completly out of scope, or it is completely in scope, so that the server makes sure that once U2F registration has succeeded, U2F authentication should work for that user.Maybe the server could put succeeded registrations into /etc/ssh/u2f/ instead of user's home directories? Just an idea. When having the registration in a separate tool, the user needs to make sure that the appid and origin are specified in the same way as OpenSSH uses them. By keeping registration and authentication closely together, there cannot be a mismatch here, and if we ever need to change the appid/origin, they can never drift apart (think a user has one version of the registration utility but uses a different OpenSSH version, likely without knowing). This brings up the question about appid/facetid. I don't like how ssh://localhost is used. Kerberos/GSSAPI has the same hostname comparison issue that you describe, FWIW, and I believe its security is better than no hostname comparison at all. Then you could use U2F as a single-factor protocol too. I find that the server admin part of handling registration is a bit strange. It may be that I'm not just getting what is achieved here. I don’t think U2F should be used as a single-factor protocol in OpenSSH (or the web). That’s essentially as safe as having an unprotected SSH authentication key on a USB drive. I’m worried that people might think it’s more than that and get a false sense of security. It is a bit better -- it is as safe as having an uncopyable unprotected SSH authentication key on a USB drive. The private key never leaves the device, and human interaction is required for every authentication operation. I don't care strongly about this -- just saying it may be possible if there is interest. /Simon -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #8 from Michael Stapelberg michael+mind...@stapelberg.de --- (In reply to Simon Josefsson from comment #7) Hi everyone. I agree that it would be nice to write up the protocol spec in IETF form -- talking to Michael, he would be positive to this so I started that effort. See: https://gitorious.org/ietf-simon/u2f-secsh/source/ In particular: https://gitorious.org/ietf-simon/u2f-secsh/raw/draft-josefsson-secsh- u2f.txt Thanks for getting this started! I'm not sure if this bug report is the best place for design discussions, but I believe one aspect of Michael's protocol should be discussed further. Maybe this protocol shouldn't do U2F registration. The U2F Registration can happen out-of-band using some command line tools (see our u2f-host and u2f-server projects). The reason why I decided to put registration into the protocol is that it makes the entire process of starting to use U2F _much_ simpler and more robust against human mistakes. If we provide U2F, but it’s hard to use, nobody will use it. When having the registration in a separate tool, the user needs to make sure that the appid and origin are specified in the same way as OpenSSH uses them. By keeping registration and authentication closely together, there cannot be a mismatch here, and if we ever need to change the appid/origin, they can never drift apart (think a user has one version of the registration utility but uses a different OpenSSH version, likely without knowing). Then you could use U2F as a single-factor protocol too. I find that the server admin part of handling registration is a bit strange. It may be that I'm not just getting what is achieved here. I don’t think U2F should be used as a single-factor protocol in OpenSSH (or the web). That’s essentially as safe as having an unprotected SSH authentication key on a USB drive. I’m worried that people might think it’s more than that and get a false sense of security. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Simon Josefsson si...@josefsson.org changed: What|Removed |Added CC||si...@josefsson.org --- Comment #7 from Simon Josefsson si...@josefsson.org --- Hi everyone. I agree that it would be nice to write up the protocol spec in IETF form -- talking to Michael, he would be positive to this so I started that effort. See: https://gitorious.org/ietf-simon/u2f-secsh/source/ In particular: https://gitorious.org/ietf-simon/u2f-secsh/raw/draft-josefsson-secsh-u2f.txt As of writing, this is just cut'n'paste from Michael's description, but the intention is to expand on it. If anyone wants commit rights, just drop me an email. FWIW, my background is that I'm working at Yubico and have been involved in the U2F protocol and its standardization. I'm not sure if this bug report is the best place for design discussions, but I believe one aspect of Michael's protocol should be discussed further. Maybe this protocol shouldn't do U2F registration. The U2F Registration can happen out-of-band using some command line tools (see our u2f-host and u2f-server projects). Then you could use U2F as a single-factor protocol too. I find that the server admin part of handling registration is a bit strange. It may be that I'm not just getting what is achieved here. Cheers, Simon -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 r04r mind...@minichan.org changed: What|Removed |Added CC||mind...@minichan.org -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #6 from Michael Stapelberg michael+mind...@stapelberg.de --- (In reply to Damien Miller from comment #5) (In reply to Michael Stapelberg from comment #3) (In reply to Damien Miller from comment #2) I think it is best that you start with a description of the u2f authentication method protocol - it's much better to review that the protocol is sound before looking at the implementation. Could you write this up? From that comment it sounds like there is some misunderstanding here :). U2F stands for Universal Second Factor, see also http://en.wikipedia.org/wiki/Universal_2nd_Factor You can find the protocol specification on http://fidoalliance.org/specifications/download/ I’ve done a presentation at our local computer club, you can find the slides here: https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf — they contain a pretty high-level and easy to understand description of U2F. Is that what you were looking for? If not, let me know :). No, I'm looking for a description of what goes on the wire for SSH. Like what RFC4252 does for the existing SSH authentication methods. Ah, I see. Here goes: When the client starts the u2f authentication, it sends: byte SSH_MSG_USERAUTH_REQUEST stringuser name in ISO-10646 UTF-8 encoding [RFC3629] stringservice name in US-ASCII stringmethod name in US-ASCII uint32U2F mode (authentication or registration) 1) In case the client requests registration, the server replies with: byte SSH2_MSG_USERAUTH_INFO_REQUEST stringRegisterRequest Where RegisterRequest is specified in http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-registerrequest-members After sending 'RegisterRequest' to the U2F security key, the client sends back the security key’s response (see http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-registerresponse-members): byte SSH2_MSG_USERAUTH_INFO_RESPONSE stringRegisterResponse Once the server verified the 'RegisterResponse' indeed signed the original challenge, it extracts the user’s U2F public key and sends back a ssh-u2f key line which the user should add to her authorized_keys file: byte SSH2_MSG_USERAUTH_INFO_REQUEST stringauthorizedKey 2) In case the client requests authentication, the server replies with: byte SSH2_MSG_USERAUTH_INFO_REQUEST stringSignRequest After sending 'SignRequest' (see http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-signrequest-members) to the U2F security key, the client sends back the security key’s response: byte SSH2_MSG_USERAUTH_INFO_RESPONSE stringSignResponse The authentication is successful if the server successfully verifies that the signature on the 'SignResponse' was created with the formerly registered public key. As you can see, the protocol on the wire is fairly simple — I just follow the JavaScript API because that is what libu2f-host expects. Hope that helps, let me know if you have more questions. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Michael Stapelberg michael+mind...@stapelberg.de changed: What|Removed |Added Attachment #2511|0 |1 is obsolete|| Attachment #2512|0 |1 is obsolete|| --- Comment #4 from Michael Stapelberg michael+mind...@stapelberg.de --- Created attachment 2521 -- https://bugzilla.mindrot.org/attachment.cgi?id=2521action=edit Updated version of the patch (considered merge-worthy from my POV) -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Damien Miller d...@mindrot.org changed: What|Removed |Added CC||d...@mindrot.org --- Comment #2 from Damien Miller d...@mindrot.org --- I think it is best that you start with a description of the u2f authentication method protocol - it's much better to review that the protocol is sound before looking at the implementation. Could you write this up? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 --- Comment #1 from Michael Stapelberg michael+mind...@stapelberg.de --- Created attachment 2512 -- https://bugzilla.mindrot.org/attachment.cgi?id=2512action=edit patch 2/2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs