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

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

Hi Tero

So I’m not a big fan of the interim exchange (Scott had suggested something similar).

I would imagine that it’s going to decrease the tunnel setup rate on VPN GW’s.

Adds at minimum another round trip, which could be >two if the QS blob isn’t correct or many more if fragmentation.

It seems to be a large change to what’s there today.

Does not allow for a 1-1 swap for the DH value today to something that is QS.

On a more positive note I like the idea of the incrementing message ID’s for re-transmissions. I had a similar idea myself ☺

As mentioned before, if the issue is with sending these QS blobs is the size. At the moment CJ has given some indication of the sizes, however what is going to be used isn’t decided. 

With regards to sending the QS blob using IKEv2 fragmentation. Unless this is sent after authentication occurs it still allows for an attack whereby someone can send up to 

 HDR(PRE_AUTH, MID=1),
           SKF(NextPld=0, Frag#=m-1, TotalFrags=m)

To exhaust the receivers buffers..

cheers

On 09/08/2017, 11:08, "IPsec on behalf of Tero Kivinen" <[e-mail] on behalf of [e-mail]> wrote:

    Cen Jung Tjhai writes:
    >>And I think if the IKE_SA_INIT messages grow too large with QSKE,
    >>then it’s better to develop generic fragmentation mechanism for
    >>IKE_SA_INIT, rather than making it specific for fragmenting QSKE
    >>blobs. Generic mechanism would allow to reuse it in case we’ll have
    >>to include other large payloads in initial messages.
    >
    > Yes, while a generic mechanism would allow it to be reused, it
    > sounds like a different draft all together. It could result in a
    > very complex change in the protocol. Furthermore, we would like to
    > support QSKE blob that is larger than 64KB in size, hence we
    > fragment it in that way. 
    
    Actually I think it would be better NOT to change IKE_SA_INIT at all,
    but instead add new exchange between the IKE_SA_INIT and IKE_AUTH.
    
    I.e., lets have following exchange:
    
    Initiator                         Responder
       -------------------------------------------------------------------
       HDR(IKE_SA_INIT, MID=0), SAi1, KEi,
           Ni, N(IKEV2_FRAGMENTATION_SUPPORTED),
           N(PRE_AUTH_SUPPORTED)  -->
    
                                    <--  HDR(IKE_SA_INIT, MID=0), SAr1, KEr, Nr,
    				         N(IKEV2_FRAGMENTATION_SUPPORTED)
                                         	 N(PRE_AUTH_NEEDED), [CERTREQ]
    
       HDR(PRE_AUTH, MID=1),
           SKF(NextPld=PLD1, Frag#=1, TotalFrags=m)
           {...} -->
       HDR(PRE_AUTH, MID=1),
           SKF(NextPld=0, Frag#=2, TotalFrags=m)
           {...} -->
       ...
       HDR(PRE_AUTH, MID=1),
           SKF(NextPld=0, Frag#=m, TotalFrags=m)
           {...} -->
    
    				<-- HDR(PRE_AUTH, MID=1),
    				        SKF(NextPld=PLD1, Frag#=1,
    					    TotalFrags=m)
    			                {...}
    				<-- HDR(PRE_AUTH, MID=1),
    				        SKF(NextPld=0, Frag#=2,
    					    TotalFrags=m)
    			                {...}
                                ...
    				<-- HDR(PRE_AUTH, MID=1),
    				        SKF(NextPld=0, Frag#=m,
    					    TotalFrags=m)
    			                {...}
    
       HDR(IKE_AUTH, MID=2),
           SK {IDi, [CERT,] [CERTREQ,]
               [IDr,] AUTH, SAi2,
               TSi, TSr}  -->
    
                                    <--  HDR(IKE_AUTH, MID=2),
    				         SK {IDr, [CERT,] AUTH,
                                                 SAr2, TSi, TSr}
    
    I.e., we run normal IKE_SA_INIT with message ID of 0. It negotiates
    the fragmentation (IKEV2_FRAGMENTATION_SUPPORTED), so all further
    exchanges after IKE_SA_INIT can use fragmentation.
    
    Then we do another exchange before the IKE_AUTH, i.e. we do PRE_AUTH
    exchange before IKE_AUTH using message id 1 (or even message ids 2, 3,
    4, etc, as many as are needed). This step does the large blob exchange
    neede for the IKE_AUTH. As these are normal fragmented IKEv2 message,
    i.e. there is request and there is reply. What goes in there is
    most likely using some new payload number to transfer the QSKE data in
    both directions.
    
    Note, that IKEv2 messages are limited to 4GB in size, and one payload
    inside IKEv2 message is limited to 64kB in size, so if larger than 64k
    objects need to be transmitted, it can be transmitted using exactly
    one IKEv2 message, having multiple payloads in it. On the other hand
    as fragments are not individually acknowledged, we do not want to
    transfer too big messages using it, so it might be better to allow
    multiple PRE_AUTH message exchanges before moving to the IKE_AUTH.
    This means that the PRE_AUTH exchange most likely needs to have some
    way of telling the other end when it is done, and when to move to
    IKE_AUTH.
    
    IKE_AUTH then would be just normal IKE_AUTH.
    
    The fact whether we need the PRE_AUTH exchange can be negotiated in
    the IKE_SA_INIT, either using transform types in SA payload, or using
    the notify payloads.
    
    Also if we split data to less than 64k chunks anyways, it might also
    be better not to use IKEv2 fragmentation, but instead just send
    several PRE_AUTH exchanges instead.
    
    Note, that the PRE_AUTH happening between IKE_SA_INIT and IKE_AUTH
    would be encrypted, and MACed, but it WILL NOT be authenticated, i.e.,
    we have not yet authenticated the other peer, and we will not include
    those octets to the AUTH payload calculations, so they will not be
    authenticated in AUTH phase, like the IKE_SA_INIT contents will be
    authenticated.
    
    I think this kind of step between IKE_SA_INIT and IKE_AUTH might be
    easiest and most generic way of transferring the QSKE data. We will be
    transferring large amount of data anyways, so trying to put it part of
    IKE_SA_INIT is not useful, and trying to play around with cookies, and
    IKE_SA_INIT modifications is just adding complexity. 
    -- 
    [e-mail]
    
    
    _______________________________________________
    IPsec mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ipsec