Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

"Valery Smyslov" <smyslov.ietf@gmail.com> Tue, 09 April 2019 07:20 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF291205FB; Tue, 9 Apr 2019 00:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.488
X-Spam-Level:
X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnU6cO1j6SZk; Tue, 9 Apr 2019 00:19:58 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182AB1207AC; Tue, 9 Apr 2019 00:19:58 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id y13so19397422wrd.3; Tue, 09 Apr 2019 00:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=PA45xlf+9vBNjzATQsAUdZfnB4gN19VxAzADlhUi1Y4=; b=AvLs+CthpHp486lY0J6Gk5OZu9J/cdKkSQvLJpKFy5XeyDcwUoKQQ2V9ipu9wDb+QH R4WMCQB+3kXpJyd1sHyvOdKPCuZ7oozsEj8rUdtz3RE2t6UVTGGqrxv9H2VtuqCxTtak oCwPsAwgtTnCiOG635TCqwSK120lkdFEb/XOyvbuXACdzG5HhOW2kknBCgYf264kgz1A 6OnUHBr3PXCKd5ygODnUt/AmgLTMLjHB/ch2SFFCaRDMCtBG9oLb61PZKR0fniaaVMtA lK2+yQvrk4LVHzn+yNpvVw2XMWO5YTvU7D6y1AzcOZukkl7GXycG3RCykvrj8FMtauil jMYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=PA45xlf+9vBNjzATQsAUdZfnB4gN19VxAzADlhUi1Y4=; b=jcAKhGE1aIJNejFAR/zJxy2ggH52g/KxF2yBRgUrpOgMZmwgPLwzLlcLyL5/E0OyWo P9atwUlAx/Qa5ulpAuSQdi3cgKjP0oIitTQDff+DvgQRN/M0BEuauM+nhshgXDd0Heam wtWT88ZCpozp8fA8um5ViXUXb+ICitwwLxOrAmvzaMRLQff30KDvjPa3vx4ls3rLQH7T RUQXsWtPVnmjmhupjZI+WqnnV+FkZ38FZJV7a5uvJHRJdiWot0TsAF2zS35nNRv4Q79D Yhcfd85PLLH/S4GaGGB1mTZTmUGVRNvqG0tCjJWB0SMCOoUrGsIL+1sWNtoMMPh37yLz yw4A==
X-Gm-Message-State: APjAAAWeMSdVfkj97yYu54VtsQJJVbAIgjI9ctKrjBW19msKyyiOGrgP SLXg62kSft2OB965lPhkvZNuIqEa
X-Google-Smtp-Source: APXvYqzmYxJSpl2SFT8Bjz1GyYf9YsFhAIeo27nn3IO/N5u0Effo6kFclDxxJz4UYJKgB/2JDH1L5w==
X-Received: by 2002:a5d:4a4d:: with SMTP id v13mr22295877wrs.169.1554794396203; Tue, 09 Apr 2019 00:19:56 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i28sm92894350wrc.32.2019.04.09.00.19.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Apr 2019 00:19:55 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Heider' <heidert@nm.ifi.lmu.de>, 'IPsecME WG' <ipsec@ietf.org>
Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org, stefan@gazdag.de
References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de>
In-Reply-To: <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de>
Date: Tue, 09 Apr 2019 10:19:47 +0300
Message-ID: <02e801d4eea4$9db3cac0$d91b6040$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E9_01D4EEBD.C30BB120"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvnwHW2sz0Af2jPnul4b4PUA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/TQTo55nodQFZ4XdLamC_Metr4uI>
Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 07:20:01 -0000

Hi Tobias,

 

thank you for very comprehensive side meeting report. Sorry for late reply, see my comments inline.

 

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tobias Heider
Sent: Wednesday, March 27, 2019 8:30 PM
To: IPsecME WG
Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org; stefan@gazdag.de
Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

 

Hi,

we had a side meeting today where some of us shared our experiences implementing this
draft and we had the chance to discuss the future of this draft with the authors.
Here's what we have talked about and our results:

#1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:

The current draft proposes to send a pair of new nonces in every subsequent IKE_INTERMEDIATE exchange.
We agreed that none of us sees any obvious security problems with only using the nonces exchanged in 
IKE_SA_INIT, but we should try to get this confirmed by cryptologists (maybe CFRG can help).

 

          Since it mostly concerns security, I’d rather let cryptographers to decide.


#2 Using a single IKE_INTERMEDIATE to transport all additional keys

One single big IKE_INTERMEDIATE message that transports all additional key exchanges would be enough to
allow big keys to be fragmented. The main problem of this approach is that fragmentation handles lost 
fragments by resending all fragments. There is no way of requesting retransmission of a single fragment.
This may turn out to be a problem, which is why each new key is sent in a separate IKE_INTERMEDIATE.

 

          True, that’s why we use an approach when one IKE_INTERMEDIATE conveys one QSKE.

          I don’t think it makes implementations substantially more complex – 

          if you can do one IKE_INTERMEDIATE, it’s not difficult to do more than one.

          What about delay, it’s a complex matter – whether sending large fragmented

          message with one round trip is better that sending several smaller messages 

          with several round trips.


Another solution might be to change fragmentation to allow retransmission of single fragments.

 

          Actually, it’s not easy to achieve and would have required to change the core IKE logic.

          The problem is on the return path – how the initiator would request resending

          a single fragment if it is lost in the response? This would have required to 

          significantly complicate IKE’s core, and I don’t think we are in a position to do it.


#3 Using a reserved field to avoid 7 new transform types

It was discussed whether it makes sense to use a reserved field in the transform substructure header
to combine transforms of the same transform type (e.g. Diffie-Hellman group) with logical AND instead of OR.
We agreed that the current solution is less work to implement and using the reserved field offers no
functional benefit.

 

          Yes, we reused existing functionality.



#4 Big Keys (e.G. Classic McEliece)

In general there was consensus that we should find a way to enable the use of McEliece keys.
The problem is that McEliece keys are >1MB in size and thus can not fit into the KE payload
(which has a 16 bit size field).

The solution we came up with is fragmenting a single key over several KE payloads which are transmitted
in a single IKE_INTERMEDIATE message that can be fragmented over several udp datagrams using
IKEv2 fragmentation:

HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} -->
       <-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)}
 

This approach is only limited by the size field of the IKEv2 header, which is 32 bit.

 

          To be accurate, there is another limitation for this approach.

          IKE fragmentation allows to have up to 2^16 fragments, so depending

          on the fragment size there is a limit on the size of IKE message 

          that can be fragmented. As far as I know many implementations

          use fixed fragment size of 576 bytes. If we subtract from this 

          value the size of IP, UDP, IKE Header, IKE trailer etc., it’s about 

          ~500 bytes of useful data, so the original KE must be less than

          ~32MB. I hope it’s enough for any sensible key exchange method,

          including McEliece. For IPv6 fragment size is usually 1280 bytes,

          so this limitation would be relaxed a bit in case of IPv6.


#5 Rekeying and CREATE_CHILD_SA

Nonces should be handled as said in #1.
The draft does not yet specify how the new SKEYSEED is generated.
We agreed that the best way would be to do this in a single prf (different than in the INTERMEDIATE
exchanges which are "rekeying" incrementally), e.G. :

    SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr)

 

          I’d rather change it as follows:

 

          SKEYSEED = prf(SK_d(old), KE1result | Ni  |Nr | KE2result | KE3result | ...)

 

          This would allow not to keep nonces from CREATE_CHILD_SA until all the additional exchanges are completed

          and instead use the running prf state. 

          In case each additional exchange uses its own nonce (as currently specified)  it would be:

 

          SKEYSEED = prf(SK_d(old), KE1result | N1i  |N1r | KE2result | N2i  |N2r | KE3result | N3i  |N3r |...)

 

          This formulas can also be used in case of creating/rekeying IPsec SA:

 

          KEYMAT = prf+(SK_d, KE1result | Ni  |Nr | KE2result | KE3result | ...)

          or

          KEYMAT = prf+(SK_d, KE1result | N1i  |N1r | KE2result | N2i  |N2r | KE3result | N3i  |N3r |...)

 

The use of INFORMATIONAL exchange for the additional key exchanges was criticized.
Several alternative designs were discussed, here's the most important ones:

Design 1: Sending all in a single exchange:

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4}

Problems include that the initiator might generate keys that are then not accepted by the responder.
Also the message would probably be very big, so the same problems as in #2 apply here.
It was discussed what happens if the responder does not accept the proposal.
As in normal IKEv2 the INVALID_KE notify can be sent by the responder and that CREATE_CHILD_SA
has to be redone with the new knowledge of what the responder supports.

 

          True.


Design 2: Single additional INFORMATIONAL

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)}

HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->
    <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4}

Implementers might have problems with the complexity of using the (link1) cookie
values as well as with the use of INFORMATIONAL for yet another thing.

 

          I think that if implementation can do one additional INFORMATIONAL,

          it’s not difficult to do several of them. So I see no substantial

          advantages of limiting the number of trailer exchanges to 

          exactly one.


          Regards,

          Valery.


Feel free to correct us or comment if we made a mistake or missed something important!
Thanks to everyone for joining the conversation!

Regards,
Tobias and Stefan