Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Valery,
It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is addressed. There is an additional cost of the extra notification message for every initiator that has no-mandatory ppk configured for the responder. In the worst case scenario the responder would need to go through looking up the PPK_id and if that fails then authenticate the auth_data. Even though it is slightly more work for the responder, I don't consider that heavy processing that would introduce attack concerns. 

My concerns is that we might be making it too complicated by potentially introducing two separate SK_p's. From an ops perspective, if we stated the rule that when we want to go postquantum a PPK should be populated on the responder first as Graham and others suggested, then the extra complication of a new notification can be avoided. Violation of that rule would lead to IKE_AUTH failure for that initiator only.

Vukasin,
Any thoughts from an implementer's standpoint? 

Panos

-----Original Message-----
From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov
Sent: Monday, August 21, 2017 10:25 AM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; 'Paul Wouters' <paul@nohats.ca>; ipsec@ietf.org
Cc: 'Vukasin Karadzic' <vukasin.karadzic@gmail.com>
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Hi Scott, 

> > then it has to flip a coin on whether or not to send the PPK_SUPPORT 
> > notify and if it guessed wrong, the AUTH payload on the initiator 
> > will be wrong. Sending the notify commits to using a PPK because the 
> > initiator uses it as input to the AUTH payload.

[...]

> > One way of solving this could be to allow PPK_SUPPORT to have some 
> > notify data, which could for instance be a hash of the 
> > connection/group name used by the responder.
> > Another option is to use the PPK as one of the inputs to some hash 
> > algorithm as PPK_SUPPORT data, so the responder can go through its 
> > list of PPKs to match it back to a connection/group. But we would 
> > need to be sure that this does not open up the PPK to attacks 
> > (classic and
> > quantum)
> 
> That's what we did in our original proposal (actually, it was a 
> function of the PPK itself).  The problems with that were:
> 
> - If we made it a nondeterministic function (that is, include a 
> randomizer), then the server had to do a linear scan over all their known PPKs to find the matching one.
> 
> - If we made it a deterministic function, then someone listening in 
> can trivially determine when we're reusing the same PPK
> 
> (There's also a minor issue of "which hash function to use"; we haven't negotiated any at this time).
> 
> A linear scan over possibly 10,000 PPKs was considered unacceptable.  
> One of our proposals even allowed the server to specify the trade-off between the above two; that was considered too complex.
> 
> I'm not thrilled with Tero's answer of "lets be careful about the 
> order we upgrade things in complex networks", but I don't know how to 
> better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring significant computation on the server side.

One (relatively) simple solution would be the following.

If initiator is configured with PPK, but at the same time its policy marks using PPK as optional, then the initiator can send two authenticators - one using SK_pi' and the other using SK_pi (where SK_pi = prf(PPK, SK_pi')). The one, computed using SK_pi (where PPK is involved) is placed in AUTH payload, and the other, computed using SK_pi' (without PPK) is placed in a new optional status notification NO_PPK_AUTH.

   Initiator                       Responder
   ------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2, TSi, TSr, 
       N(PPK_IDENTITY)(PPK_id), 
      [N(NO_PPK_AUTH)(auth_data)] }  --->

When responder receives this message and cannot find the corresponding PPK based on PPK_id and is configured to allow PPK-less SA, it can still authenticate initiator by using the content of NO_PPK_AUTH. 
In this case the Responder replies with the IKE_AUTH response lacking PPK_IDENTITY to let the initiator know that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without using PPK).

<---   HDR, SK {IDr, [CERT,]
       AUTH, SAr2, TSi, TSr} 

If the responder has the corresponding PPK, then it computes its AUTH payload using SK_pr and includes PPK_IDENTITY notification:

<---   HDR, SK {IDr, [CERT,] 
       AUTH, SAr2, TSi, TSr, 
       N(PPK_IDENTITY)(PPK_id)} 

This solution allows peers to communicate in different settings and to enforce their own policy.
For instance, if the initiator is configured to always use PPK, it won't include NO_PPK_AUTH at all. If responder is configured to always use PPK, it will just ignore NO_PPK_AUTH and return AUTHENTICATION_FAILED in case the proper PPK is not found.

Regards,
Valery.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec