Subject: [IPsec] #127: Should IKE_AUTH errors be encrypted?

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2009 15:46:23 -0800

Section 1.3.1 says "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message."  First, this seems out of place, since this section talks about CREATE_CHILD_SA for Child SAs.  Second, assuming this is talking about IKE_AUTH, I think this contradicts what we'd earlier agreed to -- and what section 1.2 now seems to suggest -- in that the IKE_AUTH response should normally be encrypted and MACed even on failure.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Dec 2009 12:13:03 -0800

>Section 1.3.1 says "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message."  First, this seems out of…

Also note that the text in 2.21.2 (which has been mostly unchanged during the editing process) strongly indicates that the error is sent encrypted.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Dec 2009 14:35:56 +0200

Paul Hoffman writes:
> Section 1.3.1 says "When an IKE SA is not created, the error message
> return SHOULD NOT be encrypted because the other party will not be
> able to authenticate that message."  First, this seems out of place,
> since this section talks about CREATE_CHILD_SA for Child SAs.
> Second, assuming this is talking about IKE_AUTH, I think this
> contradicts what we'd earlier agreed to -- and what section 1.2 now
> seems to suggest -- in that the IKE_AUTH response should normally be
> encrypted and MACed even on failure. 

We already decided when handing ticket 9
(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/9) that the reply
message should be encrypted.

The text to 1.3.1 was changed in -03 version (Feb 26 2009), and that
ticket 9 was opened by my
http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html
message much earlier and ticket 9 was closed after this change in
1.3.1 was added, so the text in the 1.3.1 was not just updated to
reflect the change done because of ticket 9.

I think it is ok to just update the 1.3.1 to match the section 1.2 and
ticket 9 solution.
-- 
[email-masked]