Subject: Re: [IPsec] Mutual authnull to mutual authenticated upgrade

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 1 Aug 2018 14:54:44 +0300

Hi,

sorry for late reply.

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

I still believe that sending additional AUTH information in N(AUTHNULL) (as well as in N(NO_PPK_AUTH))
is a protocol hack. The proper way is to add a generic mechanism that would allow
peers to announce authentication algorithms they support. Note that no negotiation is needed - 
it is sufficient to announce a list of auth methods, as it is currently takes place with hash functions.
The N(NO_PPK_AUTH) is a bit different, since it is not a new authentication method, it is a modification
of existing methods, so the hack in this case is forgivable :-)

That said, I agree with Tero that if you allow AUTH_NULL, then announcing in addition any other 
(real) auth methods can be done on attacker's mercy only, as she can always remove them 
and downgrade IKE SA to AUTH_NULL.

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

I believe such use cases do have a right to exist.

Regards,
Valery.

> Paul and Vukasin