[Bug 2319] [PATCH REVIEW] U2F authentication

2019-10-31 Thread bugzilla-daemon
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

2019-04-06 Thread bugzilla-daemon
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

2019-02-01 Thread bugzilla-daemon
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

2018-12-10 Thread bugzilla-daemon
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

2018-05-03 Thread bugzilla-daemon
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

2018-04-08 Thread bugzilla-daemon
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

2018-03-25 Thread bugzilla-daemon
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

2018-03-05 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Thomas Jarosch  changed:

   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

2018-02-02 Thread bugzilla-daemon
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

2017-11-14 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Torbjörn Lönnemark  changed:

   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

2017-09-22 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

David Lang  changed:

   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

2017-09-14 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

rickard.von.es...@gmail.com  changed:

   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

2017-04-18 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Mike Frysinger  changed:

   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

2017-02-22 Thread bugzilla-daemon
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

2017-01-08 Thread bugzilla-daemon
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

2017-01-05 Thread bugzilla-daemon
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

2016-12-29 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Fernando Herrera  changed:

   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

2016-10-27 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Fabian Peter Hammerle  changed:

   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

2016-05-03 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Vincent Brillault  changed:

   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

2016-01-19 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jakub Jelen  changed:

   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

2016-01-19 Thread bugzilla-daemon
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

2016-01-18 Thread bugzilla-daemon
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

2016-01-18 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Adam Goode  changed:

   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

2016-01-13 Thread bugzilla-daemon
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

2016-01-07 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Les Aker  changed:

   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

2016-01-01 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Georg Sauthoff  changed:

   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

2015-12-10 Thread bugzilla-daemon
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

2015-11-30 Thread bugzilla-daemon
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

2015-11-28 Thread bugzilla-daemon
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

2015-11-24 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Adam Goode  changed:

   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

2015-09-21 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Troy Ready  changed:

   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

2015-09-17 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jakub Jelen  changed:

   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

2015-09-04 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Tobias Florek  changed:

   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

2015-06-28 Thread bugzilla-daemon
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

2015-06-26 Thread bugzilla-daemon
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

2015-06-22 Thread bugzilla-daemon
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

2015-06-22 Thread bugzilla-daemon
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

2015-05-16 Thread bugzilla-daemon
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

2015-02-27 Thread bugzilla-daemon
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

2015-02-19 Thread bugzilla-daemon
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

2015-01-25 Thread bugzilla-daemon
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

2015-01-24 Thread bugzilla-daemon
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

2015-01-23 Thread bugzilla-daemon
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

2015-01-20 Thread bugzilla-daemon
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

2015-01-08 Thread bugzilla-daemon
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

2014-12-24 Thread bugzilla-daemon
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

2014-12-10 Thread bugzilla-daemon
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

2014-11-18 Thread bugzilla-daemon
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