Paul Wouters writes:
> 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
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
start requiring authentication like you have in your case 5 below:
> 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.
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 }
> 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)
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 protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
