Re: addresses and IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   This posting points out the tip of a very large iceberg. I think I
   understand some of the issues (but I'm not confident); some seem
   unsolvable; and some raise questions about the design goals of IPsec.
   Attempts to improve things for some scenarios (e.g. Mobile IP) may make
   things worse in others (e.g. Address Translation Gateways).
   
=> IMHO Mobile IP and NATs need the same thing: some "address agility".

   > Each party can get up to 5 addresses:
   >  - the address used for the transport of phase 1 messages (T1)
   >  - the address in the phase 1 identity (I1)
   >  - the address in the party's certificate (C1)
   >  - the address used for the transport of phase 2 messages (T2)
   >  - the address in the phase 2 traffic selector (which replaces IKEv1
   >    phase 2 identity) (I2)
   > (I don't consider the optional IKEv2 phase 2 identity payload until
   > it has an interesting semantic when it is an address identity).
   >
   > A not-really-written-down rule specifies the phase 1 identity must be
   > the subject or an alternate subject of the party's certificate (when
   > certificates are used but in any case the identity and the authentication
   > means must be strongly bound).
   
   You're right that the rules aren't really written down. We tried to copy
   IKEv1 on the theory that people were using it and we didn't understand the
   issues well enough to have confidence that changes would be improvements.
   If there are specific changes or clarifications that you think would be
   useful, please propose them.
   
=> the purpose of my mail was to open the discussion about this kind
of changes/clarifications.

   There is an implicit (or it might in fact be explicit though I couldn't
   find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
   messages associated with an IKE SA will have the same source and
   destination IP addresses. ESP and AH explicitly state that their SA is
   identified by the combination of the Destination IP address and SPI, and
   the only anticipated case for having the source address vary for an SPI is
   for multi-sender multicast.
   
=> I disagree:
 - draft-ietf-ipsec-esp-v3-02.txt (and Stephen Kent's presentation
   at the last IETF) makes very clear that SPI should become the unique
   identifier of a SA at the exception of multicast destination
   (where the issue is not multiple sender but multiple recipients which
    can not enforce the unicity of the SPI).
 - RFC 2401 is very clear about the outer source address of ESP (and AH)
   in tunnel mode: it can be *any* address of the source, etc.
   (cf 5.1.2.1 3 NOTE, 5.2.1, etc)

   The IKEv2 spec doesn't say what an implementation should do if it receives
   a cryptographically valid message from an unexpected source address.
   I suppose it should.

=> this is a point which must be fixed. If we agree it should, the IKE-SA
SPI shall become the way to identify "sessions".

   One possibility is that it could specify that such
   messages are discarded and possibly logged. A second is that they be
   treated as though they were cryptographically invalid. A third is that the
   source address be ignored and the packet treated as though it was received
   from the expected source address. A fourth is that the source address be
   remembered and future messages on the SA be sent to that one.
   
=> only the first and last possibilities have a meaning but
we can not get both.

   Why would it matter? I claim that in all cases except Transport mode ESP
   (which is an ESP issue rather than an IKE issue), no invalid messages can
   be delivered as the result of any of these approaches.

   The reason it might be desirable to accept messages from changing
   source addresses is to allow the other end of an SA to change IP
   addresses mid-conversation without breaking the connection.

=> they are two common cases where this can happen: mobility and NATs.

   This argues for the fourth approach.

=> this is why I'd like to get it (or with the first approach a real
discussion).

   But the fourth approach makes possible a denial of service attack that is
   unacceptable. An attacker need only intercept and prevent delivery of a
   single IKE packet and retransmit it with a changed source IP address.

=> this is not the fourth approach because you've added a NAT traversal
property. For mobility (without NAT traversal capability) the source can
authentify its address, for instance you can imagine the protection in IKEv2
is AH+ESP like in place of ESP like only.

   The other end will begin misdirecting responses and the IKE SA will
   eventually time out.

=> but with very efficient protocols like IKEv2 CREATE-CHILD-SA exchange
to spoof one message is enough.

   If we believe we need to be able to handle the case of a mobile
   SA, I believe we would have to do it with an authenticated message.

=> I believe you mean a message where the source address is authenticated.

   This could be added later, but my going in position would be that
   if either end of an SA changes IP addresses then the SA should be
   broken and renegotiated.

=> this can become incredibly too expensive if this imply to redo
a DH exchange each time a mobile moves or a NAT resets some state.
Another argument is the authentication in ESP/AH should reject any
packet which doesn't come from the right node, so to check addresses
is both annoying (this removes flexibility) and unnecessary (crypto
is more powerful than access list).
I propose to add this question into SOI requirements.

   In that case, it doesn't matter which of the first three
   approaches an implementation takes because it shouldn't happen (and no
   useful attacks could exploit them).
   
=> we have to split attacks into attacks from address agility and attacks
from NAT traversal capability. BTW the second kind of attacks is not
only against IKE/SOI and I am writing an I-D about this.

   Where addresses are important is in the ESP and AH connections tunnelled or
   transported through IPsec SAs. ESP and AH are designed to "transparently"
   secure applications that use existing networking APIs and may trust data
   differently based on the IP address from which it originates (e.g. the Unix
   rtools). For any useful security to be provided, IKE is responsible for
   assuring that the authenticated identity corresponds to the IP address of
   SAs.
   
=> If you apply this to ESP/AH we come back to a previous point,
if you apply this to IKE then "road warriors" may not use IKE.

   How is this possible?

=> the question is more "is this desirable?"
   
   One way is by having the identities in certificates in fact be IP addresses
   rather than names as implied by the quoted text above. Systems may be
   deployed that way, but it would surprise me. More likely is that the
   "Policy Database" installed as part of IPsec configuration contains a table
   matching IP addresses to either public keys or the names that must appear
   in certificates used in IKE. How that policy database would be populated
   and maintained is one of the great remaining mysteries of IPsec. For
   firewall to firewall tunnels, manual configuration works, and I believe
   that's how people do it today. But for end to end IPsec to become routine,
   better techniques will need to be deployed and standardized. It's a much
   harder problem than any already solved in IPsec, so I don't expect progress
   soon. I certainly don't want to hold IKEv2 hostage to solving it.
   
=> IAB recommended to use names in place of addresses, and don't forget
cases like the "road warrior" one.
It seems we are going on the path to separate the identity from the address
but obviously we should not go too far or we'll open the door to new attacks.
Bit I disagree we shouldn't care. And there are many things we can do,
for instance use DNSsec or authentify IKE message headers.

   In tunnel mode, it's the inner IP addresses that must be authenticated.
   They are because they must match the traffic selectors and the traffic
   selectors must match the authenticated names from IKE and in the IPsec
   Policy Database. In tunnel mode, the outer IP addresses are like those of
   IKE... it doesn't matter what we do with them so long as we don't open
   ourselves to denial of service attacks.
   
=> I believe you aggree that today the issue is not really handled
(for instance many "mobile VPN" setups have no provision against
transient pseudo-NAT attacks) and, even more important, users have
no idea of what to do...

   In transport mode, it's the outer IP addresses that must be authenticated.
   This is tricky because they are not cryptographically protected. What
   should ESP or AH do if they receive a transport mode IP packet with IP
   addresses that don't match the traffic selectors? I believe the spec says
   they should throw them away.

=> yes, RFC 2401 5.2.1 has a MUST for this case.

   This will break transport mode SAs if they pass through address
   translation gateways.

=> IMHO this is a good property.

   I believe the right answer to
   this is to always use tunnel mode through address translation gateways.
   Proposals for tunneling through address translation gateways call for use
   of a special tunnel mode that is encapsulated in UDP.
   
=> UDP is another problem which doesn't come from NAT, but for not 1-1
mapping.

   IKEv2 explicitly supports Address Translation Gateways by *not*
   authenticating the outer IP addresses in IKE messages.

=> and this opens the door to the transient pseudo-NAT attack even
when it is known there is no NAT on the path. I am not against the
feature but against to get it by default (and perhaps always) without
proper considerations about consequences.

   This allows
   connections to work even though the outer IP addresses appear different to
   the two ends of the IKE (and presumably also ESP) SAs.
   
   It's not clear what we can or should do to provide better support for ATGs
   or Mobile IP, but I'm open to suggestions.
   
=> I believe we should both provide better support and better graduation
between what is accepted and consequences on possible attacks.
Perhaps the ipsec WG needs a mobility concern from IESG like the security
concerns received by the mobile-ip WG some times ago?

Thanks

Francis.Dupont@enst-bretagne.fr

PS: random ideas about support/attacks:
 - put the address in the identity and check it:
   no support, inflexible but very (too?) secure.
   (I believe this is supported by many IKE(v1) implementations today
    but only testing (or source reading) shows if the check is done)

 - put a FQDN in the identity and verify address->FQDN mapping via DNSsec:
   addresses can be changed if DNS is updated, rely on DNSsec deploiment.
   (perhaps supported by implementations which can get keys/certificates
    from DNS but is it from DNS or from DNSsec?)

 - spit "transport" addresses and identities, never check them but
   don't accept change:
   support NAT traversal but not NAT resets or mobility, vulnerable
   to transient pseudo-NAT attacks on multiple and two way messages
   (seems to be the IKEv2 default)

 - spit "transport" addresses and identities, protect IP headers and
   accept change between "phases":
   support of mobility but not of NAT traversal (i.e. this is the IPv6
   solution), no vulnerability
   (should be considered for SOI? note to put the (new) source address
    inside messages is enough to protect it, this makes "movements" more
    explicit too)

 - spit "transport" addresses and identities, no header protection,
   accept change between "phases":
   support of mobility and NAT traversal and NAT reset, vulnerable to
   transient pseudo-NAT attacks
   (if this is considered for SOI IMHO this should not be the default)