Subject: [IPsec] Mutual authnull to mutual authenticated upgrade

From: Paul Wouters <[email-masked]>
Date: Thu, 19 Jul 2018 10:27:11 -0400 (EDT)

We had to support the following deployment.

A large group of nodes is deployed with mutual authnull. This
offers passive attack protection on the network. At a later
stage, nodes are given their certificate for authentication.

The goal was to go from mutual authnull to mutual RSA. If either
node does not yet support authentication, both nodes use auth null.

So we have the following possibilities:

1) authby=authnull -> authby=authnull
2) authby=authnull,cert -> authby=authnull
3) authby=authnull,cert -> authby=authnull,cert  (must yield real authentication)
4) authby=authnull -> authby=authnull,cert

When all nodes have gotten a cert, you can remove authnull so end up with:

5) authby=cert -> authby=cert

1 and 5 are existing known working deployments.

2-4 have a scenario where you have to pick an IKE_AUTH method. Depending
on the responder you got it right or wrong. If wrong, you have to
restart IKE_INIT to try the other method. We wanted to do this IKE_AUTH
in 1 roundtrip without a restart of IKE_INIT.

Note all these scenarions yield a symmetric authentication. It will be
either authnull or mutual "real" authentication (eg RSA or DigitalSignature)

So what we ended up doing is similar to the NO_PPK_AUTH trick. We added
sending a notify N(AUTHNULL) (40960 private use number) to the IKE_AUTH
exchange on the initiator which is a notify containing an AUTH payload
using authnull. So this becomes:

request             --> IDi, [CERT+,]
                            [N(INITIAL_CONTACT),]
                            [N(AUTHNULL)]                     <----- New item
                            [[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
                            [IDr,]
                            AUTH,
                            [CP(CFG_REQUEST),]
                            [N(IPCOMP_SUPPORTED)+,]
                            [N(USE_TRANSPORT_MODE),]
                            [N(ESP_TFC_PADDING_NOT_SUPPORTED),]
                            [N(NON_FIRST_FRAGMENTS_ALSO),]
                            SA, TSi, TSr,
                            [V+][N+]

The IKE_AUTH response is unmodified.

If the responder supports this payload, AND local policy can do
authentication, it will ignore this payload and use the regular AUTH
payload. If it only has a configuration for authnull, it will use the
N(AUTHNULL) as the received AUTH payload instead or the actual AUTH
payload. The responder will send back only a real AUTH payload. If the
initiator had N(AUTHNULL) but the responder can do regular authentication,
it will just send back an real authentication AUTH payload. If the
responder can only do authnull, it will send an authnull based AUTH
payload. The responder never sends a N(AUTHNULL) payload as we did
not need/want to support asymmetrical authentication where one part
is authnull and the other is not, as we either have a CA+EE cert for
ourselves AND the peer, or we only have authnull for everything.

See our test cases:

http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-03-authanon-anon/
http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-02-anon-authanon/
http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-01-authanon-authanon/

My questions are:

1) Is this useful enough to write up as RFC ?
2) Are we correct with our assumption that you either end up on mutual
    authnull or with mutual authentication, or do people believe there
    is a use case for asymmetric authentication as well, in which case
    the responder could also send AUTH plus N(AUTHNULL)

Paul and Vukasin

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2018 18:55:18 +0300

> 4) authby=authnull -> authby=authnull,cert

Actually all of those (including the last one) are just authnull
always. If you do not require authentication then Man in the middle
attacker can just modify the exchange so that authnull is only one
offered.

I.e., the option 4 is still insecure until you go and change
configuration to 5. So the question there is if you do not care about
authentication you should just install certs everywhere, and then

> 1 and 5 are existing known working deployments.

And 2-4 are exactly same as 1 from security point of view.

> 1) Is this useful enough to write up as RFC ?

As all cases 2-4 are just authnull really, and do not offer anything
for security, I am not sure there is point of adding them as RFC.

Note, that you can already do this in standardized ways by using
multiple authentications RFC 4739. I.e., initially do normal authnull
and include MULTIPLE_AUTH_SUPPORTED in IKE_SA_INIT response and 1st
IKE_AUTH request. If both included it, then you know they have
certificates, thus you can do 2nd round of authentication by adding
ANOTHER_AUTH_FOLLOWS too to the 1st IKE_AUTH request.

Then you do 2nd IKE_AUTH exchange which does the certificate based
authentication.

This has exactly same (bad) security properties than what you are
doing, meaning man in the middle can still remove the payloads and
cause us fall back to authnull, but at least it uses already
specified protocol. 

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                              <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                           N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
      	      	   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
		   N(ANOTHER_AUTH_FOLLOWS) }  -->
			      <-- 4. HDR, SK { IDr, [CERT+], AUTH }
      5. HDR, SK { IDi, [CERT+], AUTH }  -->
                              <-- 6. HDR, SK { SA, TSi, TSr }

>     the responder could also send AUTH plus N(AUTHNULL)

Actually doesn't that automatically already happen with authnull? I
mean authentication can be asymmetric, i.e., one end can use
pre-shared keys and another certificates, and I think authnull also
allows that, i.e., responder can use certificates to authenticate
himself and initiator can use authnull. At least Introduction section
lists all those asymmetric cases as uses cases for NULL auth.

So I do not think you actually need to do MULTIPLE_AUTH_SUPPORTED or
hacks what you are doing.

Are the certificates signed by known trust anchor, and is that trust
anchor already configured in all nodes initially?

If so then asymmetric authentication should just work. I.e., in case 2
the initiator will authenticate himself with certificates, and
responder can verify that, but still use NULL auth himself. In case 4
it will be other way around.

On the other hand if you have not trust anchors installed and you need
to find that out during the handshake, you can use the fact whether
you get CERTREQs in the exchange to indicate that other end has proper
trust anchors installed, and if you do not get trust anchors mathing
your certificate from the other you use NULL auth, and if you do get
matching trust anchors and you have certificate, then you use
signatures.

Or am I missing something now?
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 19 Jul 2018 14:32:26 -0400 (EDT)

> attacker can just modify the exchange so that authnull is only one

You can prefer authentication over unauthenticated. You could do
different things. But yes, this is a migration path that mostly
avoids some kind of flag day or a rollout where one non-updated
node prevents all the network from using authenticated communication.

> And 2-4 are exactly same as 1 from security point of view.

No, a cert-cert connection is still proving there is no MITM :P

> Then you do 2nd IKE_AUTH exchange which does the certificate based

I guess we did not support that, but it is a fair point.

> lists all those asymmetric cases as uses cases for NULL auth.

That doesn't end up favouring authenticated over authnull. See above
disagreement that this matters :)

> anchor already configured in all nodes initially?

No. Some nodes still have no certificates whatsoever, and some nodes
have been updated to have certificates.

> matching trust anchors and you have certificate, then you use

Some implementations always send CERTREQs even if they only allow PSK,
in case the other end wants to use CERT based auth while this end
uses something else (eg psk or null)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Jul 2018 00:14:08 +0300

> disagreement that this matters :)

I think it does. See below

> have been updated to have certificates.

Ok.

> uses something else (eg psk or null)

So how does they manage to send CERTREQ having hash in them matching
your trust anchor, if they have not been configured with that trust
anchor?

If you have manually configured them to send CERTREQs with trust
anchor hashes you do not trust, then I think that is configuration
error and it must be fixed.

I.e. if you see CERTREQ which has hash matching the trust anchor that
signed your certificate, then you can quite safely assume that the
other end do support certificates, and has the required trust anchor
installed, so you can always use the certificate based authentication
yourself. This will cause you to favor certificate based
authentications over auth null if it is possible. 

If remote end sends empty CERTREQ, then fix the configuration in the
other end so it will include the hashes of the trust anchors instead.
It should be easier to do that, than to implement new protocol...
-- 
[email-masked]