On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko wrote:
> Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
>
>
>
> On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko wrote:
>
> Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
>
> Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
>
>
>
> On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko wrote:
>
> Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
>
>
>
> On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote:
>
> Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
>
>
>
> On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote:
>
> Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
>
>
>
>
> it cannot establish partially where one side trusts (authenticates) and
> other does not.
>
>
> You can very much establish a TLS session where one side authenticates by
> the certificate presented but the other side does not.
>
> Not if you mandate mutual TLS auth (request cert)
>
>
> "Mutual authentication" means both sides authenticating the other in the
> same action. Here, both sides can authenticate the other, but need not.
> Either side is entirely free to ignore the certificate for any number of
> reasons. (The confusion arises because all SASL mechanisms that support
> server authentication are by definition mutual authentication).
>
> Yes, this is exactly the point. But not only that, by mandating SASL
> external over TLS you also mandate TLS mutual authentication (which happens
> within the same protected channel).
>
>
>
> Ah, no. Because SASL EXTERNAL isn't an authentication at all, there's no
> implication of mutual authentication (and often isn't any bidirectional
> either).
>
> Maybe I'm not aware of other uses of EXTERNAL auth but when I wanted to
> implement EXTERNAL support in XMPP to advertise it in mechanisms and expect
> interoperability with other client/servers I need to request client
> certificate (set_verify_mode VERIFY_PEER) and then validate received
> certificate. If that is not mutual TLS auth then I'm not sure what that is.
>
>
> It's client authentication.
>
>
> Also. Server authentication + client authentication = Mutual
> Authentication.
>
>
>
> Normally, "mutual authentication" means both sides have assured that the
> other is authenticated *and* has authenticated them. For example, SCRAM and
> DIGEST both have the server provide proof that the server also knows the
> secret used by the client. That's not the case with TLS's use of X.509 -
> each authentication is unidirectional and independent.
>
> It is not, both sides need to have private key in order to complete
> identification, and client certificate authentication is executed within
> server's security context (RFC 5246 7.4.4 Note: It is a fatal
> handshake_failure alert for an anonymous server to request client
> authentication).
>
> You cannot just pick random public key (certificate) and offer it in TLS
> CertificateRequest message because there is CertificateVerify message which
> requires you to have access to the private key whith which you need to sign
> entire handshake (security context). It *is* TLS authentication.
>
> But yes, you can set a policy where you accept any security context from
> the server (pseudo-anonymous) and authentication only client. Or you can
> skip CertificateRequest (default state) and authenticate only server. But
> when you do RequestCertificate and do VERIFY_PEER (in whatever way you
> like) - you are actually doing mutual TLS authentication.
>
> I will stop commenting this though, I don't know why are we spending time
> arguing about such an obvious thing. Do you want to highlight that
> somewhere in some standards this is called out differently? By all means.
> dixi.
>
> Client authentication can occur with, or without, server authentication.
> Client authentication can occur with SASL EXTERNAL. Or it can occur without
> it. Or SASL EXTERNAL can - in rare cases - be offered where TLS client
> authentication hasn't occurred at all. In other words, the offering of
> EXTERNAL - while it should only be offered when the server expects the
> client will be able to successfully use EXTERNAL - doesn't mean anything in
> security terms, and nor does the client using (or not) EXTERNAL.
>
> VERIFY_PEER will verify the certificate (establish whether it has a
> trusted path), but you could also verify it as the same certificate used in
> previous sessions, or as a method to increase security of dialback if you
> wanted. Depending on your views of how secure CAs are, this might be
> preferable.
>
>
> That is again policy decision, which I also don't want to discus it in
> this context as it's already hard to track this discussion.
>
> X509 based TLS is Server Auth. VERIFY_PEER requests Client Auth - both
> together are mutual x509 TLS Auth.
>
>
>
> But - ignoring whether VERIFY_PEER actually authenticates or not - that's
> not really the case, since Alice might ignore Bob