Yaron Sheffer writes:
> If the authentication fails in such ways that the entries cannot
> create IKE SA (authentication failure or similar), then the response
> will be unencrypted, unauthenticated notify. There is no point of
> sending the notify encrypted and integrity protected, as it is not
> authenticated (as initiator and responder have not yet verified the
> AUTH payloads):
>
> <-- HDR, N(error_for_ike_sa)
>
> The initiator receiving such reply MUST NOT immediately stop the SA
> creation, but it should still retransmit the message few times, in
> case that error notify was forgery and the real responder will reply
> with valid reply. It can use the recipient of such message as a hint
> to tell that authentication failed, thus it can shorten the
> retransmission timers from few minutes down to few tens of seconds.
>
> Paul:
>
> The first part (don't nuke the IKE SA) is resolved, but the second part
> (should the error message be encrypted) is still an open issue.
>
> Yaron:
>
> And then we had a long discussion (see e.g.
> http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was
> never resolved.
I think I have now changed my mind about this issue, meaning I think
the reply should be encrypted and MAC'ed but it should still be
clearly specified that it is unauthenticated, as we have not yet
verified the identity of the other end. Having the message encrypted
and MAC'ed proofs that the entity who sent us the IKE_SA_INIT is also
responsible for this IKE_AUTH error, which means there is no point of
retransmitting our request anymore, as only the party participating
the Diffie-Hellman could have generated the error.
I.e. when error of type:
<--- HDR, SK { N(error_for_ike_sa) }
is received we can consider that IKE SA connection as failed, and
delete the IKE SA immediately, but we should not consider that error
as permanent error from that node, as man in the middle attacker could
have generated such error instead of the intended party.
After receiving such error initiator MAY restart IKE SA creation from
the beginning few times before completely failing the IKE SA creation.
This is related to the section 2.4 3rd last paragraph which explains
how initiator can protect himself against this kind of poison the
connection setup attempt. I.e. if IKE SA negotiation failed then
initiator should perhaps consider there might be man-in-the-middle and
enable that protocol described there, i.e. process multiple
IKE_SA_INIT replies, and continue them in paralleal and then pick the
one which succeeds and fail the others.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
