openssh bugs - Nov 2014 - [Bug 2319] New: [PATCH REVIEW] U2F authentication

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

            Bug ID: 2319
           Summary: [PATCH REVIEW] U2F authentication
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: michael+mindrot at stapelberg.de

Created attachment 2511
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2511&action=edit
patch 1/2

I?ve been told to file a ticket here in order to get a response to the
patch I posted to openssh-unix-dev. Here is what I originally wrote to
the list:

"""
Recently, the FIDO alliance announced U2F [1], and Google announced
that it supports U2F tokens (?security keys?) for Google accounts [2].
As the spec is not a very short read, I gave a presentation last week
about U2F which may be a good quick introduction to the details [3].
For the rest of this mail, I?ll assume that you read either my
presentation or the spec, but feel free to post any questions about
U2F and I?ll try to answer them. (side note: I?m not working on U2F,
playing around with it and implementing it in OpenSSH is my private
fun project :))

I?ve spent some time (together with Christian and Thomas) hacking on
U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s
not complete, but it should be good enough to get the discussion going
:). Please see the two attached files for the patch. Due to their
size, I?ve not posted them in-line.

The way it currently (!) works:

1) Use ?AuthenticationMethods publickey,u2f? in sshd_config (or
<whatever>,u2f)
2) Recompile SSH with the patch and change userauth_u2f() to use
packet_put_int(0) (== registration) instead of packet_put_int(1)
(=authentication). Sorry about that. See my question below.
3) You need to do this step only once: ssh into your server, touch
your security key when prompted, and you?ll see a ssh-u2f key line,
which you should copy&paste into the server?s ~/.ssh/authorized_keys
for the corresponding user.
4) Recompile with packet_put_int(1).
5) ssh into your server, touch your security key when prompted, enjoy
the additional security :).

There are a couple of open questions:

1) Will you accept this patch (let?s ignore details for now) at all?
Everyone I?ve talked to in the last couple of days was pretty excited
about having U2F support in OpenSSH, so I think it?d be a great
feature.

(the rest are detail questions about the implementation)

2) Could we make the server write to authorized_keys to avoid the
copy&paste step? Probably not a good idea, but I figured I?d ask
anyway.

3) What would be a good way to trigger the different U2F modes on the
client? Should we add a new flag to ssh(1)? Registration is very
rarely triggered, authentication should be the default.

4) What should we use as U2F appid? Currently I just set
?ssh://localhost? (it must be a URL), and we could use
?ssh://<hostname>?. Christian suggested using the host key
fingerprint, which would decouple the appid from the hostname (which
may be good if the hostname frequently changes, because U2F security
keys are registered for a specific appid).

5) What should we use as the origin (in the ssh client)? In the case
where U2F is used by a web browser, this is set to the canonical
representation of the domain (i.e. lowercased, after idn etc.). At the
moment, I?m using either the host alias or the hostname. Is that
acceptable or is there a better method?

6) Not a question, but a note: the patch does not yet handle multiple
registered U2F security keys.

7) I?d like to use SSL_load_error_strings() so that the human-readable
error messages actually contain some content and are not just NULL :).
It?ll require linking with -lssl. Is that okay or is there a reason
why we don?t do it so far?

Thank you very much for any replies :).

[1] https://fidoalliance.org/
[2]
http://googleonlinesecurity.blogspot.ch/2014/10/strengthening-2-step-verification-with.html
[3] https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf
"""

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #1 from Michael Stapelberg <michael+mindrot at stapelberg.de>
---
Created attachment 2512
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2512&action=edit
patch 2/2

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #3 from Michael Stapelberg <michael+mindrot at stapelberg.de>
---
(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 :).

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Michael Stapelberg <michael+mindrot at stapelberg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2511|0                           |1
        is obsolete|                            |
   Attachment #2512|0                           |1
        is obsolete|                            |

--- Comment #4 from Michael Stapelberg <michael+mindrot at stapelberg.de>
---
Created attachment 2521
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2521&action=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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
(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.

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jean-Philippe Ouellet <jpo at vt.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jpo at vt.edu

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #6 from Michael Stapelberg <michael+mindrot at 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
   string    user name in ISO-10646 UTF-8 encoding [RFC3629]
   string    service name in US-ASCII
   string    method name in US-ASCII
   uint32    U2F mode (authentication or registration)

1) In case the client requests registration, the server replies with:

   byte      SSH2_MSG_USERAUTH_INFO_REQUEST
   string    RegisterRequest

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
   string    RegisterResponse

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
   string    authorizedKey

2) In case the client requests authentication, the server replies with:

   byte      SSH2_MSG_USERAUTH_INFO_REQUEST
   string    SignRequest

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
   string    SignResponse

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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

r04r <mindrot at minichan.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Simon Josefsson <simon at josefsson.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon at josefsson.org

--- Comment #7 from Simon Josefsson <simon at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #8 from Michael Stapelberg <michael+mindrot at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #9 from Simon Josefsson <simon at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Matt Johnston <matt at ucc.asn.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matt at ucc.asn.au

--- Comment #10 from Matt Johnston <matt at 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
      string    session identifier
      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "u2f"

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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Han-Wen Nienhuys <hanwenn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hanwenn at gmail.com

--- Comment #11 from Han-Wen Nienhuys <hanwenn at 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 XXXX >> .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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Mantas M. <grawity at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grawity at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Peter Moody <mindrot at hda3.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

maze+bugzilla-mindrot-org at strahlungsfrei.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maze+bugzilla-mindrot-org at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

semenko <nick at semenkovich.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

mike at mikedoherty.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Tobias Florek <mindrot at ibotty.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at ibotty.net

--- Comment #12 from Tobias Florek <mindrot at ibotty.net> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #13 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 2710
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2710&action=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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Troy Ready <troy at troyready.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |troy at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Adam Goode <adam at spicenitz.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adam at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #14 from Adam Goode <adam at spicenitz.org> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #15 from Simon Josefsson <simon at josefsson.org> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

wiktor at metacode.biz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wiktor at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Georg Sauthoff <mindrot at georg.so> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Les Aker <me at lesaker.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

bugmenot at mailinator.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugmenot at mailinator.com

--- Comment #16 from bugmenot at 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 XXXX >>
> .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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

mmotz at e-motz.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmotz at e-motz.com

--- Comment #17 from mmotz at 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 at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Adam Goode <adam at spicenitz.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|adam at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2710|0                           |1
        is obsolete|                            |

--- Comment #18 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 2782
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2782&action=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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #19 from mmotz at 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 at host:~$  ssh -o U2FMode=registration vpn > /tmp/u2f-key.pub
sign_and_send_pubkey: signing failed: unexpected internal error
qr at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Stefean B?hler <mindrot at stbuehler.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at stbuehler.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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Vincent Brillault <git at lerya.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |git at lerya.net

--- Comment #20 from Vincent Brillault <git at lerya.net> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Aleksander Adamowski <olo at fb.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olo at fb.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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Christian Svensson <mindrot at cmd.nu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at cmd.nu

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Fabian Peter Hammerle <fabian.hammerle at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fabian.hammerle at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Fernando Herrera <fherrera at onirica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fherrera at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #21 from Damien Miller <djm at mindrot.org> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #22 from Simon Josefsson <simon at josefsson.org>
---
> 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Mike Rostermund <mike at kollegienet.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike at kollegienet.dk

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

sami.losoi at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sami.losoi at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Mike Frysinger <vapier at gentoo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vapier at gentoo.org

--- Comment #23 from Mike Frysinger <vapier at gentoo.org> ---
(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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

rickard.von.essen at gmail.com <rickard.von.essen at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rickard.von.essen at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

David Lang <david at lang.hm> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at lang.hm

--- Comment #24 from David Lang <david at lang.hm> ---
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Torbj?rn L?nnemark <tobbez at ryara.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobbez at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

jordandev678 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jordandev678 at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Thomas Jarosch <thomas.jarosch at intra2net.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.jarosch at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

bugzillamindrotorg at unrelated.net.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzillamindrotorg at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

daniel at lbe.rs changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

mdaniels5757 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mdaniels5757 at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

labor4 <schreibtisch at labor4.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schreibtisch at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Jon Gjengset <jon at thesquareplanet.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jon at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #25 from jordandev678 at 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 2222 -o PreferredAuthentications=u2f,password jordan at 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 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.
That's technically correct - but SSH has no suitable replacement for
the 'relying party ID' (RPID) in U2F. I'm kicking around the idea of
using host keys as the RPID for but that has a few serious issues too.

I would point out though that the stated scenario only avoids this
issue by having the user manually select the key for each connection.
When an agent is involved standard SSH publickeys are just as
susceptible to this. The standard SSH agent doesn't lock keys to hosts
and just iterates though keys until one works. All we're doing here is
replacing the software SSH-agent with a more secure hardware agent. In
short - SSH already suffers from this, it's not just a U2F thing.

So with that in mind what I'd like to get nailed down though to guide
said development is if people (OpenSSH) would consider this type of
issue blocking for this considering the above and:
i) It requires B to get the list of keys for the user on A - which
requires B to have cracked the first factor (password) for the user on
A to get sent the list. Or both hosts are hostile to you and root on A
is sharing your keys behind the scenes with B.
ii) It requires the user to accept the host key of an actively hostile
host, if not two.
iii) The user has to expect to find U2F on the hostile host - if they
didn?t expect it then they wouldn?t touch the U2F key when prompted and
never confirm they hold it.


4) I'm not familiar enough with U2F to review it.

Perhaps if we can get one of the Yubico people or some other
appropriate entity to attest this is a reasonable implementation within
the constraints of SSH? If we could get this to a state where you guys
(OpenSSH) are happy with the status of what is here pending approval of
some appropriate entity of the U2F specifics that would probably be
easier to swing. Is that a reasonable approach from your perspective?

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2319

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #26 from Damien Miller <djm at mindrot.org> ---
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.