[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
peer address protection
The peer addresses are not protected in IKEv2 and are not clearly
protected in IKEv1 (in fact many implementations loosely bind them
to the ID or to a CERT subject name so attacks work only in the
road warrior case which of course conflicts...).
I propose a very simple scheme:
- the first exchange (IKE_SA_INIT) is done using UDP port 500
(common case) or UDP port 4500 (if someone believes there should
be a NAT in the path). The NAT detection, using NAT_DETECTION_*_IP
notifications, MUST be performed in this first exchange.
- First case: a NAT is detected and NAT traversal is enabled:
IKE and IPsec SAs run over UDP port 4500, implicit address update
is enabled ONLY for the peer(s) which is behind the NAT (i.e., the
address of a peer which is not behind a detected NAT is not allowed
to change). This implicit address update mechanism SHOULD be supported
and when it is triggered a check MUST be performed between the new
address and the corresponding NAT_DETECTION_*_IP initial notification:
if the addresses are the same (i.e., the detected NAT has disappeared)
we fall into the third case or the IKE SA SHOULD be closed and
reopened over UDP port 500.
- Second case: a NAT is detected and NAT traversal is disabled:
the connexion MUST be rejected.
- Third case: no NAT is detected and for some reasons the initiator
wants to run over UDP port 4500. It MAY keep the UDP port 4500
but as there is a bidding down attack against performances (NAT
traversal has a cost, note that there is no security problem because
as no peers are behind a NAT the implicit update mechanism MUST
NOT be allowed) so a SHOULD is needed for the last case.
- Fourth/last case: no NAT is detected: IKE and IPsec SAs SHOULD be
run over UDP port 500 and peer addresses MUST be protected using
PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications
included in the encrypted payload of all messages.
The concrete proposal for these notifications are:
<to be inserted at the end of 3.10.1>
PEER_ADDRESS_SOURCE 2458X
This notification is used to protect the source peer
address against en route modifications. It includes the
address family (from IANA Address Family Numbers, IPv4 is
1 and IPv6 2) on 16 bits, followed by the source port on
16 bits and the peer source address. It MUST be in an
encrypted payload. At least one PEER_ADDRESS_SOURCE
notification MUST be included into each message after
the first exchange when no NAT has been detected.
When multiple PEER_ADDRESS_SOURCE notifications are
included, they encode its whole peer source address
set, but the first one MUST be for the used source
address. To allow the reduction of the peer source
address set to one address, an address MAY be repeated.
In case of a mismatch between the source address and the
corresponding peer address notifications, there is a
dangling update or an attack. If the possibly compromised
message is a new request, its content MUST be ignored and
a warning notification sent, but the message counter MUST
be incremented in order to accept next requests. If it is
a retransmitted request, the cached reply MUST be sent. If
it is a reply, the corresponding request MUST be retransmitted.
PEER_ADDRESS_DESTINATION 2458X
This notification is used to protect the destination peer
address against en route modifications. It includes the
address family (from IANA Address Family Numbers, IPv4 is
1 and IPv6 2) on 16 bits, followed by the destination port
on 16 bits and the peer destination address. It MUST be in
an encrypted payload. At least one PEER_ADDRESS_DESTINATION
notification MUST be included into each message after
the first exchange when no NAT has been detected.
When multiple PEER_ADDRESS_DESTINATION notifications are
included, they encode its whole peer destination address
set, but the first one MUST be for the used destination
address. To allow the reduction of the peer destination
address set to one address, an address MAY be repeated.
In case of a mismatch between the destination address and
the corresponding peer address notifications, there is a
dangling update or an attack. If the possibly compromised
message is a new request, its content MUST be ignored and
a warning notification sent, but the message counter MUST
be incremented in order to accept next requests. If it is
a retransmitted request, the cached reply MUST be sent. If
it is a reply, the corresponding request MUST be retransmitted.
NOTES:
- can the "first one MUST be for the used source address" be a problem,
i.e., should we use a SHOULD or a MUST? Note that the NAT detection
gives the used address and IPsec assumes the source (and destination)
addresses are stable.
- there is no defined warning in case of address mismatch, so please
add after:
PEER_ADDRESS_ALERT 2458X
This notification is used to signal possible problems
with peer addresse. For instance it MUST be included in
replies when a new request has been received with a
modified en route peer address and was ignored.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: as an implementor I clearly chose simplicity over message size!
The remaining stuff is for 2.11 (address and port agility) which needs
to be extended and of course for 2.13 (NAT traversal) but for the last
thing I'll wait for Tero's new wording integration. The introduction
of this message can give a good idea of my current opinion...
PPS: an overbroken NAT can mess all attempts to run IKE over UDP port 500
so we have to allowed both to run IKE over UDP port 4500 (which is an
optimization if there is a NAT) and to keep the port 4500 if the NAT
doesn't show itself.