IKEv2bis: some open issues

1
IKEv2bis some open issues

• Paul Hoffman, VPN Consortium

2
Guidelines for this document

• No technical changes to IKEv2 unless there is
  very careful and very explicit agreement
• In cases of ambiguity, try to determine what
  would have made sense if we got it right the
  first time
• Get lots of input from developers

3
Anticipated next steps

• Discuss on list
• Put out a -02 by mid-December
• Try to knock off even more issues

4
Issues of the day

• Well get through as many as we can
• Behavior when KE payload not included
• Exchange type for INVALID_IKE_SPI outside of an
  IKE_SA
• Notification when creation of CHILD_SA fails
• Original initiator and rekeying
• Add section on simultaneous IKE SA rekey
• Floating to port 4500 'by default', and use of
  UDP when no NAT detected
• Address and config values lifetime
• Conflicts in DH proposals
• Exponential reuse reference

• Pipelining interop between supporting and
  non-supporting peers
• Interaction of IKE_SA_INIT retransmissions with
  specific notifies
• Motivation for including SPIs in the cookie
• Checking of the other peer's IKE SPI
• Clarify which traffic selectors to use in
  rekeying
• Traffic selectors when rekeying vs. the packet
  that triggered the rekeying
• Choice of the right TS when narrowing

5
50 Behavior when KE payload not included

• 1.3.2 why is KE a SHOULD, not a MUST? How is the
  SA generated if it is omitted?

6
46 Exchange type for INVALID_IKE_SPI outside of
an IKE_SA

• For the one-way INVALID_IKE_SPI notification
  described in RFC 4306 section 1.5, it is unclear
  to me what the Exchange Type should be in the IKE
  header.  Should it be 37 (INFORMATIONAL) or
  should it be copied from the request that
  contained the unrecognized SPI?
• More in the issue tracker

7
9 Notification when creation of CHILD_SA fails

• 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
• 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.

8
65 Original initiator and rekeying

• Tero says the actual text in 4306 and
  clarifications does not exactly specify when the
  message ids are reset and when the roles are
  changed. For me it was clear that of course the
  old IKE SA uses the old roles and old message IDs
  as otherwise it could not work at all, and the
  new IKE SA created by rekeying IKE SA will use
  the new message ID starting from 0, and new roles
  of the original initiator and responder (i.e. the
  Initiator flag in the header).

9
22 Add section on simultaneous IKE SA rekey

• There should be section of simultaneous IKE SA
  rekeying. The simultaneous IKE SA rekeying is
  much more important case to get correct, as both
  ends MUST agree on which IKE SA survive, as
  otherwise they will move the CHILD SA to wrong
  IKE SA and their state is completely messed up
  after that.
• What should happen if the simultaneous rekeying
  of IKE SA is noticed only AFTER the whole
  rekeying is already finished.

10
40 Floating to port 4500 'by default', and use
of UDP when no NAT detected

• Clarif-7.6 An IPsec endpoint that discovers
  a NAT between it and its correspondent MUST send
  all subsequent traffic from port 4500, which NATs
  should not treat specially (as they might with
  port 500).
• We should also list whether it is allowed to
  float to port 4500 even when no NAT is detected
  (I think the answer is yes). And even if we float
  to port 4500, the UDP encapsulation should not be
  enabled or expected unless NAT between is really
  detected.

11
56 Address and config values lifetime

• 2.19 INTERNAL_ADDRESS_EXPIRY is gone, but
  shouldn't we specify what the gateway should do
  if the address lease expires? On a related note,
  the section does not specify the lifetime of the
  configuration values, i.e. should they be renewed
  by the next IKE SA rekey, or reauthentication, or
  never?

12
30 Conflicts in DH proposals

• Section 3.3.6. Attribute Negotiation
• Must all of the offered proposals have identical
  Diffie-Hellman group lists? What does it mean if
  one of the proposals have different list than
  some other proposal? Can the KE payload include
  then be from such group that only exists in one
  of the lists? Also do the Diffie-Hellman groups
  need to be repeated on every single proposal?

13
55 Exponential reuse - reference

• In 2.12 Can we give a reference on how to do
  exponential reuse securely?

14
52 Pipelining interop between supporting and
non-supporting peers

• 2.3 The first paragraph contains an apparent
  contradiction. It mentions that pipelining is
  done 'if the other endpoint has indicated its
  ability to handle such requests' and then goes on
  to describe how a pipelining implementation can
  interoperate with a non-pipelining one.

15
36 Interaction of IKE_SA_INIT retransmissions
with specific notifies

• Current When a responder receives an IKE_SA_INIT
  request, it has to determine whether the packet
  is retransmission belonging to an existing
  'half-open' IKE_SA (in which case the responder
  retransmits the same response), ...
• Propose to add ... or it belongs to an existing
  IKE_SA where the IKE_AUTH request has been
  already received (in which case the responder
  ignores it), or it is INVALID_KE_PAYLOAD or
  COOKIE notify responses to the IKE_SA_INIT
  request.

16
19 Motivation for including SPIs in the cookie

• Material to add The real reason to hash the SPIs
  to the cookie is to make sure that attacker
  cannot fetch one one cookie from the other end,
  and then initiate 100 IKE_SA_INIT exchanges all
  with different initiator SPIs (and perhaps port
  numbers) so that the for the responder it looked
  like there is lots of machines behind one NAT box
  who are all trying to connect. As the cookie is
  tied to the SPIi the attacker cannot use cookie
  multiple times.

17
17 Checking of the other peer's IKE SPI

• Tero Our implementation originally only checked
  its own SPI half, and didn't verify that the
  other ends SPI half didn't change. We fixed it to
  check the other ends SPI also, but I wonder
  should we say one way or the other here? Also
  what SPI should the response have, i.e. the SPIs
  from the request, or the SPIs from the original
  IKE SA creation.

18
11 Clarify which traffic selectors to use in
rekeying

• Proposed addition When doing rekeying, the
  traffic selectors SHOULD come from the original
  decorrelated policy, i.e. not the same traffic
  selectors which the old SA had in case the
  responder narrowed them, but from the policy
  which initiator used originally to create the
  IPsec SA. This allows the SA to expand to full
  traffic selector set allowed by latest (perhaps
  changed) policy.

19
12 Traffic selectors when rekeying vs. the
packet that triggered the rekeying

• To allow responder to do intelligent narrowing of
  the traffic selector the responder should know
  which packet triggered the rekeying, so it will
  not narrow the traffic selectors to set which is
  not usable for the packet triggering the
  rekeying. This means that even the traffic
  selectors for the rekeying needs to have those
  selectors from the packet (see section 2.9).

20
25 Choice of the right TS when narrowing

• Spec When narrowing is done, there may be
  several subsets that are acceptable but their
  union is not. In this case, the responder
  arbitrarily chooses one of them, and MAY include
  an
• Tero I do not think the responder can
  arbitrarily choose one of them, it MUST select
  the one that includes the first TS if it was
  acceptable.
• Paul technical change