Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.txt

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Jan 2019 14:37:09 +0300

Hi,

a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted.
It addresses Paul Wouters' comment about the Security Considerations text.

Regards,
Valery (for the authors).

> A new version of I-D, draft-ietf-ipsecme-qr-ikev2-06.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
> 
> Name:		draft-ietf-ipsecme-qr-ikev2
> Revision:	06
> Title:		Postquantum Preshared Keys for IKEv2
> Document date:	2019-01-18
> Group:		ipsecme
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-qr-ikev2-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-06
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-06
> 
> Abstract:
>    The possibility of Quantum Computers pose a serious challenge to
>    cryptography algorithms deployed widely today.  IKEv2 is one example
>    of a cryptosystem that could be broken; someone storing VPN
>    communications today could decrypt them at a later time when a
>    Quantum Computer is available.  It is anticipated that IKEv2 will be
>    extended to support quantum secure key exchange algorithms; however
>    that is not likely to happen in the near term.  To address this
>    problem before then, this document describes an extension of IKEv2 to
>    allow it to be resistant to a Quantum Computer, by using preshared
>    keys.
> 
> 
> 
> 
> 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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jan 2019 10:22:07 -0500 (EST)

> It addresses Paul Wouters' comment about the Security Considerations text.

Thanks!

I have another minor suggested change :)

current:

    Note that [RFC6023] allows to
    skip creating Child SA in the IKE_AUTH exchange, so that the
    supporting peers can rekey the IKE SA before any Child SA is created.
    Note also that some information (identities of the peers, feature
    negotiation notifications, Vendor IDs etc.) is always exchanged in
    initial exchanges and thus cannot be protected from the attack
    described above by performing an IKE SA rekey.

new:

It is possible to create a childless IKE SA in IKE_AUTH as specified
in [RFC6023]. This prevents Child SA configuration information from
being transmited in the original IKE SA that is not protected by
a PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges,
such as peer identities, feature notifications and Vendor ID's cannot
be hidden from the attack described above, even if the additional IKE
SA rekey is performed. Although this information would also be available
to a Man-in-the-middle attacker without a quantum computer.

This removes the two "note" from sentences which make them less easy
to read, and quantifies the leaked information a bit in the context of
a simple MITM, non-quantum attack. It explains a bit better why there
isn't a strong reason to try and hide the peer identities and VIDs from
attackers with quantum computers.

Paul

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 18 Jan 2019 16:38:33 +0000

Thanks for the detailed reviews Paul. I don't think the new text is changing the meaning of the text that is already there. Anyone reading either of the two, would be able to understand the point. Thus, I feel there is no need to make the new change this late in WGLC process. 
Panos

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Paul Wouters
Sent: Friday, January 18, 2019 10:22 AM
To: Valery Smyslov <[email-masked]>
Cc: IPsecME WG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.txt

Thanks!

current:

new:

It is possible to create a childless IKE SA in IKE_AUTH as specified in [RFC6023]. This prevents Child SA configuration information from being transmited in the original IKE SA that is not protected by a PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges, such as peer identities, feature notifications and Vendor ID's cannot be hidden from the attack described above, even if the additional IKE SA rekey is performed. Although this information would also be available to a Man-in-the-middle attacker without a quantum computer.

This removes the two "note" from sentences which make them less easy to read, and quantifies the leaked information a bit in the context of a simple MITM, non-quantum attack. It explains a bit better why there isn't a strong reason to try and hide the peer identities and VIDs from attackers with quantum computers.

Paul

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Jan 2019 21:24:40 +0300

Hi Paul,

I think that comparing QC-based attack with MITM is a bit incorrect,
since Man-in-the-Middle can only learn what the Initiator sends,
while an attacker equipeed with QC can also learn what the Responder
replyis. Besides, unlike Man-in-the-Middle, this is a passive attack 
and the peers could never know that their conversation is revealed.

Anyway, I think that MITM in IKEv2 is covered in enough detail
in RFC7296, so I don't see the need to mention it here.

Otherwise, the two texts basically say the same. I admit that yours
is easier to read :-), but let's see what the RFC  says :-)

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jan 2019 14:00:51 -0500 (EST)

> Thanks for the detailed reviews Paul. I don't think the new text is changing the meaning of the text that is already there. Anyone reading either of the two, would be able to understand the point.…

This statement is incorrect from a procedural point of view.

It is never too late in the WGLC for the WG to make the document better
if everyone agrees. Clarifying the text before sending in onto the rest
of the IETF for LC is what is supposed to happen in a working group.

Especially since this was new text, and not text that has resided in
many revisions before the last one.

Revision numbers are cheap. Let's make our documents easier to read.

I'm okay with Valerie's comment about not introducing MITM in the
change. But I'd really like to say the two sentences that start with
"note" to be rewritten for easier reading.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Jan 2019 16:00:50 +0200

Panos Kampanakis (pkampana) writes:
> Thanks for the detailed reviews Paul. I don't think the new text is
> changing the meaning of the text that is already there. Anyone
> reading either of the two, would be able to understand the point.
> Thus, I feel there is no need to make the new change this late in
> WGLC process.  

WGLC is not late, it is early...

Paul's text is easier to read, and I think that pointing out that
initiators Peer identity, feature negotiatons, vendor ids are already
available for active attacker doing man in the middle of the
connection is good point. Usually the responder already has static
address, thus most of this information is already known to everybody,
so initiators information is more important.

Also we can later add protection for both peer identities if we like,
i.e. use random one use pseudonyms in the initial exchange.

Paul Wouters writes:
> being transmited in the original IKE SA that is not protected by a
> PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges,
> such as peer identities, feature notifications and Vendor ID's
> cannot be hidden from the attack described above, even if the
> additional IKE SA rekey is performed. Although this information
> would also be available to a Man-in-the-middle attacker without a
> quantum computer.

This last sentence should probably be rewritten to be more accurate,
i.e.:

Although initiators information would also be available to a
Man-in-the-middle attacker without a quantum computer.

> to read, and quantifies the leaked information a bit in the context
> of a simple MITM, non-quantum attack. It explains a bit better why
> there isn't a strong reason to try and hide the peer identities and
> VIDs from attackers with quantum computers. 
-- 
[email-masked]