Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)

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

>Section 1.2, paragraph 2 -- "the identities are hidden from eavesdroppers".  Is it worth noting that a man-in-the-middle could intrusively discover the initiator's identity?

Added: (A man-in-the-middle who cannot complete the IKE_AUTH exchange can nonetheless see the identity of the initiator.)

>Section 1.3.1 -- "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.

Opening a new issue about this.

>Section 1.3.2 -- "New initiator and responder SPIs are supplied in the SPI fields of the SA payload."  I think we should change this to read "A new initiator SPI is supplied ..."  Perhaps we should add something about the responder choosing an SPI to the paragraph beginning "The responder replies ..."

In 1.3.2, changed "New initiator and responder SPIs are supplied in the SPI fields of the SA payload." to "A new initiator SPI is supplied in the SPI field of the SA payload." Also added "A new responder SPI is supplied in the SPI field of the SA payload." a few paragraphs down.

>Section 2.8 -- Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one."  This sentence appears within a paragraph that is otherwise entirely about rekeying IKE SAs.  I think it should probably be moved to the end of the preceding paragraph.

Good catch.

>Section 2.21.2 -- We need to remember to remove the "NOTE FOR WG DISCUSSION".

Done.

--Paul Hoffman, Director
--VPN Consortium