Hi Pasi, Tero's mail gives a clearer explanation of the situation than your proposed text. Gluing the two together, how about replacing your last paragraph with:
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the
IKE_AUTH messages are encrypted and integrity protected, if the peer
receiving this notification has not authenticated the other end yet (or if
the peer fails to authenticate the other end for some reason), the
information needs to be treated with caution. More precisely, (assuming that
the MAC verifies correctly) the sender of the error indication is known to
be the responder of the IKE_SA_INIT exchange, but the sender's identity
cannot be assured.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> pasi.ero...@nokia.com
> Sent: Monday, May 04, 2009 15:09
> To: kivi...@iki.fi; ipsec@ietf.org
> Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA
> fails
>
> Tero,
>
> What do you think of the proposed text here?
>
> http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> > Of ext Yaron Sheffer
> > Sent: 03 May, 2009 23:37
> > To: IPsecme WG
> > Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails
> >
> > 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.
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
