[Bug 2663] New: [man] sshd_config(5) AuthenticationMethods segment clarification, proposal and questions

[bugzilla-daemon]

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

Bug ID: 2663
   Summary: [man] sshd_config(5) AuthenticationMethods segment
clarification, proposal and questions
   Product: Portable OpenSSH
   Version: 7.2p2
  Hardware: Other
OS: Linux
Status: NEW
  Keywords: low-hanging-fruit
  Severity: enhancement
  Priority: P5
 Component: sshd
  Assignee: unassigned-b...@mindrot.org
  Reporter: bg...@gmx-topmail.de

Segment's first paragraph reads:
AuthenticationMethods
... This option must be followed by one or more __comma-separated
lists__ of authentication method names. ...

Suggested change
... This option must be followed by one or more lists of
__comma-separated authentication method names__. ...

Rationale:
The current wording is misleading; not the lists are comma-separated,
but their elements; any pair of neighbouring lists is space-separated.
--

My approach was:
Taking the example of the second paragraph's first sentence (without
considering the subsequent explanation)
... “publickey,password publickey,keyboard-interactive” ...
the misleading statement about the list separator would have to yield
three authentication paths, either with:
   "publickey" or "password and publickey" or  "keyboard-interactive"
Testing a configuration with just "password,publickey" in an actual
sshd_config file made it apparent that a single list is at hand, as an
authentication only occurs if the password input can be augmented with
the retrieval of a keyfile (otherwise, the client reports
"Authenticated with partial success.").
--

And something else is at play:
AuthenticationMethods password publickey
AuthenticationMethods publickey password

Both fail to authenticate, if no publickey is present; apparently, the
first (and only) items of the 2 lists are brought into a default order
of "publickey password"; this cannot be inferred from invoking
sshd -T -f /etc/ssh/sshd_config
which seems to suggest that the order remains as originally set in
sshd_config.
Granted, single item lists do not warrant usage of
"AuthenticationMethods". But this fails as well:
AuthenticationMethods password publickey,password
(Again, a rather useless combination from a practical view)
The client specifically stating not to use public key auth remedies the
issue:
ssh user@host -o "PubkeyAuthentication no"
My suggestion for this would be to extend the manual section by a
sentence that states the order of precedence of authentication methods
within a given "stage".
--

For me, with regard to the manual segment of AuthenticationMethods, a
question remains with the term "stage" in paragraph 2, sentence 2:
Only methods that are next in one or more lists are offered at each
stage, ...
Is this supposed to say that, for example:
AuthenticationMethods password,publickey 
hostbased,keyboard-interactive
could result in a user being authenticated by "hostbased publickey"?

If so, then the last sentence of the section's paragraph 1:
Successful authentication requires completion of every method in at
least one of these lists.
would be incorrect in so far that - strictly speaking - none of the
given lists was completed, but a new one was assembled.

Thanks for any clarifications -  and maybe, this helps some other folks
when preparing and testing an sshd configuration.
--

Beyond this topic, is there a reason why only the first occurrence of
AuthenticationMethods is honored? As with HostKey, Port, ...,
reocurring keywords' values could be appended...

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

[Bug 2662] New: Does it still make sense to use DSA host keys by default?

[bugzilla-daemon]

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

Bug ID: 2662
   Summary: Does it still make sense to use DSA host keys by
default?
   Product: Portable OpenSSH
   Version: 7.4p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: sshd
  Assignee: unassigned-b...@mindrot.org
  Reporter: cjwat...@debian.org

Despite the fact that the client disables DSA support by default since
OpenSSH 7.0, the server still includes it in the implicit list of host
keys used if you don't specify any HostKey options at all (which is the
default behaviour in the stock sshd_config).  This seems a bit odd. 
Would you consider removing it from the list in
fill_default_server_options, thereby requiring people who really need
it to specify it manually?  That would seem to be useful in further
discouraging the use of DSA.

Background for why I'm asking: https://bugs.debian.org/823827 requested
something similar, which at the time I handled only in the Debian
packaging scripts.  Recently I switched to doing a better job of
upgrading server configuration files and using something much closer to
the stock upstream sshd_config, which has resulted in
https://bugs.debian.org/850614, so I'm considering patching this out of
fill_default_server_options given that the Debian packaging scripts
ensure that all necessary host keys are generated so something newer
should always be available; but it seems worth asking if you have
serious qualms about that approach.

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

[Bug 2319] [PATCH REVIEW] U2F authentication

[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