Re: Adding revised identities to IKEv2

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

<long answer>

 In your previous mail you wrote:

   Francis Dupont wrote:
   >    Oh sure. If I say the entity name is "Uri Blumenthal" - then there
   >    has to be a key/cert associated with that name. As it only matters
   >    for signing the Phase 1 exchange to validate IP address from which
   >    the traffic is originating, for subsequent Phase 2 things.
   > 
   > => this is a typical example of statements I disagree with: in fact
   > signing the Phase 1 exchange doesn't validate IP address.
   
   Why doesn't it? In your opinion,what is missing and how would you
   prefer to validate IP address?
   
=> the IP address can be changed "en route" by an attacker in the path
or the peer can put a rogue IP address. What you validate by the
signature is the name, not the address. Stephen Kent in his message
used the expression "whatever address is asserted by it (the peer)"...

To illustrate the two attacks:
 - for the first one a box placed on the path between peers by an attacker
   maps the peer address in IKE messages to another address, this gives
   three bad effects:
  * someone can illegitimately received the protected traffic
    (usually not a real issue because the traffic is protected)
  * the peer doesn't receive the protected traffic (first DoS issue)
  * a victim can be overloaded by the protected traffic redirected to it
    (second DoS issue).
 - for the second one the peer can usurp the address of another box which
   is, for instance, booting, just for the IKE exchange. After you can
   get any of the previous three effects.

   > IMHO
   > you should agree the level of trust in this "validation" is *not*
   > at the level of trust of cryptographic signatures!
   
   Perhaps I should - but I don't. Try to convince me first, then we'll
   see.
   
=> the address is validated because the exchange is not one-one so
if the peer doesn't receive all the messages it cannot finish the exchange (1)
and of course the peer uses the same address in all messages (2).
(2) is a side effect of the UDP usage (TCP gives this check built-in)
(1) is a "return routability" check which is very weak compared to
a cryptographic signature.
Of course, this comes in addition to the first attack (what I called
"transient pseudo-NAT attack"), so:
 - in some cases, the address should be protected (this is easy to do
   if the address is in a payload covered by integrity check). Note this
   disables the NAT-traversal feature, i.e., we can get either "en route"
   address protection or NAT-traversal, not both.
 - in some cases, the peer should be trusted to have used one of its own
   addresses. IMHO this is not a big issue but if we add a readdressing
   one-one exchange to IKE, we'll get the choice between a full trust
   to the peer about its addresses or a longer exchange with a "return
   routability" check. Same for any kind of readdressing feature in
   rekeying.

Regards

Francis.Dupont@enst-bretagne.fr