DDSSEC_ — Additional Enhancement to Mutual Authentication following ISO/IEC 9798-3 standard

Note: this issue was raised by Cyril Dangerville (THALES).

Despite the enhancement in DDSSEC_-146 the Authentication protocol still has an "identity misbinding issue".

The protocol after DDSSEC_-14 is applied can be summarized as:

Revised (recommended) protocol:

Participant1                                                       Participant2


                               ParticipantDiscovery (pdata)
                  <------------------------------------------------------------

Message 1: 
c_1, Hash(c1), challenge_1
--------------------------------------------------------------------------->

                   Message 2: 
c_2, Hash(c_2) | dh_2 | challenge_1 | challenge_2, 
                  	Sign(Hash(c_2) | dh_2 | challenge_1 | challenge_2 ) )   
       <------------------------------------------------------------------------------

Message 3:
 Hash(c_1), dh_1, challenge_1, challenge_2,
         Sign(Hash(c_1) | dh_1 | challenge_1 | challenge_2)
-------------------------------------------------------------------->

This protocol is vulnerable to Unknown Key Share (UKS), aka identity misbinding attack. Let participant P3 (with c_3 = id_3, etc.) be an attacker in the middle.
P3 intercepts message 1 and replaces with the message below before transfering to P2:

c_3, Hash(c_3), challenge_1

P2 then replies message 2 and P3 transfers the message to P1 unchanged.

P1 replies message 3 but P3 intercepts again and replaces with the message below before transfering to P2:

Hash(c_3), dh_1, challenge_1, challenge_2,
		Sign_P3(Hash(c_3) | dh_1 | challenge_1 | challenge_2)

In the end, P1 and P2 are the only ones sharing the secret (K) based on dh_1 and dh_2 as only P1 and P2 know the private values. However, P2 believes its peer to be P3 since he received (and could validate) only the certificate and signature of P3. Therefore, P2 believes he is sharing a key with P3, whereas he is actually sharing with P1. From then on, any subsequent message arriving to P2 and authenticated under K - or keys derived from it - will be interpreted by P2 as coming from P3. Note that this attack does not result in a breach of secrecy of the key (since the attacker does not learn, nor influence the key in any way), but it does result in a breach of authenticity since the two parties to the exchange will use the same key with different understandings of who the peer to the exchange is.

To avoid this the protocol should be modified to something like this:

Protocol flow:
P1 <- P2: ParticipantDiscovery (pdata)                                                                                             
P1 -> P2: c_1, challenge_1, dh_1
P1 <- P2: challenge_1, c_2, challenge_2, dh_2,
           SignP2(Hash(c_2)|challenge_2|dh_2|challenge_1|dh_1|Hash(c_1))
P1 -> P2: challenge_1, 
            SignP1(Hash(c_1)|challenge_1|dh_1|challenge_2|dh_2|Hash(c_2))

Modify authentication protocol to avoid the Identity Misbinding Attack

The authentication protocol should be modified to make it robust to the Identity Misbinding Attack. The approach shall follow what was suggested in the issue description with some minor additions that make it easier to implement in an interoperable manner.

The modified protocol (including suggested optional properties) is:
The notation [ xxx ] indicates properties that may be present for troubleshooting purposes but otherwise can be omitted.

P1 <- P2: ParticipantDiscovery (pdata)
P1 -> P2: c_1, [Hash(c_1)], challenge_1, dh_1
P1 <- P2: c_2, [Hash(c_2)], challenge_1, challenge_2, dh_2, [Hash(c1)], [dh_1]
          SignP2(Hash(c_2) | challenge_2 | dh_2 | challenge_1 |dh_1 | Hash(c_1) ) 
P1 -> P2: [Hash(c_1)], [Hash(c_2)], [dh_2], [dh_1], challenge_1, challenge_2,     
          SignP1(Hash(c_1) | challenge_1 | dh_1 | challenge_2 | dh_2 | Hash(c_2))