Subject: [IPsec] Comment on ikev2bis section 2.4

From: Keith Welter <[email-masked]>
Date: Thu, 25 Sep 2008 12:55:29 -0700

>From ikev2bis section 2.4:
   {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
   IKE_SA is the only IKE_SA currently active between the authenticated
   identities.  It MAY be sent when an IKE_SA is established after a
   crash, and the recipient MAY use this information to delete any other
   IKE_SAs it has to the same authenticated identity without waiting for
   a timeout.  This notification MUST NOT be sent by an entity that may
   be replicated (e.g., a roaming user's credentials where the user is
   allowed to connect to the corporate firewall from two remote systems
   at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
   if sent, MUST be in the first IKE_AUTH request, not as a separate
   exchange afterwards; however, receiving parties need to deal with it
   in other requests.

How can the assertion described in the first sentence be made by the 
sender of the IKE_AUTH request since the identities are not authenticated 
until the IKE_AUTH response is received?  Furthermore, it seems that even 
if the "authenticated" condition is dropped from the first sentence, the 
IKE_AUTH request would need to contain the optional IDr payload in order 
for INITIAL_CONTACT to make sense in this message.

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Sep 2008 12:12:31 +0300

Keith Welter writes:
> until the IKE_AUTH response is received?

I have implemented it so that we do do mark the initial contact being
received when we see the notification, and then when the full IKE SA
negotiation is finished (i.e. authenticated successufully), we
process the INITIAL_CONTACT notification.

Of course you should not act on the INITIAL_CONTACT immediately, but
only after the other end is authenticated himself. If the initiator is
using EAP to authenticate him, then he is authenticated only after
last IKE_AUTH request is processed.

> Furthermore, it seems that even if the "authenticated" condition is
> dropped from the first sentence, the IKE_AUTH request would need to
> contain the optional IDr payload in order for INITIAL_CONTACT to
> make sense in this message.

The first IKE_AUTH request from initiator to responder will have the
IDi, which gives the identity of the initiator, and if there is
INITIAL_CONTACT notification in the same packet the responder will
know that the identity of the other end will be IDi after the full
authentication is finished. If no EAP is used, then the responder can
immediately process the AUTH payload too, and will authenticate the
other end while processing the request. If EAP is used, then initiator
will be authenticated only at the last IKE_AUTH request, thus
processing of the INITIAL_CONTACT should be postponed until that. It
still makes sense to send the INITIAL_CONTACT in the same packet where
the IDi is sent, thus thats why it is sent inside the first IKE_AUTH
message.

For the responder to send INITIAL_CONTACT to initiator is usually not
that useful, as initiator already told the responder that he most
likely do not have valid IKE SA with the responder, because he started
the IKE SA creation in the first place.

The current text added by the clarification actually forbids responder
for sending INITIAL_CONTACT, as it says the INITIAL_CONTACT MUST be in
the first IKE_AUTH *request*, which means it cannot be in the IKE_AUTH
reply sent back by the responder.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 26 Sep 2008 08:50:29 -0400

Hi Tero, the problem is this: how does the initiator know when to send 
INITIAL_CONTACT?  How can the initiator know that this is the first SA 
"between the authenticated identities" when the initiator does not yet 
know IDr?  This might be the case because the initiator's PAD entry has a 
wildcarded remote identity, or it might be the case because the initiator 
has overlapping PAD entries and allows the peer to send an IDr differing 
from the initiator's optional IDr payload.  In either case, the initiator 
does not have enough information when it sends the IKE_AUTH request to 
know conclusively that this is the first SA "between the authenticated 
identities" simply because it does not know both authenticated identities. 
 For a mobile device bringing up its first and only IKE SA, this is not a 
problem.  But for a multi-homed server bringing up a dozen IKE SAs after 
reboot, it is problematic.

There may also be a (strained) use case for the responder's sending 
INITIAL_CONTACT.  If the responder uses NO_ADDITIONAL_SAs to limit one 
child SA per IKE SA, the initiator may have multiple IKE SAs to the 
responder.  If the responder reboots and a liveness exchange causes one of 
those SAs to be deleted and a new one to be negotiated, it would be 
helpful to receive an INITIAL_CONTACT from the responder to allow for the 
other IKE SAs to be cleaned up.  Perhaps we should only recommend an 
implementation send INITIAL_CONTACT as responder if it has this limitation 
of one child SA per IKE SA.  But that suggests we should allow for 
receiving INITIAL_CONTACT from a responder in any case.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Keith Welter/Raleigh/IBM@IBMUS
Cc:
[email-masked]
Date:
09/26/2008 05:15 AM
Subject:
[IPsec]  Comment on ikev2bis section 2.4

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 Sep 2008 13:22:02 +0300

> reboot, it is problematic.

I do not think this is really a problem in any real implementations.
Implementations need to know the PAD entry they are going to use when
they start to create SA. If they have existing SAs with the same PAD
entry, they will be using the same IKE SA to create the child SAs or
in case the existing SAs is something that cannot be used because for
example NO_ADDITIONAL_SAs received before, then they still know there
is IKE SA already there.

If they have overlapping PAD entries, then they need to give the IDi
and IDr to tell the other end which of those PAD entries they are
using, so other end can distingush multiple connections. If both ends
have same policy then they will not return different IDr. If the
policy is different in each end, then they might have situation where
the initiator sends IDi, and IDr along with INITIAL_CONTACT and
responder select different IDr to be used, but I would say that is
configuration error, thus the policy in responder end should be fixed
to fix this problem.

IKEv2 tries to work at some extent even if the peers have mismatched
policies, but there are cases where it cannot work if policies are
different enough. I think this is one of those cases.

I have never seen this kind of problem in any real world scenarios.
Also the easiest fix is to simply disable INITIAL_CONTACT
notifications in those cases. IKEv2 do not require INITIAL_CONTACT
notifications to work correctly, they are there mostly because IKEv1
had those, and in some simple cases they might optimize the resource
usage in the responder.

IKEv1 was not reliable protocol, so there it was important to remove
all one-way SAs with INITIAL_CONTACT because there was no other way to
recover from crash. In IKEv2 the extra SAs will go away quiet quickly
after the other end realizes the other end is not sending any traffic
and starts DPD, and when that fails it will delete IKE SA and all
IPsec SAs associated with IKE SA.

Because of this the need for INITIAL_CONTACT is much less than what is
was for IKEv1. 

> other IKE SAs to be cleaned up.

I do not think we are going to see such kind of limited IKE
implementations. My guess is that if implementation sends
NO_ADDITIONAL_SAs it only supports exactly one IKE SA and one IPsec SA
because it is some kind of connection where there can be only one
connection at time. I do not really think there will be
implementations which would allow multiple IKE SA from same peer, but
has only very limited number of IPsec SAs inside each of those IKE
SAs.

Again the normal IKEv2 DPD and so on will take care of the extra SAs.
Note, that if the initiator is going to use the similar mechanims for
all of the SAs he has, he will most likely trigger DPD about same time
for each of the SAs, and recreate them quite close to each other (also
failing DPD with peer, should be considered as a hint there is
something wrong with the peer, so at least that should trigger DPD for
the rest of the IKE SAs). 

> Perhaps we should only recommend an 

I do not really consider that case important enough to add special
handling for it. I would much rather stick with the section 7.8 of
RFC4718 which restricts the INITIAL_CONTACT to be in the first
IKE_AUTH request, i.e. from initiator only. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 29 Sep 2008 07:26:11 -0400

Tero, thanks for the reply.  I think that clears up most of the issues I 
mentioned except for the issue of a wildcarded PAD entry; e.g., allowing 
the remote identity to be any subdomain of your own company's domain name, 
within a certain scope of IP addresses.  If we initiate multiple 
connections to different IP addresses using this PAD entry, then we cannot 
know whether the IDr for any new connection matches the IDr for any prior 
connection until after the Auth exchange is complete.

I wonder whether we could 1) allow for INITIAL_CONTACT to be sent in a 
subsequent exchange for just this case; or 2) allow the use of IP address 
considerations as well as identity considerations in determining whether 
to send INITIAL_CONTACT, if there is any uncertainty due to identity 
wildcarding.

It sounds like you are hinting at #2 in your note below.  You mention 
checking whether an implementation has "existing SAs with the same PAD 
entry."  But until the remote identity has been resolved, choosing a PAD 
entry is done only on the basis of IP address anyway.  Distinguishing 
between distinct IP addresses covered by the same PAD entry would seem to 
be a logical extension of that.

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
[email-masked], Keith Welter/Raleigh/IBM@IBMUS
Date:
09/29/2008 06:26 AM
Subject:
Re: [IPsec] Comment on ikev2bis section 2.4

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 Sep 2008 15:54:38 +0300

> connection until after the Auth exchange is complete.

But if they are going to be on different IP-addresses and they do not
have anything special marked on them (i.e. marked in PAD to have
multiple IP-addresses), I would guess they are different entities. The
IDr text is there just to make sure you do not use ONLY the IP-address
to see if the peer is same. In normal case you do both IP and identity
checks. 

> subsequent exchange for just this case; or

If you are not sure, just dont send INITIAL_CONTACT at all. As I said
it is not that important in IKEv2 anyways. 

> 2) allow the use of IP address 

IP-address is assumed to be taken account BEFORE taking account the
ID. The RFC says "authenticated identity", this does not rule out
IP-address checks. The text was changed from IP-address to
authenticated identity just to allow multiple IKE SA with different
identities with same IP-address. The original idea was not to assume
that any IP-address can have any identity, i.e. normally the first
check would be the gateway IP-address (unless the PAD entry is marked
specially to replicated gateway or gateway having multiple
IP-addresses). 

> entry is done only on the basis of IP address anyway.

Yes. Or the PAD entry is done on the bases of the triggering packet,
and we do know the gateway IP-address where we are going to connected
using IKE.

> Distinguishing between distinct IP addresses covered by the same PAD
> entry would seem to be a logical extension of that.

Unless there is anything special in the PAD I would always assume that
different IP-addresses are different entities, even when they might
have same ID. In case you are connecting to different authentication
realms you can have exactly same ID for the remote end using different
CA certificates for example, and when you have triggering packet you
select one of them and connect to the IP-address of the gateway. In
that case you must check the peer IP also, as that tells they are
different autenticated identities even when they have same ID.

Perhaps the term should be "authenticated entity" instead of
"authenticated identity".
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec