Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi Tobias,
thank you for very comprehensive side meeting report. Sorry for late reply, see
my comments inline.
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tobias Heider
Sent: Wednesday, March 27, 2019 8: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).
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
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi,
little update on the nonces:
Stefan and I have been asking around the CFRG people what they think
about omitting
additional nonces and the consensus seems to be that this is not an easy
question
and that this could probably only be resolved doing formal verification.
Also we were strongly advised to get formal verification for the whole
protocol
including the INTERMEDIATE, and to seek help at CFRG at some point.
We're trying to bring people together who are interested in helping with
this,
If anyone has previous experience with formal verification of secure
network
protocols and wants to join, feel free to contact me.
Regards,
Tobias
On 3/27/19 6:29 PM, Tobias Heider wrote:
> 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
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
On 3/28/19 2:19 PM, Panos Kampanakis (pkampana) wrote: > Thanks Tobias, Valery and Stefan. > > Imo Classic McEliece is impractical for use in live key negotiations in > protocols like TLS, IKE, SSH etc. NIST will standardize more practical and > secure postquantum KEMs and the added complexity for McEliece is not > necessary. I understand that others might want McEliece because they trust it > more. In that case, I suggest the mechanism described in #6 to be a "MAY" in > the draft. > > Panos Hi Panos, as this draft does not specify any new key exchange methods I would not include it in this document at all. Best would probably be in a eventual future draft that also introduces McEliece and/or NTS-KEM transform ID for use with IKEv2. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Thanks Tobias, Valery and Stefan. Imo Classic McEliece is impractical for use in live key negotiations in protocols like TLS, IKE, SSH etc. NIST will standardize more practical and secure postquantum KEMs and the added complexity for McEliece is not necessary. I understand that others might want McEliece because they trust it more. In that case, I suggest the mechanism described in #6 to be a "MAY" in the draft. Panos -Original Message- From: Tobias Guggemos Sent: Thursday, March 28, 2019 4:37 AM To: Panos Kampanakis (pkampana) ; Tobias Heider ; IPsecME WG Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org; ste...@gazdag.de Subject: AW: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt * PGP Signed by an unknown key > > #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? There is no decision made on this, at the end this is a question to be discussed and agreed on in the WG. However, with McEliece being the proposal which is most trusted in the crypto community, there will be people wanting to support it (let it be governmental institutions with strict security requirements). We had "consensus" on: 1) that the draft should support the possibility to exchange McEliece keys without "breaking" the protocol again. 2) we all hope that we won't need it! =) Correct me if I'm wrong. > Panos Cheers Tobias * Unknown Key * 0xC833559F ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hello all, I'd like to add a couple of remarks. 1. There is one more code-based proposal based on Goppa codes and somewhat on McEliece and that is NTS-KEM, I would suppose one of those two will be one of the final standardized algorithms. NTS-KEM has three sets of parameters, one for each of the security 'levels' that NIST proposed, and the first and second set of parameters (for Level 1 and Level 3 security) have significantly smaller keys (though they are still one of the biggest). There is even a document published by Classic McEliece team that compares all important aspects of the proposal ( https://classic.mceliece.org/nist/vsntskem-20180629.pdf) (there is also a response from NTS-KEM team addressing all points from that document). 2. All NIST proposals are K(ey)E(ncapsulation)M(echanism)s. I don't know if it's possible or if it makes sense, but in some use cases (eg. small client - server) it may be useful for a server to store public key from client, so that client doesn't need to each time (eg. for a rekey) calculate a new public key (and send it?), because key generation can be expensive, in case of Classic McEliece key generation in software takes billions (4-6) of cycles, about 2 seconds in ~6,000,000,000 case on a 'Intel Xeon E3-1220 v3 (Haswell) running at 3.10GHz with 32GB of RAM' platform. Maybe that point can be also addressed in the draft. One more remark regarding KEMs, in case of Classic McEliece/NTS-KEM, the initiator would send MBs (eg, 1357824 bytes) of KE payload, while in the other direction the responder would need to send only couple of hundred of bytes (240 bytes) which contain encapsulated secret key. Regards, Vukasin Karadzic ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi everyone, Quoting Tobias Guggemos : > #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? There is no decision made on this, at the end this is a question to be discussed and agreed on in the WG. However, with McEliece being the proposal which is most trusted in the crypto community, there will be people wanting to support it (let it be governmental institutions with strict security requirements). We had "consensus" on: 1) that the draft should support the possibility to exchange McEliece keys without "breaking" the protocol again. 2) we all hope that we won't need it! =) Correct me if I'm wrong. Nothing to be corrected here. I'd like to stress that some parties who participated in the discussion yesterday or in personal conversations have told about the demand for using a rather secure version even if it means more work on extending the protocol. Though there's a few quantum-resistant algorithms that I personally like still McEliece is the one cryptographers are most confident to be secure. There's several use cases relevant to companies and agencies where using McEliece (even this in combination with other algorithms) is the way to go and therefore this should definitely be considered for IKEv2. Kind Regards, Stefan Gazdag ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi, > > > 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? > > There is no decision made on this, at the end this is a question to be > discussed > and agreed on in the WG. > However, with McEliece being the proposal which is most trusted in the crypto > community, there will be people wanting to support it (let it be governmental > institutions with strict security requirements). > We had "consensus" on: > 1) that the draft should support the possibility to exchange McEliece keys > without "breaking" the protocol again. > 2) we all hope that we won't need it! =) > > Correct me if I'm wrong. That was my impression too. In other words - make it possible to handle such extremely long keys in probably suboptimal way, but with minimal possible changes to the protocol. So that those who need them could use them, but no promises that protocol will optimized for them. Regards, Valery. > > Panos > > Cheers Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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? There is no decision made on this, at the end this is a question to be discussed and agreed on in the WG. However, with McEliece being the proposal which is most trusted in the crypto community, there will be people wanting to support it (let it be governmental institutions with strict security requirements). We had "consensus" on: 1) that the draft should support the possibility to exchange McEliece keys without "breaking" the protocol again. 2) we all hope that we won't need it! =) Correct me if I'm wrong. > Panos Cheers Tobias pgp8xQCAiIYeH.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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
_
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
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi Leonie, > Hi, > > The draft specifies how to use additional key exchanges for Child SAs. It > states that if several key exchanges > are negotiated in CREATE_CHILD_SA, key shares are transmitted in a series of > INFORMATIONAL exchanges. > So I was wondering if keys are updated after each INFORMATIONAL exchange, > similar as its done with the > INTERMEDIATE exchange? It's a good question. We haven't discuss this issue yet among authors, but I think there is no reason (and I believe no reliable way) to update the keys used to protect the current IKE SA. Instead, we can just use subsequent Key Exchanges as additional inputs into prf as follows: For IKE SA rekey: SKEYSEED = prf(SK_d_current, KE1 | Ni1 | Nr1 | KE2 | Ni2 | Nr2 ... KEn | Nin | Nrn) For new Child SA or its rekey: KEYMAT = prf+(SK_d_current, KE1 | Ni1 | Nr1 | KE2 | Ni2 | Nr2 ... KEn | Nin | Nrn) where KE1, Ni|r1 - from CREATE_CHILD_SA, other KE and Ni|r - fron subsequent INFORMATIONAL. But I'd rather let cryptographers comment on this and probably suggest better ways to do it. And in any case this should definitely be clarified in the draft, as well as some other things (e.g. how collisions would be handled in this case etc.) > Besides, has anybody experiences with fragmenting INFORMATIONAL exchange? Im > not aware that > INFORMATIONAL exchange has been used to transmit such large payloads before. RFC 7383 explicitly says that if IKE fragmentation was negotiated, then any subsequent protected exchange may be sent in fragmented form. It's true that so far IKE fragmentation was primarily used in the IKE_AUTH exchange, however any compliant implementation must be able to use it in any exchange containing Encrypted payload. Regards, Valery. > Regards, > Leonie > > > -Ursprüngliche Nachricht- > > Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery Smyslov > > Gesendet: Mittwoch, 16. Januar 2019 08:16 > > An: IPsecME WG > > Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org > > Betreff: Re: [IPsec] New Version Notification for > > draft-tjhai-ipsecme-hybrid- > > qske-ikev2-03.txt > > > > Hi, > > > > a new version (-03) of the QSKE draft is published. It contains quite a lot > > of > > changes from the -02 version: > > > > 1. Negotiation method is changed to standard (via new Transform Types in > > SA payload) > > 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is > > addressed > > 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslov- > > ipsecme-ikev2-aux-02) > > 4. IANA considerations section is added > > 5. Temporary IDs for PQ KE methods (using VendorID) are removed > > > > Please, review the draft. Some issues have already been discussed and the > > changes reflect the WG consensus, > > some are new and the text reflects only the authors' current opinion. > > > > Regards, > > Valery (for the authors) > > > > > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > > > has been successfully submitted by C. Tjhai and posted to the > > > IETF repository. > > > > > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > > > Revision: 03 > > > Title:Framework to Integrate Post-quantum Key Exchanges into > > Internet Key Exchange Protocol > > > Version 2 (IKEv2) > > > Document date:2019-01-14 > > > Group:Individual Submission > > > Pages:19 > > > URL:https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme- > > hybrid-qske-ikev2-03.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid- > > qske-ikev2/ > > > Htmlized: > > > https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske- > > ikev2-03 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme- > > hybrid-qske-ikev2 > > > Diff: > > > https://www.ietf.org/rfcdiff?url2=draft-tjhai-ipsecme-hybrid- > > qske-ikev2-03 > > > > > > Abstract: > > >This document describes how to extend Internet Key Exchange Protocol > > >Version 2 (IKEv2) so that the shared secret exchanged between peers > > >has resistance against quantum computer attacks. The basic idea is > > >to exchange one or more post-quantum key exchange payloads in > > >conjunction with the existing (Elliptic Curve) Diffie-Hellman > > >payload. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi, The draft specifies how to use additional key exchanges for Child SAs. It states that if several key exchanges are negotiated in CREATE_CHILD_SA, key shares are transmitted in a series of INFORMATIONAL exchanges. So I was wondering if keys are updated after each INFORMATIONAL exchange, similar as its done with the INTERMEDIATE exchange? Besides, has anybody experiences with fragmenting INFORMATIONAL exchange? I’m not aware that INFORMATIONAL exchange has been used to transmit such large payloads before. Regards, Leonie > -Ursprüngliche Nachricht- > Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery Smyslov > Gesendet: Mittwoch, 16. Januar 2019 08:16 > An: IPsecME WG > Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org > Betreff: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid- > qske-ikev2-03.txt > > Hi, > > a new version (-03) of the QSKE draft is published. It contains quite a lot of > changes from the -02 version: > > 1. Negotiation method is changed to standard (via new Transform Types in > SA payload) > 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is > addressed > 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslov- > ipsecme-ikev2-aux-02) > 4. IANA considerations section is added > 5. Temporary IDs for PQ KE methods (using VendorID) are removed > > Please, review the draft. Some issues have already been discussed and the > changes reflect the WG consensus, > some are new and the text reflects only the authors' current opinion. > > Regards, > Valery (for the authors) > > > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > > has been successfully submitted by C. Tjhai and posted to the > > IETF repository. > > > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > > Revision: 03 > > Title: Framework to Integrate Post-quantum Key Exchanges into > Internet Key Exchange Protocol > > Version 2 (IKEv2) > > Document date: 2019-01-14 > > Group: Individual Submission > > Pages: 19 > > URL:https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme- > hybrid-qske-ikev2-03.txt > > Status: https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid- > qske-ikev2/ > > Htmlized: https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske- > ikev2-03 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme- > hybrid-qske-ikev2 > > Diff: > > https://www.ietf.org/rfcdiff?url2=draft-tjhai-ipsecme-hybrid- > qske-ikev2-03 > > > > Abstract: > >This document describes how to extend Internet Key Exchange Protocol > >Version 2 (IKEv2) so that the shared secret exchanged between peers > >has resistance against quantum computer attacks. The basic idea is > >to exchange one or more post-quantum key exchange payloads in > >conjunction with the existing (Elliptic Curve) Diffie-Hellman > >payload. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi Tobias, thank you for catching this up. It's a leftover from previous version that somehow escaped our attention. We'll fix it in the next version of the draft. Thank you for careful reading, Valery (for the authors). > Hi Valery, > > i think i just found a minor flaw reading through the new version. > The current draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-03) says in > section 3.1: > > > In order to achieve this, the > > IKE_SA_INIT exchange now includes notify payloads that negotiate the > > extra key exchanges to be used. The initiator IKE_SA_INIT message > > includes a notify that lists the extra key exchange policy required > > by the initiator; the responder selects one of the listed policies, > > and includes that as a notify in the response IKE_SA_INIT message. > > I believe this is obsolete and was overlooked in the last change since the > negotiation of additional KEs is now done in the SA payload. > > Regards, > Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Hi, a new version (-03) of the QSKE draft is published. It contains quite a lot of changes from the -02 version: 1. Negotiation method is changed to standard (via new Transform Types in SA payload) 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is addressed 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslov-ipsecme-ikev2-aux-02) 4. IANA considerations section is added 5. Temporary IDs for PQ KE methods (using VendorID) are removed Please, review the draft. Some issues have already been discussed and the changes reflect the WG consensus, some are new and the text reflects only the authors' current opinion. Regards, Valery (for the authors) > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > has been successfully submitted by C. Tjhai and posted to the > IETF repository. > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > Revision: 03 > Title:Framework to Integrate Post-quantum Key Exchanges into > Internet Key Exchange Protocol > Version 2 (IKEv2) > Document date:2019-01-14 > Group:Individual Submission > Pages:19 > URL: > https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > Status: > https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid-qske-ikev2/ > Htmlized: > https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme-hybrid-qske-ikev2 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > Abstract: >This document describes how to extend Internet Key Exchange Protocol >Version 2 (IKEv2) so that the shared secret exchanged between peers >has resistance against quantum computer attacks. The basic idea is >to exchange one or more post-quantum key exchange payloads in >conjunction with the existing (Elliptic Curve) Diffie-Hellman >payload. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
