Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria
Hi, I do not have the time to answer right now, but I will do so later. Best regards, Tristan Ninet - Mail original - > De: "Tero Kivinen" > À: "Tristan Ninet" > Cc: "Paul Wouters" , "ipsec@ietf.org WG" , > "Olivier Zendra" , > "romaric maillard" > Envoyé: Jeudi 26 Septembre 2019 11:27:08 > Objet: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - > HAL-Inria > Tristan Ninet writes: >> Dear Mr. Wouters, >> >> Thank you for your interest in our work. >> >> > I've read through the paper, and I believe is very much misrepresents what >> > it >> > deems is a DoS attack against the IKEv2 protocol. >> > >> > The DoS attack described seems to think it can change the IP address and >> > cause >> > Initiator to be authenticated by a different peer than intended (ignoring >> > all of >> > IDi / IDr payloads it is relaying). Then the different peer is happy, but >> > the >> > last IKE_AUTH reply to the initiator would signify a failure. Then when the >> > initiator sends an Informational message with a Delete payload and >> > AUTHENTICATION_FAILED notify, the attacker drops the message. Now the >> > different >> > peer has "lost resources" since its IKE SA (and possibly IPsec SA) is up. A >> > proper implementation would send a Liveness probe if its IPsec SA counters >> > remain zero. It would also put an idle limit on an childless SA that >> > resulted >> > from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) >> >> Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT >> request >> by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH >> response >> by m4. >> >> I understand you are saying that authentication of A to C would fail because >> of >> IDi and IDr payloads. > > Normally authentication from A to C will fail because of different > authentication information. I.e., if they are using pre-shared keys > the pre-shared key for A to B is different than A to C (unless B and C > are part of same infrastructure, i.e., load-sharing or high > availaibility pairs). If A is using certificates then usually it has > two different CA infrastructures one for B and one for C, so C will > not accept certificate meant for B and will fail authentication. > > You can get this work if B and C are sharing configuration i.e., they > are two different gateways in the same adminstrative domain. > >> However, we put as a requirement to the attack that C trusts A, i.e. C has >> some >> configuration entry with the ID of A. In this case, authentication will >> succeed. > > You also put restriction that A shares exactly same authentication > information for B and C both. This is not normal for cases where B and > C are independent. > >> You then say that a proper implementation would send a Liveness probe if its >> IPsec SA sequence numbers remain zero. >> >> The RFC does say that Liveness checks are needed. In this regard, strongswan >> and >> libreswan do not follow the RFC since in both implementations, Dead Peer >> Detection (DPD) is disabled by default. > > RFC says: > > If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer. > > Usually DPD will be have timeout of 10-30 seconds, i.e., after initial > silence, i.e., if there is nothing happening in the IKEv2 SA after > final IKE_AUTH in few tens of seconds C will send DPD message to A and > will not get reply to that, and C will delete the IKE SA after few > minutes. > >> However, DPD does not deter the attack. A classic flooding DoS attack can >> only >> set up half-open SAs. An IKEv2 implementation should remove half-open SAs >> after >> some short time. In strongswan by default half-open SAs are removed after >> 30s. >> Therefore a high-rate of m1 messages is needed to achieve memory exhaustion >> using classic flooding against IKEv2. >> >> However, the Deviation attack sets up full IKE SAs (if not Child SAs as >> well) in >> C. We measured that a full connection (one IKE SA + one Child SA) is 23kB in >> strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimum >> throughput of m1 messages to deviate in order to exhaust the memory of C. > > Note, that sending classic flooding attack packets requires no effort > from the attacker. Settting up full IKEv2 SA do require > Diffie-Hellmans, Certificate verifications etc, thus rate you can set > them up is much more limited than classic case. The maximum number of > IKEv2 SAs that can be set up each second is usually in order of > hundreds or thousands, thus even if it uses 23kB for two minutes > (until DPD kicks them out) that is only few gigabytes of memory. > Older phones would run out of memory at that point, but newer ones > have more memory than that... > > Also as you are relying
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
On 10/11/19 5:44 AM, Michael Richardson wrote: Robert Moskowitz wrote: > At some point I am going to need one, as 8005 references IPSECKEY for > its RR and I am using EdDSA for the tm-rid work. I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong that a IPSECKEY RR would point at some machine that was going to answer with HIP and not IKEv2... but now I see that you have your own RR, but share the algorithm numbers with IPSECKEY. there was an attitude to not maintain 2 separate number spaces. Now I have to live with that (how would I handle the ECDH Identities for HIP-DEX which I do not belive IKE has anything similar?) It seems that your tm-rid work can just amend this IANA registry. If you had a WG, you could ask for an early allocation. I don't think that the IPSEC WG chairs could ask for an early allocation for you at this point, alas. The way I see it, rfc 8420 'requires' this allocation. I suspect whatever works for 8420 will work for draft-moskowitz-hip-new-crypto. So I am being 'nice' and asking the owners of the IPSECKEY namespace to fix what I see as a shared problem. I really don't want to go down a path of having a tm-rid wg doing the allocation. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
On 10/11/19 5:26 AM, Michael Richardson wrote: Robert Moskowitz wrote: > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml > IANA is not showing it, so perhaps it is in a draft somewhere? I haven't done this. It's marked IETF Review, so a document is needed (but necessarily standards track). What's your use case today? Surely not tm-rid? Yes it is tm-rid. Look for a revision to https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ Any observer should have access to the HI on observing the HIT in the RemoteID Basic Message. This is needed to validate the signature in the Authentication Message. Only an authorized observer can query the USS for more information (as Stu alluded to) about the UAV. In the ASTM docs we cannot release yet (grumble) they propose both SAML and JSON for the query for these details by an authorized observer. Thus only the HI/HIT will be returned in the DNS query. RVS is normally restricted information. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
Yoav, Thank you for your quick reply, the explanations and the actions. Obviously, I will clear my DISCUSS upon a new revision of the document. About the nonce / IIV, may I suggest to add the explanation below to the terminology section? Regards -éric PS: thank you for using a É in my first name ;-) On 11/10/2019, 11:17, "iesg on behalf of Yoav Nir" wrote: Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > -- > DISCUSS: > -- > > Thank you for the work put into this document. I am trusting the security AD to > check whether it is safe not to have a 'random' IV. I’m sure they will, but as an explanation, some algorithms require a random IV. Examples are AES in CBC mode. Other algorithms do not require a random IV, but do require a unique IV. The documents describing such algorithms recommend using either a simple counter or an LFSR to generate the IV. Examples are AES in counter mode and ChaCha20. Our draft specifies IIV only for the latter kind of algorithms. > I have one trivial-to-fix > DISCUSS and a couple of COMMENTs. > > It is also unclear at first sight whether the 'nonce' built from the sequence > number is actually the IIV. Although they use the same fields, the literature tends to call the random kind an "Initialization Vector" and the must-not-repeat kind a “Nonce”. In IPsec the field is called IV, so there is some confusion in the terms. > > Regards, > > -éric > > == DISCUSS == > > -- Section 1 -- > D.1) Please use the RFC 8174 template ;) Right, our bad. This is probably because this document has been making the rounds for over 3 years. Will fix. > -- > COMMENT: > -- > > == COMMENTS == > -- Section 5 -- > C.1) "inside the SA Payload" probably worth being a little more descriptive > here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use > "IKE Initiator Behavior" for the section title. OK > -- Section 8 -- > C.2) please use the usual text for IANA considerations (notably asking IANA to > register as this is not this document that registers the codes). Yes, since we received early assignment I think we should go with the “IANA has assigned the following values…” text, and leave a reminder that the reference should be updated. > > == NITS == > > In several places, s/8 byte nonce/8-byte nonce/ Will fix. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
Robert Moskowitz wrote: > At some point I am going to need one, as 8005 references IPSECKEY for > its RR and I am using EdDSA for the tm-rid work. I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong that a IPSECKEY RR would point at some machine that was going to answer with HIP and not IKEv2... but now I see that you have your own RR, but share the algorithm numbers with IPSECKEY. It seems that your tm-rid work can just amend this IANA registry. If you had a WG, you could ask for an early allocation. I don't think that the IPSEC WG chairs could ask for an early allocation for you at this point, alas. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
Robert Moskowitz wrote: > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml > IANA is not showing it, so perhaps it is in a draft somewhere? I haven't done this. It's marked IETF Review, so a document is needed (but necessarily standards track). What's your use case today? Surely not tm-rid? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > -- > DISCUSS: > -- > > Thank you for the work put into this document. I am trusting the security AD > to > check whether it is safe not to have a 'random' IV. I’m sure they will, but as an explanation, some algorithms require a random IV. Examples are AES in CBC mode. Other algorithms do not require a random IV, but do require a unique IV. The documents describing such algorithms recommend using either a simple counter or an LFSR to generate the IV. Examples are AES in counter mode and ChaCha20. Our draft specifies IIV only for the latter kind of algorithms. > I have one trivial-to-fix > DISCUSS and a couple of COMMENTs. > > It is also unclear at first sight whether the 'nonce' built from the sequence > number is actually the IIV. Although they use the same fields, the literature tends to call the random kind an "Initialization Vector" and the must-not-repeat kind a “Nonce”. In IPsec the field is called IV, so there is some confusion in the terms. > > Regards, > > -éric > > == DISCUSS == > > -- Section 1 -- > D.1) Please use the RFC 8174 template ;) Right, our bad. This is probably because this document has been making the rounds for over 3 years. Will fix. > -- > COMMENT: > -- > > == COMMENTS == > -- Section 5 -- > C.1) "inside the SA Payload" probably worth being a little more descriptive > here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use > "IKE Initiator Behavior" for the section title. OK > -- Section 8 -- > C.2) please use the usual text for IANA considerations (notably asking IANA to > register as this is not this document that registers the codes). Yes, since we received early assignment I think we should go with the “IANA has assigned the following values…” text, and leave a reminder that the reference should be updated. > > == NITS == > > In several places, s/8 byte nonce/8-byte nonce/ Will fix. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ -- DISCUSS: -- Thank you for the work put into this document. I am trusting the security AD to check whether it is safe not to have a 'random' IV. I have one trivial-to-fix DISCUSS and a couple of COMMENTs. It is also unclear at first sight whether the 'nonce' built from the sequence number is actually the IIV. Regards, -éric == DISCUSS == -- Section 1 -- D.1) Please use the RFC 8174 template ;) -- COMMENT: -- == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
