Hi Prashant, As per RFC 5996, Initiator sending AUTHENTICATION_FAILED would be sufficient in case of peer's authentication failure:
Sec. 2.21.2 Error Handling in IKE_AUTH ... If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses. ... In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a Delete payload. ... Regards, Raj On Wed, Apr 27, 2011 at 7:09 PM, Prashant Batra (prbatra) <prba...@cisco.com > wrote: > Thanks Scott, > > > > I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so > as to ensure that the peer deletes the ipsec tunnel from the SADB (as it > would have already added the tunnel in SADB, after sending the > AUTH_RESPONSE). > > But, to second you, most implementations would delete the same on receiving > AUTHENTICATION FAILED alone. > > > > Regards, > > Prashant > > > > > > *From:* Scott C Moonen [mailto:smoo...@us.ibm.com] > *Sent:* Wednesday, April 27, 2011 5:54 PM > *To:* Prashant Batra (prbatra) > *Cc:* ipsec@ietf.org; ipsec-boun...@ietf.org > *Subject:* Re: [IPsec] Query regarding IKE_SA_AUTH response > > > > Hi Prashant. > > > 1) If in IKE_AUTH request message initiator sends a ID_R > > payload(optional) specifying a particular peer identity, and the > > responder > > sends some different identity in the ID_R payload, what should be the > > behavior? Should we send a AUTHENTICATION failure message, > > or except this new identity of the peer and mark the SA established, if > > the other things are fine. > > This is an implementation decision. In general, you should not > automatically reject the negotiation because the optional IDr is intended > only as a hint. Instead, you should (1) check whether your peer > authorization database (PAD) allows you to converse with the new identity at > the given IP address and to protect the given traffic, and (2) be sure to > verify that any earlier decisions, such as the use of a particular > pre-shared key or the choice of IKE SA cryptographic algorithms, are still > correct given that you are talking to a different identity than you first > suspected. > > > 2) If we were to send a AUTHENTICATION failure, then this should be sent > > as a INFORMATIONAL exchange message (as the message received > > is a response and not request). What should be the message Id used? > > Yes, if you were to determine that the peer identity is not permitted by > your PAD, then you would initiate a new informational exchange on the IKE > SA. Since the IKE_AUTH exchange has a message id of 1, this exchange would > have a message id of 2. My own preference would be to send both an > AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for > maximum clarity. But I think that sending only AUTHENTICATION_FAILED is > sufficient and would be the preference of others on this list. > > > Scott Moonen (smoo...@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > [image: Inactive hide details for "Prashant Batra (prbatra)" ---04/27/2011 > 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,]"Prashant Batra > (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2, > > From: "Prashant Batra (prbatra)" <prba...@cisco.com> > To: <ipsec@ietf.org> > Date: 04/27/2011 08:06 AM > Subject: [IPsec] Query regarding IKE_SA_AUTH response > Sent by: ipsec-boun...@ietf.org > ------------------------------ > > > > > Hi, > > I have 2 doubts regarding IKEv2, > > 1) If in IKE_AUTH request message initiator sends a ID_R > payload(optional) specifying a particular peer identity, and the > responder > sends some different identity in the ID_R payload, what should be the > behavior? Should we send a AUTHENTICATION failure message, > or except this new identity of the peer and mark the SA established, if > the other things are fine. > > 2) If we were to send a AUTHENTICATION failure, then this should be sent > as a INFORMATIONAL exchange message (as the message received > is a response and not request). What should be the message Id used? > > Regards, > Prashant > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
