Subject: Secure remote access with IPsec

From: Antonio Forzieri <[email-masked]>
Date: Wed, 19 Mar 2003 15:42:09 +0100

Hi,
I send this mail to the WG followig Paul Hoffman advice.

I'm an Italian student and I'm doing my degree thesis about "Secure
remote access using IPsec".
I've been studing the problem since August 2002 and I think that the
current IKEv2 draft (05) solves almost all the problems around this
technology even if changes to the signature model proposed by Hugo
Krawczyk should (MUST :-) ) be adopted (Yes, I read SIGMA paper).
Because this is a research work (thesis) It would have no sense for me
implementing IKEv2.

Are there any other problems, directions or open issues about this
technology, that MUST be studied? Is there something (simulations,
measures, implementations) that can help in making this technology more
powerful and that *could be useful to IETF*?

P.S: These are the problems that I studied in these months:

- Endpoint Authentication is solved by EAP even if there is "The
compound authentication binding problem" using legacy authentication
mechanism like CHAP, OTP, SecurID... However I think that in the future
we will authenticate ourselves with a smart card, or something similar
- What about Kerberos in EAP?
- Why can't we make a binding AUTH with CHAP, OTP?
   AUTH = prf(Password | "Key Pad for IKEv2", <message bytes>));
   with OTP we can think of doing something like this:
   AUTH = prf(Next_One_Time Password | "Key Pad for IKEv2", <message 
bytes>));

- Configuration problem is solved by the use of the Configuration
Payload (CP), I think this is the easiest way of doing this, even if in
the WG peoples long debated DHCP Vs CP;

- NAT-T capability are enabled in IKEv2, and I think it works well (what
about let IKE speaks on UDP 4500 directly even when there isn't NAT-T
function enabled? What's wrog with that?). I know the pseudo-NAT
problem, however I think that an attacker on the path could easily
delete all the message.

- IPsec is well integrated with MIPv6 
[draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile 
node connecting back to his Corporate Network, without need rekeying 
when it changes his address (can we change the selectors of a SA or an 
entry of the SPD upon the receiving of a BU message?)

-- 
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: [email-masked]
ICQ# 177683894
------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Mar 2003 01:11:50 +0100

In your previous mail you wrote:

=> research is not 100% paperwork...

=> EAP is the PPP generic authentication. You can put what you'd like
in EAP.

=> CHAP and OTP are included in EAP (CHAP as the MD5-Challenge, OTP
as itself, both are "initial" types).

=> if it seems useful to permit this (IMHO it will be the case) then
NAT-T support will get a MUST.

   function enabled? What's wrog with that?).

=> if the function is disabled this is simply a policy mismatch, i.e.,
a negociation failure (notification with error "INVALID-SYNTAX"?)

   I know the pseudo-NAT
   
=> it seems you read my drafts!

=> we cannot change the selectors of a SA without rekeying. And we shan't
change a traffic selector of a tunnel without rekeying. The situation
is a bit more complex for transport mode or peer addresses, today the only
way is rekeying but there is a WG agreement it should be studied in a
post-IKEv2 activity. Note the MN-HA transport mode SA for BU protection
is setup in a proxy mode (transport mode where peer addresses and traffic
selectors don't match). Such SAs cannot be updated but fortunately in
this special case this is not needed...

Thanks

[email-masked]

---

From: Antonio Forzieri <[email-masked]>
Date: Fri, 21 Mar 2003 12:30:49 +0100

> => research is not 100% paperwork...
You are right, however, if there are any other problems, directions or 
open issues about remote access, I think it will be usefull study them.

> => EAP is the PPP generic authentication. You can put what you'd like
Agreed.

[SNIP]
> NAT-T support will get a MUST.
The reason why nat-t draft and than IKEv2 draft switch the communication 
to port 4500 if a NAT is detected there is a NAT-T helper fuction which 
does nottraslate UDP500 and that is implemented in a lot of NA(P)T. So 
what's wrong to let IKev2 directly speak on port 4500 instead of 500?
If we let IKEv2 speak on port 500 and then switch to port 4500 if nat is 
detected we should have collision problem during IKE_SA_INIT.

> => it seems you read my drafts!
Of course! :-)

> change a traffic selector of a tunnel without rekeying.
Why not? What's wrong with changing the selectors?

[from  draft-ietf-mobileip-mipv6-ha-ipsec-03.txt]
    Step 9.  If the mobile node and the HA have the capability to change
    the IKE endpoints, they change the address to C.  If they dont have
    the capability, both nodes remove their phase 1 connections created
    on top of the care-of address B and establish a new IKE phase 1 on
    top of the care-of address C.  This capability to change the IKE
    phase 1 end points is indicated through setting the Key Management
    Mobility Capability (K) flag [8] in the Binding Update and Binding
    Acknowledgement messages.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Mar 2003 18:53:11 +0100

=> nothing but the current draft wording suggests that IKE_SA_INIT
always runs over UDP 500. This should be fixed.

=> there is no collision problem with the same initiator, and collisions
where both sides are initiators are already handled by the rekeying stuff
(both in the draft and in this list).

=> the term selector is not very accurate. You can't change the traffic
selectors but you can change the endpoints (i.e., the peer addresses)
with a peer address update mechanism.

       top of the care-of address C.

=> this text applies only to IKEv1. In IKEv2 one should use the rekeying
mechanism for the IKE SA, both because it is available and because in
IKEv2 when an IKE SA is closed all the IPsec SAs it negociated are closed.

       This capability to change the IKE
       phase 1 end points is indicated through setting the Key Management
       Mobility Capability (K) flag [8] in the Binding Update and Binding
       Acknowledgement messages.
   
=> this is about peer address update mechanisms, in IKEv2 you'll get:
 - an implicit mechanism with NAT Traversal for peers which have
   the other peer behind a NAT.
 - an explicit mechanism defined after the urgent publication of the
   IKEv2 document.
 - a programmatic stuff which provides the peer address update itself
   for a set of SAs (an IKE SA and some IPsec SA pairs). It will be
   used of course by IKEv2 but I've suggested to make it available from
   the outside of the IKEv2 process(es).

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 22 Mar 2003 03:17:07 +0800

> problem, however I think that an attacker on the path could easily

The current IKEv1 NAT-T requires that implementations MUST be able to
handle initial connections coming to port 4500. I think this should be
taken to IKEv2 also. 

> entry of the SPD upon the receiving of a BU message?)

I was talking with Jari Arkko about this last night, and I came up
with following proposal:

----------------------------------------------------------------------
2.25 Explicit Address Updating

For some cases there are needed for explicitly update the peer
address. This can be used to support mobile-ip, multihoming, and to
help SCTP support. The difference with implicit address updating, is
that in this case the other end can actually notify the other end
about the change in the address, and authenticate the new address (and
port). The explicit address update is done by sending
SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
inside, to the other end. This notification can be send either using
the old or new address, but the sender MUST be able receive in the new
address before sending this out.

When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process
MUST check that the other end can receive the packets sent to new
address, by sending empty notification to the peer addres and port
given inside the notification (not the UDP outer address). When the
host requesting the change replies to that notification, and proofs
that it can actually receive packets sent to that address the actual
change should take effect. This change affects the IKE SA used to
receive the notification (i.e all future exchanges started on that IKE
SA will use this new address) and all child IPsec SAs created by this
IKE SA (i.e tunnel endpoint updated to new address).

The reply to the original SOURCE-ADDRESS-CHANGED notification is sent
back to the address where it was received, as is also all other
requests, where reply is not yet sent (i.e they follow normal rule,
that the reply is sent back to the address where the packet
originated). Note, that all hosts are required to process this
notification while waiting for reply to their SOURCE-ADDRESS-CHANGED
notification (see section 2.3). 

This requires implementations to support mutating the already existing
SAs (one way to implement this is to atomically delete the SA and then
add it back with new information). Similar feature is also needed for
the implicit address updating needed for NAT traversal, where we need
to update the UDP encapsulation addresses and ports.

----------------------------------------------------------------------

Following text should be added to section 3.10.1 after
HTTP-CERT-LOOKUP-SUPPORTED:

----------------------------------------------------------------------

	SOURCE-ADDRESS-CHANGED		   	24587

            This notification is sent when the other end has changed
            its IP-address and wants the responder of this
            notification to update the IKE SA remote peer address and
            port. When this notification is received the host MUST
            do the dead peer detection against the address given in
            this payload, and if that is successful then the IKE SA
            peer address and all the child SA tunnel endpoint
            addresses MUST be updated to new address. This
            notification is not used in the NAT traversal case, as the
            host behind NAT does not know when its address changes.
            The data associated with this notification is 2 byte port
            number and 4 or 16 byte IP-address.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Mar 2003 18:54:41 +0100

port).

=> note that when NAT-T is not activated we need an explicit protection
of the peer addresses (notifications like NAT-DETECTION-*-IP carrying
the full address and port) so the only guy who can put fake new addresses
is the peer.

   The explicit address update is done by sending
   SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
   inside, to the other end.

=> so new port and address don't need to be inside the notification
because they are inside the (protected) message.

   This notification can be send either using
   the old or new address, but the sender MUST be able receive in the new
   address before sending this out.
   
=> I disagree: there is no problem to require they are sent using
the new address.

   When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process
   MUST check that the other end can receive the packets sent to new
   address, by sending empty notification to the peer addres and port
   given inside the notification (not the UDP outer address).

=> I disagree: this return routability check should not be mandatory,
i.e., one MAY trust its peer. But IMHO it should be explained (as it
adds in fact nothing in the protocol it is free) and a config knob
should enable it. We have to provide the default value for this knob,
I am in favor of ON, i.e., perform the check by default.

   When the
   host requesting the change replies to that notification, and proofs
   that it can actually receive packets sent to that address the actual
   change should take effect.

=> fine

   This change affects the IKE SA used to
   receive the notification (i.e all future exchanges started on that IKE
   SA will use this new address) and all child IPsec SAs created by this
   IKE SA (i.e tunnel endpoint updated to new address).
   
=> I disagree: we need more fine grain stuff for multi-homing.
What I propose is to put the list of affected SAs in the notification
with an "all SAs" flag which does exactly what you describe with
a restriction for proxy case SAs which must be never affected.

=> is this text really useful?

=> agreed. IMHO this feature should be accessible from the outside of
the IKE implementation too.

   

               This

=> with the mandatory peer address protection when NAT-T is not activated
this statement is no more useful (because NAT-T and peer address protection
are exclusive and one of them is mandatory after the IKE_SA_INIT exchange).

I'll update my address management proposal (remove all the NAT-T stuff
and adopt a NAT-T vs. other case style) but IMHO we should put our
efforts on the things to clarify in the current draft, i.e., everything
about NAT-T & address management at the exclusion of the explicit
mechanism itself.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Mar 2003 18:56:45 +0100

=> A question "en passant": is a payload more appropriate?
(I can't find a rationale about payload vs. notification, the
only argument is payloads can be made critical...)

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 23 Mar 2003 20:02:20 +0200

> only argument is payloads can be made critical...)

The current draft seems to be using notifications for all this kind of
things, so thats why I selected that too. I think notifications are
fine in this kind of cases. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 23 Mar 2003 20:01:30 +0200

> the full address and port) so the only guy who can put fake new addresses

Yep, that is the reason for the SOURCE-ADDRESS-CHANGED notification
(i.e it says the address have changed, and the new ones are here). 

> because they are inside the (protected) message.

The new address and port need to be somewhere in the protected
message, thus they do need to be in some notification. I do not want
to reuse the NAT-DETECTION-*-IP for them, so it is easier to simply
put them to this notification. 

> => I disagree: there is no problem to require they are sent using

To be able to respond the return routability check we need to be able
to receive in the new address. 

> I am in favor of ON, i.e., perform the check by default.

I think it is mandatory. Note, that this is protecting another kind of
attack:

Lets take example. www.videos.cnn.com is offering HDTV level video
streams, but only with oppurtunistic encryption. Alice connects to
this service and starts video transfer from the www.videos.cnn.com.
After the video stream is going Alice, decides that he wants to really
be Malice, and sends authenticated SOURCE-ADDRESS-CHANGED packet to
the www.videos.cnn.com and says that his new address is Bob's address.

If the www.videos.cnn.com does not do the return routability check
then it will diver this 10 MBit/s video stream from Alice/Malice to
the Bob's ADSL line blocking it completely.

If the Bob is smart enough to be running IKEv2 and IPsec, he can
recover, but if he does not know anything about IKEv2 and IPsec only
think for he to do is to call the cnn and ask for their help to stop
the sending the video feed. If he supports IKEv2 he will be seeing
traffic to unknown SPI, thus he will send unauthenticated IKEv2
notification to the www.videos.cnn.com about invalid SPIs and when the
www.videos.cnn.com receives that, it will start dead peer detection to
see if the IKEv2 SA is still up. Bob will not reply to that and after
IKE timeout the www.videos.cnn.com will drop the IKEv2 SA, IPsec SA
(i.e the attack stops). 

> => I disagree: we need more fine grain stuff for multi-homing.

Do we? I think it is easier to gain that with multiple IKEv2 SAs each
having the IPsec SAs that are tied together. 

> a restriction for proxy case SAs which must be never affected.

I do not think we want to put that in there now. I think we can
postpone that until later. 

> => is this text really useful?

Hmmm... it seems to be little unclear. The thing I was trying to say
there is that the IKEv2 mandatates that if you have one exchange going
out you must be able to process another exchange coming in. I.e when
you send SOURCE-ADDRESS-CHANGED notification to the other end and the
other end does the return routability check (using informational
exchange and notifications), then you must be able to reply to that.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Mar 2003 20:27:48 +0100

=> more I think about this, more I believe notifications are fine for
peer address protection but a payload is better for peer address update.
But it is perhaps more than a matter of taste so I wait for a good argument...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Mar 2003 22:15:45 +0100

=> what I try to mean is the peer address must be protected in all
messages when NAT-T is not activated (i.e., no NAT was detected).
Of course this is even more important when a peer address update
notification or payload is in the message.

   message,

=> I agree and I've added more.

   thus they do need to be in some notification. I do not want
   to reuse the NAT-DETECTION-*-IP for them, so it is easier to simply
   put them to this notification. 
   
=> the reuse of the NAT-DETECTION-*-IP was a possible choice but
we decided to split NAT stuff and mobility/multi-homing stuff.

   
=> I was not clear enough: IMHO we should require the peer address update
stuff be sent using the new address.

   

=> you've only shown the default must be to perform the test.
But in a mobility context it can be better to trust the peer and
to avoid an extra round-trip time (we already had this discussion
for mobile IPv6 in its list), and in a multi-homing context the new
address can be already known to be one of the valid addresses of the
peer. So I am only in favor of a mandatory support and to perform
the check by default.

=> this kind of address stealing was discussed during months in the
mobile-ip mailing list so we have now a good idea of the tradeoff.
   
   > => I disagree: we need more fine grain stuff for multi-homing.
   
   Do we?

=> yes, there are some cases in multi-homing where one'd like
to setup one IKE SA to negociate IPsec SAs with different
endpoint addresses. With fine grain address update, this can be
easily done.

   I think it is easier to gain that with multiple IKEv2 SAs each
   having the IPsec SAs that are tied together. 
   
=> we should give the choice. And multiple IKEv2 SAs don't work
with INITIAL-CONTACT, etc. I really believe fine grain is useful
but we can poll the multi6 WG if you'd like.

   
=> the whole explicit update mechanism is portponed...

=> so we agree there is a problem with the wording.

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Mar 2003 22:45:43 +0200

Tero, your text looks good and I like this. I'm OK with
notification approach. I also agree with your approach
to require the routability test everytime. There are
situations where you could avoid it, but imho SHOULD
is the right keyword right now; folks that want to work
out optimized signaling sequences can do the work on their
or later to figure out in which cases you can actually
leave it out. Finally, its good to allow the notification
to be sent from either the old or the new address; the
former may make sense when you know beforehand that you
will move.

Nits:

- s/mobile-ip/mobility/
- s/can be send/can be sent/
- s/ip-address/IP-address/ (or IP address)

Jari

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Mar 2003 23:23:06 +0100

=> your position is not sound: if you allow an update for
a future movement ("Finally, ...") then the mandatory routability
check won't work.

Regards

PS: it is too soon to discuss this, the urgent stuff is to have
a good document for IKEv2 out, and we agreed to postpone the
explicit update mechanism.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Mar 2003 00:38:21 +0200

> a future movement ("Finally, ...") then the mandatory routability

Oh, I am assuming the routability test is still done with the
new address. Just that the update source address can be chosen
freely (either old or new). Granted, if you send the update
you will have to be ready then or real soon to receive the test
packet. But at least implementations have some freedom to figure
out how to do this. And there are no specific reasons to prohibit
this.

Jari