Tero:
> same IP address. The initiator begins negotiation of a CHILD_SA
> using the SAi2 payload. The final fields (starting with SAi2) are
> described in the description of the CREATE_CHILD_SA exchange.
>
> <-- HDR, SK {IDr, [CERT,] AUTH,
> SAr2, TSi, TSr}
>
> The responder asserts its identity with the IDr payload, optionally
> sends one or more certificates (again with the certificate containing
> the public key used to verify AUTH listed first), authenticates its
> identity and protects the integrity of the second message with the
> AUTH payload, and completes negotiation of a CHILD_SA with the
> additional fields described below in the CREATE_CHILD_SA exchange.
>
> The recipients of messages 3 and 4 MUST verify that all signatures
> and MACs are computed correctly and that the names in the ID payloads
> correspond to the keys used to generate the AUTH payload.
>
> {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
> fails for some reason, the IKE_SA is still created as usual. The
> list of responses in the IKE_AUTH exchange that do not prevent an
> IKE_SA from being set up include at least the following:
> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
> INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
In the case of the that kind of failure the return packet will then be
without the SAr2, Tsi, and TSr, i.e.:
<-- HDR, SK {IDr, [CERT,] AUTH,
N(error_for_child_sa)}
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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
