Subject: [IPsec] Reauthentication extension for IKEv2

From: Martin Willi <[email-masked]>
Date: Tue, 16 Sep 2008 09:17:17 +0200

Hi,

The reauthentication procedure for IKEv2 works as follows (from
draft-ietf-ipsecme-ikev2bis-00 2.8.2):

   IKEv2 does not have any special support for reauthentication.
   Reauthentication is done by creating a new IKE_SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
   payloads), creating new CHILD_SAs within the new IKE_SA (without
   REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
   deletes the old CHILD_SAs as well).

While this approach works and reuses existing protocol elements, it has
some disadvantages. The problem is that we actually can't know that an
incoming IKE_SA setup is used for reauthentication, as creating multiple
identical IKE_SAs is perfectly feasible.

1. If a lot CHILD_SAs are established within the IKE_SA, this procedure
   needs a lot of exchanges to complete, increase load and reauth
   duration. During this stage, we also have multiple CHILD_SAs with
   the same traffic selectors. Defining priorities is difficult, as
   we don't know if the new IKE_SA is actually for reauthentication or
   not.
2. The server doesn't know that the new IKE_SA creation is used for
   reauthentication and can't assign the same INTERNAL_ADDRESS to the
   peer without risking an address conflict. This will result in an
   address change and will close established connections using that
   address.
3. Housekeeping and connection monitoring gets ways more complicated,
   as the new IKE_SA does not have any relation to the old one.

Mainly because of 2., we have been forced to do the reauthentication
procedure by closing the IKE_SA before establishing the new one. This
will eliminate the address flicker, but introduces a connectivity gap of
seconds.

While there are workarounds to these problems, I don't see a way to
implement reauthentication properly and reliable. Because of these
problems I'm thinking about an extension to do the reauthentication
within an established IKE_SA (think of the existing rekeying procedure,
but with an additional AUTH/EAP exchange).

What do you think about such an extension? Already considered something
similar, or does your reauthentication procedure work hassle-free? I'm
wondering if we are the only ones facing these problems or if such an
extension would gain broader acceptance...

Regards,
Martin - strongSwan project

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Sep 2008 12:09:14 +0300

> extension would gain broader acceptance...

The first question I have is why are you doing reauthentication at
all?

What is the benefits of the reauthentication?

What is the benefits of the reauthentication that can be done WITHOUT
user intervention (i.e. no user typing in password or pin code or
fingerprint or similar)?

I myself can only really see benefits from reauthentication when it
does require that user is really sitting there on the machine, and
gives something that the machine itself cannot give. In those cases
the user is required to type in something or do something anyways,
thus it does not really matter if the communications is interrupted
for second if user must stop his work for much longer time to type in
his passphrase or pin code.

The RFC 4478 simply skips this question and says "With some IPsec
peers, particularly in the remote access scenario, it is desirable to
repeat the mutual authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by a
third party who has gained control of the IPsec peer."

In most cases if third party has gained control of the IPsec peer he
will also get control of all authentication information inside the
peer, including private keys and pre shared keys. Only way to make
sure that he does not get access to those is to protect them with
passphrase, or pin code or similar that is only known by the user.

This is also said out in the RFC 4478: "However, in the remote access
scenario it is usually up to a human user to supply the
authentication credentials ..."

Because of this I do not think there is that much requirement for
reauthentication protocol that is faster than what we already have. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Martin Willi <[email-masked]>
Date: Tue, 16 Sep 2008 13:15:21 +0200

Hi Tero,

>  gives something that the machine itself cannot give.

Yes I absolutely agree, this is the point of reauthentication.

If the user uses smartcard authentication and leaves for a coffee break, 
he removes the smartcard. This will keep the tunnel and all applications 
up until the user returns. If he does not return in time, the tunnel 
will get unusable.

>  his passphrase or pin code.

If the pin code is cached while the smartcard is connected, no user 
intervention is required at all.

But the real problem are application session: They might break during 
these communication interrupts, and are guaranteed to break if the 
INTERNAL_ADDRESS changes.

>  reauthentication protocol that is faster than what we already have.

Speed is not the main problem, but keeping up IPsec tunnels during 
reauthentication.

Martin

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Sep 2008 15:03:24 +0300

> INTERNAL_ADDRESS changes.

I agree, thats why I think the way you presented there where you first
remove the IKE SA and then start it over so you get the same address
is the only one that really works. In most cases for remote
access cases you have only one IPsec SA so creating new IKE SA and
that IPsec SA is fast and should not disturb normal TCP/IP flows
(unless your operating system does stupid things, like destroy all
TCP/IP flows when you do the recreationg of the IKE SA).

> Speed is not the main problem, but keeping up IPsec tunnels during 

I do not really think we need to keep the IPsec tunnels up. We do need
to keep the TCP/IP connections running inside those IPsec tunnels up.
In most remote access cases the number of IPsec SAs is very small
(usually one). In cases where you are doing host to host transport
mode IPsec, you can have lots of IPsec SAs, but in those cases most of
them are also between different peers.

Can you give some example where you really have lots of (hundreds of
IPsec SAs) between two peers in cases where you would like to use
reauthentication?

If we are only talking about the INTERNAL_ADDRESS cases, there might
be better ways to solve it. For example an exchange in the old IKE SA
which releases the address (and forbids making new IPsec SAs for the
IKE SA, but still keeps existing IPsec SAs working), and then the new
IKE SA can get the same address and then you can create new IPsec SAs
and delete the old ones from old IKE SA until you have moved all
traffic and then you can remove old IKE SA. Or you could even make the
implementation so it allows requesting and getting the same address
for 2 different IKE SAs provided they both come from same IP-address
and port, and are using exactly same identity to authenticate them,
and the new IKE SA creation didn't use INITIAL_CONTACT notification,
but did include all exactly same parameters given to first IKE SA as
hints when doing configuration payloads. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Sep 2008 22:23:12 +0100

Hi Martin.

Please see my comments below.

>   we don't know if the new IKE_SA is actually for reauthentication or

Multiple CHILD_SAs is not a problem, as that is also explicitly  
permitted by RFC 4306. As long as the old CHILD_SA has not been  
deleted, it's perfectly fine to use it.  Besides, as Tero said, remote  
access VPNs tend to have either one child SA or only a few.

I do see a problem with the text, in that it says that you re-create  
all the child SAs before deleting the old IKE SA. IMO the better way  
is to (1) create a new IKE SA, (2) delete the old IKE SA (and all  
associated child SAs) and then (3) create new child SAs as needed.

>   address change and will close established connections using that

In the new IKE_AUTH exchange, the initiator will have the same IDi  
payload as in the setup of the old SA. Additionally, the initiator  
will ask not for any IP address in CFG, but for the IP address that it  
already has. If this condition is met (address belongs to an IKE SA  
authenticated with the same IDi), it's OK to re-assign the IP address.

>   as the new IKE_SA does not have any relation to the old one.

I agree.

> will eliminate the address flicker, but introduces a connectivity  

Again, I don't think that #2 is a problem.

> extension would gain broader acceptance...

OK, when I was writing 4478, I did consider four possibilities:

1. Do nothing. Let's call the client Carol and the server Steve. Steve  
just deletes the IKE SA when it's time, and Carol begins a new IKE SA  
at once.

2. What 4478 says. Re-authenticate by making a new IKE SA and deleting  
the old one. New child SAs created as needed. Steve only tells Carol  
when she should re-authenticate.  The advantage here is that Carol the  
user can type in her password or insert her smartcard at her leisure,  
without her connections being cut.  It's also rather simple to  
implement over an existing IKEv2, and if Carol doesn't support the  
extension, we revert to #1.

3. In addition to #2, add an indication to the AUTH exchange (using a  
notification probably) that this replaces this old IKE SA. In that  
case, after the AUTH exchange completes, all child SAs are transferred  
to the new IKE SA, and so does the CFG address. This was rejected by  
people on this mailing list, because it makes the code more  
complicated, and doesn't save us anything.

4. Similar to what you propose. we can do the AUTH exchange alone,  
under the existing IKE SA (with or without rekeying) and no new child  
SAs at all. There is the question of what buffer we would be signing  
with the AUTH payloads (do we keep a copy of the original INITIAL  
exchange?), but this can be resolved one way or another.
This is probably what Dave Wierbowski means by "real support". It's  
also more efficient on the wire and in terms of computation. I agree  
that this makes a lot of sense, and if we were designing IKEv3 now, I  
would be all for this.  However, this is an extension that is usable  
is some scenarios but not others. As AUTH is defined now in the RFCs  
and in the bis document, you're not allowed to do an AUTH exchange  
without a piggybacked CHILD SA exchange, and you're not allowed to do  
an AUTH exchange over an open IKE SA, in parallel with other exchanges  
(maybe the window is not 1) and with existing child SAs. All these  
differences may mean a significant change to the state machines for  
the AUTH exchange.

I liked option #4 very much, but I felt that it was too much of an  
alteration to IKEv2 for the benefit it gives. Using the make-before- 
break logic of RFC 4478 you can get the same results, with slightly  
less efficiency, but with substantially less code complexity. That  
seems to me to be the better balance.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Sep 2008 22:28:40 +0100

> TCP/IP flows when you do the recreationg of the IKE SA).

Destroying the TCP/IP flows because of IKE SA is stupid. But it does  
make sense to turn off the virtual interface if the IKE SA has been  
destroyed, and no new IKE SA is created. That's why I prefer the make- 
before-break way.

> hints when doing configuration payloads.

Agree, but I think you don't even need IP and port. Just same IDi and  
requesting same address.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Sep 2008 14:03:26 +0300

> Agree, but I think you don't even need IP and port. Just same IDi and  

The IP and port check would protect against cases where you happen to
have 2 laptops or similars sharing same ID and same authentication
data. In normal case that should not happen, but that might happen
(for example when you have new and old laptop and are moving stuff
from old to new etc) and adding those checks is cheap and they should
not affect normal use. I.e. if the IP-address is different then second
connection is considered to be new connection instead of
reauthentication, and it gets new internal IP-address and everything
works.

Do you see any problems by adding the IP address and port check?

Only case I can see is when using mobike and moving between
IP-addresses and doing reauthentication at the exactly same time. This
could be prevented by saying that the IP-address check includes all
possible IP-addresses the client has announced in the additional
addresses notifications.

The problems by giving two different devices same IP-address is more
serious than changing the IP-address of existing device, so thats why
I think we want to make strict checks to detect that the devices are
same. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Martin Willi <[email-masked]>
Date: Wed, 17 Sep 2008 13:35:52 +0200

Hi,

> I do see a problem with the text, in that it says that you re-create all 
> the child SAs before deleting the old IKE SA. IMO the better way is to 
> (1) create a new IKE SA, (2) delete the old IKE SA (and all associated 
> child SAs) and then (3) create new child SAs as needed.

Yes, if we want to get usable and interoperable reauthentication without 
an extension, we have to define that procedure more in detail (as Tero 
has already done in a previous mail):

- The make-before-break as discussed
- Requesting the same INTERNAL_ADDRESS explicitly
- IRAS must assign used INTERNAL_ADDRESS if explicitly requested to the
   same Identity
- Probably other details

As I already said, it IS possible to do that with the currently defined 
procedure. But in my experience, you'll need a lot of quirks to get 
things working smoothly, and I really see it skeptical to get good 
interoperability results between different vendors.

> alteration to IKEv2 for the benefit it gives. Using the 
> make-before-break logic of RFC 4478 you can get the same results, with 
> slightly less efficiency, but with substantially less code complexity. 

In my opinion, doing the reauthentication the current way IS complex, 
involves multiple active IKE_SA, transferring state between them, 
invalidating the old, ... And there are unresolved issues, such as 
collisions, which will introduce an additional layer of complexity in 
the whole thing.

At least for our implementation, it would be much simpler to do it 
inline. It is almost the same as rekeying, but with additional 
authentication with the primitives used in IKE_AUTH.

Martin

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Sep 2008 19:30:40 +0100

> Do you see any problems by adding the IP address and port check?

I haven't thought this through, but I think there could be weird  
interactions and race conditions between MOBIKE or simple mobility and  
the re-authentication. If the IDi is the same, AND the client  
specifically requests the IP address that belongs to the other IKE SA,  
then I don't see how the old/new laptop case is a problem.  The new  
laptop will not know the IP address assigned to the old laptop, and  
will (SHOULD?) request an empty address.

---

From: <[email-masked]>
Date: Thu, 18 Sep 2008 10:41:13 +0300

Yoav Nir wrote:

> interactions and race conditions between MOBIKE or simple mobility
> and the re-authentication. If the IDi is the same, AND the client
> specifically requests the IP address that belongs to the other IKE
> SA, then I don't see how the old/new laptop case is a problem.  The
> new laptop will not know the IP address assigned to the old laptop,
> and will (SHOULD?) request an empty address.

We could add some advice on when the client should request a specific
address, and when just ask for any address (empty request).

I think the former case would occur basically if (a) the client is
explicitly configured to do so, or (b) it has an existing IKE_SA with
that address, or (c) if it had an IKE_SA with that address within 
some short amount of time, and still has active connections using that 
address.

Similarly, it probably wouldn't hurt to give some advice for the
gateway about reallocating addresses. If you reallocate an address to 
another VPN client too soon, this may even lead to security problems
if e.g. firewall state between the gateway and the rest of the world
hasn't timed out yet (for connections established by the VPN client
who had this address earlier).

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Sep 2008 13:21:20 +0300

> will (SHOULD?) request an empty address.

Quite often dhcp clients etc do store the address they got to the disk
and try to get the same address every time. Same kind of thing would
be logical and good in VPNs too, i.e. the VPN client tries to get same
IP-address even across reboots and so on. This makes some things
easier.

The mobike might have cases where there is change in the addresses at
the same time the reauthentication is requested and that causes the
IP-addresses to change. On the other hand as I explained in my
previous email, I think the case where two different nodes might have
same address is much more serious than the case where the IP-address
changes (provided this can only happen in very corner case race
conditions).

I agree that it might be enough to check ID and requested IP-address,
but would myself most likely put the IP-address check too, just in
case. On the other hand this is internal implementation detail level
things, that we do not need to specify exactly, as this does not
really affect interoperability, only how effectively implementation
handles different corner cases (i.e. both will work).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Sep 2008 13:28:26 +0300

> address, and when just ask for any address (empty request).

I have always assumed that client will give its previous address as
hint to the server regardless what that address was and when it was
last time used, provided it still remembers what this address is. Also
I would hope server would try to give that same address to client if
it is free, and the server should try to keep addresses free as long
as possible, i.e. using LRU list of addresses.

Of course this is again implementation details, that do not affect
interoperability, but do affect how well the implementations work on
certain situations. Different situations might have different
requirements, for example in some cases the server might want to give
new random address to each client every time, just to protect the
identity of the client.

Because of this I do not think we need to write any specific rules how
to handle this cases, but we can add some text explaining the effects
of different ways of doing things.

> who had this address earlier).

I think that kind of text should be part of the security
considerations section, i.e. explain that case and say that servers
SHOULd not reallocate same address to different entities too quickly. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 18 Sep 2008 14:13:26 +0300

Tero Kivinen wrote:
> > We could add some advice on when the client should request a
> > specific address, and when just ask for any address (empty
> > request).
> 

As was pointed out earlier in this thread, this *can* affect whether
reauthentication works correctly or not: some combinations of client
and gateway behavior lead to problems.

When writing RFC 4718, I had thought that it's OK for the server to
give the requested address if it's free, or if it's given to the same
authenticated initiator identity (often IDi, except when EAP is used;
see RFC 4718 Section 3.5).

But depending on the client behavior, this could lead to problems if
the same initiator identity is used on multiple client hosts... 
checking the outer IP/port (from IKE packet) would probably solve that, 
if it doesn't interact badly with MOBIKE. Or it could be solved
by saying the client shouldn't request a specific address if it's
nor currently using it.

Best regards,
Pasi