[IPsec] Potential issue with draft-ietf-ipsecme-ikev2-intermediate

[Valery Smyslov <[e-mail]>]

Hi,

I have had off the list discussion with Tobias Brunner and he has pointed out to one potential issue
with draft-ietf-ipsecme-ikev2-intermediate. Currently the authentication of IKE_INTERMEDIATE 
exchanges is performed as follows:

   InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
   ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth

   IntAuth =  IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]]

   IntAuth_1 = IntAuth_1_I | IntAuth_1_R
   IntAuth_2 = IntAuth_2_I | IntAuth_2_R
   IntAuth_3 = IntAuth_3_I | IntAuth_3_R
   ...

   IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
   IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P])
   IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P])
   ...

   IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
   IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P])
   IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P])
   ...

So, a new blob IntAuth is added to signature or MAC calculation.
Note, that the size of IntAuth blob depends on the number of IKE_INTERMEDIATE 
exchanges that took place: each IKE_INTERMEDIATE exchange increases it by the 
2x <size of prf>. 

The potential problem with this scheme that Tobias pointed out to is that
if the number of IKE_INTERMEDIATE exchanges is controlled by the initiator
(this is not true for draft-ietf-ipsecme-ikev2-multiple-ke, but may be true for 
other applications of IKE_INTERMEDIATE), then malicious initiator
may mount a memory exhaustion attack on responder by performing a large number
of IKE_INTERMEDIATE exchanges. 

Besides this attack (which is more a theoretical concern, since the size of prf is pretty 
small and the number of IKE_INTERMEDIATE exchanges will not be counted by 
thousands or even hundreds in any case), the inconvenience of the current scheme for 
the responder is that in case it uses some HSM with limited internal storage 
for storing intermediate IntAuth_* and it doesn't know beforehand the number 
of IKE_INTERMEDIATE exchanges (again, this is not true for draft-ietf-ipsecme-ikev2-multiple-ke, 
but may be true for other applications of IKE_INTERMEDIATE), then the internal resources
of this HSM will be wasted. Again, this is more a theoretical concern, since 
IntAuth_* are not secret and can pe pulled from HSM and stored in main memory.

The bottom line. The problem that IntAuth is growing with each IKE_INTERMEDIATE
exchange do exist, but in my opinion, the potential bad consequences from it 
are mostly theoretical. That said, we can fix this problem by re-defining the
IntAuth calculation as follows (the scheme suggested by Tobias):

 InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
 
IntAuth =  IntAuth_N_I | IntAuth_N_R
 
IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
IntAuth_2_I = prf(SK_pi_2, IntAuth_1_I | IntAuth_2_I_A [| IntAuth_2_I_P])
IntAuth_3_I = prf(SK_pi_3, IntAuth_2_I | IntAuth_3_I_A [| IntAuth_3_I_P])
...
IntAuth_N_I = prf(SK_pi_N, IntAuth_N-1_I | IntAuth_N_I_A [| IntAuth_N_I_P])
 
IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
IntAuth_2_R = prf(SK_pr_2, IntAuth_1_R | IntAuth_2_R_A [| IntAuth_2_R_P])
IntAuth_3_R = prf(SK_pr_3, IntAuth_2_R | IntAuth_3_R_A [| IntAuth_3_R_P])
...
IntAuth_N_R = prf(SK_pr_N, IntAuth_N-1_R | IntAuth_N_R_A [| IntAuth_N_R_P])

This will make the size of IntAuth blob constant regardless of the number of 
performed IKE_INTERMEDIATE exchanges.

The draft draft-ietf-ipsecme-ikev2-intermediate has passed WGLC and is now 
waiting for AD review. There are few interoperable implementations,
but none are used in production yet (to my best knowledge).

So, the question to the WG is - what should we do with this:

1. Re-define calculation of IntAuth to make it constant in size.
     This will most probably require another WGLC and will break
     interoperablity of existing products. The latter seems not so 
     important (no product has been released yet), but the former 
     may delay publication process.

2. Leave calculation of IntAuth as is and add some text to the
    Security Considerations section that describes potential 
    problems and makes advise to the responder (e.g.
    limit the number of accepted IKE_INTERMEDIATE exchanges).
    This will not change bits on the wire and hopefully 
    will not require another WGLC.

3. Ignore this issue (do nothing).

Opinions?

Regards,
Valery.