Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
> #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).
Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. There
are multiple candidates in the NIST PQ Project that offer pk+ct sizes of a few
kilobytes. It is likely that some will be standardized. Classic McEliece
performance seems much slower than other candidates as well. Sorry I missed it,
but why was it decided that supporting Classic McEliece is a must?
Panos
From: IPsec On Behalf Of Tobias Heider
Sent: Wednesday, March 27, 2019 1:30 PM
To: IPsecME WG
Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org; ste...@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).
#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.
Another solution might be to change fragmentation to allow retransmission of
single fragments.
#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.
#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.
#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)
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.
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.
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
___
IPsec mailing list
IPsec@ietf.org
https:
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).
#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.
Another solution might be to change fragmentation to allow
retransmission of single fragments.
#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.
#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.
#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)
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.
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.
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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] initial quick review of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00
I was pointed to a new draft: https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 It's goal is to minimize the payloads for rekeying for IKE SA's and IPsec SA's. The use case is like 3gpp use of large amounts of IKEv2 sessions. I think the idea is fine, but I think I would to see it differently implemented. I think the support notify's for this should be exchanged in IKE_AUTH, not in CREATE_CHILD_SA, because otherwise the first rekey will run into issues or has to use the old model, or would be asymmetric wit initiator sending all payloads anyway but responder could omit them. I see two options: Still use the SA payload but use a Traffic Selector Type (eg TS_UMCHANGED) to be able to distinguish between a mistakenly omited TSi/TSr and a purposefully one from this doucment. Completely change the payloads of CREATE_CHILD_SA and make it more generally with some new payload type (eg CHILD_SA_UNCHANGED) that would cover more things that are unchanged (like USE_TRANSPORT, COMPRESS, TFC/padding etc). This format would be so different to also ensure it cannot be confused with regular processing. I would need to think a bit more about the gains and complexity of each of these solutions. I do like the fact that it allows a rekey without allowing to modify anything about the SA other than fresh keys. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", resolved as "Done". URL: https://datatracker.ietf.org/wg/ipsecme/about/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
