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" 
<ipsec-boun...@ietf.org on behalf of c...@post-quantum.com> 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
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec
    

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to