Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

["Graham Bartlett (grbartle)" <[e-mail]>]

Hi

Sorry for the late reply. I’ve replied to where I feel I could add some more context to CJ’s reply.

GB>inline

On 05/08/2017, 14:29, "IPsec on behalf of Cen Jung Tjhai" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Paul,
    
    >>> 4.      The large quantum resistant ‘blob’ of data is only sent when it is known that the peer will accept this.
    
    >>I don't understand this? You mean known by preconfiguration? That would
    >>make migration really difficult and introduce a flag day. It would also
    >>not be true for Opportunistic IPsec, where there is no preconfiguration
    >>between peers.
    
    It's not pre-configuration, but negotiated via a notify payload (QSKE Notify) that is sent in IKE_SA_INIT.

GB> So the QSKE Notify basically tells the peer ‘I’ve got some PQ algorithms that are probably going to be large and these could be used’. I was chatting to Frederic Detienne last night who did raise the point that we didn’t have to use the QSKE Notify, we could just act on the fact that if we receive a IKE_SA_INIT with certain (QCR) groups in transform type 4 that are known to be large, we would naturally fragment these when they are sent in the next round.

   

    >>> 7.      With regards to fragmentation attacks, the use of fragmentation in this idea has the same security as of
    >>> RFC7383. Whereby an attacker that reveals her true IP address can send multiple fragments, but not the >>>complex chain.
    
    >>I'm not sure how that can be, if it is the IKE_INIT that is getting
    >>fragmented.
    
    It's not entire IKE_SA_INIT message that is fragmented. The fragmentation only applies to post-quantum public data, where almost all of them has payload size larger than 1KB. Furthermore, there is a known type of post-quantum algorithm whose payload size is larger than 64KB and there could be more in the future. We think by fragmenting the payload in this way, it is possible to support this kind of algorithm.
    
GB> in RFC7383 an attack is described that can exhaust the receivers resource, where the attacker reveals their IP address;


The following attack is possible with IKE fragmentation.  An attacker

   can initiate an IKE_SA_INIT exchange, complete it, compute SK_a and

   SK_e, and then send a large but still incomplete set of IKE_AUTH

   fragments.  These fragments will pass the ICV check and will be

   stored in reassembly buffers, but since the set is incomplete, the

   reassembling will never succeed and eventually will time out.  If the

   set is large, this attack could potentially exhaust the receiver's

   memory resources.

To perform the same attack, as the quantum resistant ‘blob’ of data is sent after a negotiation, an attacker would need to reveal their IP address (they can not just perform a blond spoofing attack where they spoof another IP address). 


    >>> For devices that are operating in a mesh network, where many devices have multiple peers, where peers are using
    >>> varying QSKE groups. In these instances the QSKE that is preferred by the Initiator might not be available or
    >>> preferred on the Responder. To overcome scenarios where the Initiator will send a QSKE which is large in size and not
    >>> supported by the Responder, (therefore wasting time and resource), the QSKE Notify payload can be used to query the
    >>> responder to determine the supported security association attributes. The QSKE Notify payload is sent by the
    >>> Initiator, which also excludes the QSKE payload (however a single KE payload should be included for backwards
    >>> compatibility). If the Responder supports the QSKE notify payload it replies with the accepted security associations
    
    >>Isn't this all unsafe against downgrade attacks?
    
    If a peer declares support of post-quantum algorithm with QSKE Notify payload, but not sending the post-quantum blob, the other peer shall reject the connection. On the other hand, for backward compatibility, it is up to the initiator to set the fallback policy; does it allow standard SAs or only post-quantum SAs are supported. 

    >>> For implementations that do not support the use of the QSKE, the QSKE Notify payload will be ignored and the IKEv2
    >>> exchange will continue as per RFC7296.
    
    >>What prevents an attacker from stripping out the QSKE Notify payload in
    >>the IKE_INIT request?
    
    If QSKE Notify payload is stripped, the peers won't be able to negotiate post-quantum algorithm for key-exchange, hence it depends on the configured fallback policy.

GB> If an attacker removed the QSKE Notify inline, the exchange would occur as per RFC7296. As we include the RestOfMessage1 in the authentication material check, this would not tally on both peers and authentication would fail. 
    
    >>> The QSKE is nearly identical to the KE payload, however the Fragment bit identifies if the receiver should handle
    >>> this in a different manner to the KE payload. The KE and QSKE are negotiated/advertised using the transform type 4
    >>> (Diffie Hellman groups).  By including the QSKE in the same transform type 4 as classic DH allows for minimal
    >>> configuration changes for current implementations when configuring both DH and QSKE Groups.
    
    >>Can this not be abused for an amplification attack by sending a really
    >>small QSKE payload and causing the responder to send back a large QSKE
    payload in multiple fragments?
    
    In general, QSKE payloads sent by the initiator and responder are of pretty much of equal size. It is possible for an malicious initiator to send a small QSKE payload and expecting the responder to return large multiple fragments QSKE payload. In order to combat, the responder could employ existing mechanisms to minimise the impact of this attack, for example using COOKIE or for more sophisticated attacks, RFC8019. 
    
GB> That’s a great point and yes your right, I guess this could happen (but the attacker would reveal their IP address, which could then be blocked). However I would assume that for these quantum resistant ‘blobs’ there’s a check to ensure that the data is valid or structured. Something like RFC6989 but for the algorithms that are used by the quantum resistant ‘blobs’.
    
    >>Why would the responder reply to two group suggestions with QSKE payloads?
    >>Normally in IKEv2, the initiator sends a list of proposals/options, and
    >>the responder picks one from it.
    
    In order to support "crypto-agility", which allows peers to have flexibility in selecting cipher suites. In this way, peers are able to select a DH combined with multiple post-quantum algorithms. We are not sure how important this feature is, but it would be a great idea to get opinions from the group.
    
    >>> As three groups were used, the keymat is generated with the combination of the output from the three public values.
    
    >>How did the initiator signal support for all groups _and_ support for
    >>combining them? What is gained by combining multiple groups?
    
    The signalling is done via QKSE notify. I appreciate that we have not yet described how this work on the text.

GB> I know Scott Fluhrer also thought about this. For simplicity I suggested that if Quantum Resistant groups are used we naturally allow the Responder to decide how many of the QCR algorithms it wishes to use. I personally think that signalling the use of certain groups of groups could get messy (unless someone develops a simple method to achieve this, which I haven’t seen so far). I personally really like the simplicity of the method that IKEv2 negotiates the transforms to use (just pick one of the following) and for the QC groups we could just extend this to ‘just pick >1 of the following..’.
    
    Best regards,
    CJ
    _______________________________________________
    IPsec mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ipsec