Subject: [Ipsec] Initial Contact messages

From: "Michael Richardson" <[email-masked]>
Date: Sat, 04 Dec 2004 22:42:38 -0700

-----BEGIN PGP SIGNED MESSAGE-----

This is an extended summary of a discussion at the ICSA IPsec Consortia
meetings of December 2, 2004. 

The discussion started concerning the IPSec 2.0 criteria. In it, it was
said that ICSA was going to test that a responder properly dealt with
Initial Contact messages by deleting old SAs with that "identity".

IKEv2-17 says:

        INITIAL_CONTACT                          16384

            This 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).

(some upcase is mine)

The last sentence in this is pretty much where the conversation lay.

It is difficult for an entity to know if the credentials may be replicated. 
So, to some extent, we assume that it will be difficult in practice to
configure the client correctly here.

A number of people suggested that in fact they would always be ignoring
the IC messages. (Thus the conflict with the ICSA Criteria requirements)

A lot of the discussion dealt with what an *AUTHENTICATED IDENTITY* is.
Particularly in the context of XAUTH users with group-psk.

To understand the reasons, we discussed a number of scenarios. We had
a number of scenarios that we identified. In all cases, we were interested only
in how the responding system should behave.

Below, Ix is the PARENT SA Identity. ID_i.
Note that we consider the 4-tuple of SA/DA, SP/DP because we assume that
there may be NATs in between.

1) a multiuser system H1, creates two parent SAs because it needs to
   authenticate as two different identities.

	+-------+                             +-------+
	|H1   I1|<--------------------------->| I3  H2|
	|     I2|                             |       | 
	+-------+                             +-------+

  We believe that H1 *MAY* send IC on each connection. 
  For this reason it may be that H2 must look at identity *ONLY* when
deciding which old SAs to flush. 4-tuple is not unique.

2) a single user system H1, connecting to a gateway H2, shutting
   down/suspending, and returning on another IP:

       .--------.
       | I1  H1 |<------------\		      .-------.
       |        |	       \	      |	      |
       '--------'		------------->|	      |
- ---- time ----  			      | H2    |
       .--------.             /-------------->|       |
       | I1  H1 |<-----------/  	      |       |
       |        |       		      '-------'
       '--------'				  
                				  
In this case, the 4-tuple is unique, but in addition, the ID being the
same is works to find the appropriate SAs.

3) two single user systems, using XAUTH, having "Group PSK" I1.
   Different user names.
   
       .--------.
       | I1  H1 |<------------\		      .-------.
       | user1  |	       \	      |	      |
       '--------'		------------->|	      |
                			      | H2    |
       .--------.             /-------------->|       |
       | I1  H2 |<-----------/  	      |       |
       | user2  |       		      '-------'
       '--------'				  

In this case, if H2 combines the 4-tuple with the Ix, then H2 can find
SAs before XAUTH is done. Alternatively, H2 can wait until the XAUTH has
been done before it processes the initial contact. 

4) two single user systems, using XAUTH, having "Group PSK" I1.
   The same user names. This is, for instance, the situation where
   a single person wants their laptop and their PDA to be online.
   
       .--------.
       | I1  H1 |<------------\		      .-------.
       | user1  |	       \	      |	      |
       '--------'		------------->|	      |
                			      | H2    |
       .--------.             /-------------->|       |
       | I1  H2 |<-----------/  	      |       |
       | user1  |       		      '-------'
       '--------'				  

H2 can determine uniqueness here by combining 4-tuple, ID and username.
Arguably, in this situation IC should not be sent if the IDs are known
to be combined.

{In addition, situation (1) could be combined with any of the other situations}

===== conclusions =====

There are as many as 6 items that may be used to index into the SA table
to do IC processing. There was concern that it may not be possible to
build an index that provides better than linear search given the
differences. 

There was extension discussion that liveness checks (dead peer
detection) will in most cases clean up all stale SAs. There was
discussion about whether it would in fact clean up in all situations.

{Most of these issues are not unique to IKEv2. However, XAUTH usage has
 not generally been useable across vendors in IKEv1. ICSA IPSec 2.0 does
 not test XAUTH in IKEv2 (or IKEv1). }

The suggestion was a heuristic that said that IC processing should be
done by looking up 4-tuple only. If only 2 Parent SAs were found (i.e. the
current one, and 1 old one), then the old one should be purged (with all
of its children).

This permits efficient cleanup for site-to-site VPN configurations where
the end points do not move. It was noted that this is not the situation
where one worries about resource exhaustion --- site-to-site VPNs tend
not to have to scale to the same degree that RoadWarrior ones do.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 5 Dec 2004 09:22:12 -0800

>discussion about whether it would in fact clean up in all situations.

Whether or not it does is irrelevant to the user unless there is a 
resource-exhaustion issue. If there is such an issue, the 
implementation probably will have other serious problems that cannot 
be found consistently.

>  not generally been useable across vendors in IKEv1.

The issues are relevant regardless of using XAUTH: the are the same 
for the EAP methods in IKEv2.

>current one, and 1 old one), then the old one should be purged (with all

That is certainly the reasonable interpretation of the spec, and 
fairly easy to implement.

>the end points do not move.

Yes, and it also permits efficient cleanup for remote-access users 
who only come in over one transport at a time.

>  It was noted that this is not the situation

Some remote-access VPN systems have an setting that allows the 
administrator to say "anyone in this group of users can only be 
logged in once at a time". If a user with the exact same credentials 
(including whatever came in after XAUTH) completes SA setup, the 
first SA is torn down. This should work fine even for pre-shared 
non-secrets as long as XAUTH or some other credentialling mechanism 
produces unique results for each user.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Dec 2004 12:06:51 +0200

> configure the client correctly here.

Unless the configuration says this might be replicated, the
implmentation should send initial contact notifications. If it is not
known whether this is replicated or not, then it is not replicated
(i.e. local end should know all cases where your local ID is
replicated).

There is NOTHING in the text which says that you are should be
ignoring those notifications ever. Even if you are replicated node or
something, if someone sends you INITIAL_CONTACT notification you
should process is normally (provided you support INITIAL_CONTACT
notifications at all, the whole notify processing is optional).

If someone ignores INITIAL_CONTACT notifications, I would report it as
a bug in the implementation.

The text above talks about when you MUST NOT SEND the notification.
Remember this when implementing the code. It does NOT talk about
receiving case in the last sentence. 

Most of the replicated cases, are not really replicated cases, and
they can be avoided, simply by adding another identity for the user.
I.e if he wants to use multiple connections at same time, like pda,
laptop and home machine, he needs one identity for his laptop, one
identity for his pda and one identity for his home machine. In this
case there will not be replicated identities, thus initial contact
should be sent.

Also if he is using smartcard or securid card or any other physical
token, that token can only be used in one connection, thus in that
case it is not replicated either. I.e. if he removes the smartcard
from his pda and inserts it to the laptop, the connections to the pda
should be disconnected when the laptop connects.

> Particularly in the context of XAUTH users with group-psk.

There is no XAUTH with IKEv2. There is no group-psk in the IKEv2.
There SHOULD NOT be any group-psk in the IKEv1 case either, but as
there are, then there better be different identity for each user (i.e.
the psk is same, but the identity inside the negotiation should be
different for each user).

>    authenticate as two different identities.

Yes. This is correct, only use ID to find SAs.

>    down/suspending, and returning on another IP:

Again H2 should use only the ID to find the SAs.

> 3) two single user systems, using XAUTH, having "Group PSK" I1.

The ID used inside the IKEv1 main mode exchange should be different,
and that is the only thing that should be used to identify the user in
the H2. Note, there is no reason why the ID in the IKEv1 main mode
should be same if the PSK happens to be same for both users. The
reason we have the PSK same for all users in the IKEv1 main mode, is
because the IKEv1 encrypts the ID with the PSK, thus you do not know
the ID before, and you need to select proper PSK before knowing the
ID. After we have selected the PSK and can decrypt the ID, we can use
that to select which SAs to delete.

And, yes, any member of the group having the group PSK can delete all
SAs for any other users, but he can do quite a lot more also, like
claim to be H2 and authenticate itself to the H1 as a H2, and listen
all traffic between. This is simply the property of the group PSK.

So if you are using the group PSK, all the members in the group DO
have identical security properties, and everybody in the group can
listen all others traffic and modify it at will. You better trust each
of the members in the group...

Doing XAUTH after group PSK does not change a situation at all, as it
does not any way tie the authentication to the IKE SA, thus attacker
can simply forward the XAUTH forward (or at least it used to be that
when I last time checked the protocol, and cannot check it now as
there is no draft about it). 

>    a single person wants their laptop and their PDA to be online.

The user should have two identities one for the laptop and one for the
pda in this case, i.e. something like [email-masked]
and [email-masked]. There is no reason why he should have
same ID in those cases. So H2 can again use only the ID to distinguish
the SAs to remove. 

> {In addition, situation (1) could be combined with any of the other

Does not change a thing there.

The only case where you want to share the IDs and authentication
information is some kind of high availibity systems where you have
shared IPsec SAs state between two nodes, but you do not have shared
IKE SA state (i.e. you need to recreate IKE SAs after the one node
goes down, but you can still continue using the old IPsec SAs (they
might be on the actual ethernet card and the IKE is run on two
different blade cards on the system, and the master card of those just
crashed)).

In all of the above cases some people will not want to switch to use
separate IDs even when there is no reason why not, so that is also
another reason why they might to configure their own end (i.e. the
initiator) so that it does not send initial contact notifications. 

> build an index that provides better than linear search given the

Nope. The only thing needed is the ID, and nothing else. If you use
anything else you break NAT-T, and address agility of the IKEv2. 

> discussion about whether it would in fact clean up in all situations.

In IKEv2, yes, the dead peer detection will eventually clean up the
state, but that means there will be traffic going to the black hole
for couple of minutes, which is not really very nice. Initial contact
will take care of the recover in seconds instead of minutes.

Note, that IKEv2 dead peer detection will remove SAs if and only if
there is no reply back from the other node after multiple
retransmissions, and after the time out. It says that about at least a
dozen retries over at least several minutes before giving up (section
2.4 in draft-ietf-ipsec-ikev2-17.txt). 

>  not test XAUTH in IKEv2 (or IKEv1). }

IKEv2 do not have XAUTH, so that is only for IKEv1. Also there is no
reason to use group PSK in the IKEv2 at all, so all points suggesting
that are non issues for IKEv2. 

> current one, and 1 old one), then the old one should be purged (with all

No.

In the initiator side you first check whether you have SAs with the
node you are connecting to. If you do not have any IKE SAs for the ID
you are connecting to, and your local ID is not marked as replicated,
you send INITIAL_CONTACT notification.

On the responder side you do the same thing, i.e. when you receive ID
you check whether you have IKE SAs with the other end, and if not, and
the your local ID is not configured to be replicated you send the
INITIAL_CONTACT notification.

Whenever you receive INITIAL_CONTACT notification you process that
normally, i.e. you simply search for the IKE SA matching the ID pair
of the new IKE SA, and remove those. There is no point of checking
anything else, and if the other end claims that his ID is not
replicated (by sending INITIAL_CONTACT) and that he does not have any
SAs with you, you can simply trust him and delete the SAs. 

The local end sending out the INITIAL_CONTACT should be the one who
knows whether his local ID is replicated or not.

It is completely possible that the initiator do not send
INITIAL_CONTACT notifications because he knows there is replicated
node for him, but the responder do send it as he knows he is the only
node, and there is no SAs with the ID connecting. If the initiator
then had SAs with the responder ID before, he can clear them out, as
responder do not have them anymore.

The other way around is not normally very useful, as if the initiator
sends INITIAL_CONTACT notification, it really does not matter whether
responder sends INITIAL_CONTACT notification to the initiator or not,
as the initiator does not have any SAs with responder (initiator just
claimed so by sending INITIAL_CONTACT notification).
-- 
[email-masked]