Subject: [IPsec] Candidate charter text is now in wiki

From: Tero Kivinen <[email-masked]>
Date: Fri, 17 Nov 2017 07:20:42 +0200

I put the candidate charter text to the wiki. This includes the
changes in the first two paragraphs, removes items already done, and
list of new items. I have not yet added the items that came too late
to have charter text bashed in the meeting to the wiki.

For those items which do not have text yet, it would be good idea if
those people could send new proposed text to the list so we could bash
those at the same time as we go and check the other pieces.

So read that candidate charter text and comment it on the list.

Wiki address is https://trac.ietf.org/trac/ipsecme/wiki/recharter2017
-- 
[email-masked]

---

From: <[email-masked]>
Date: Fri, 17 Nov 2017 06:35:19 +0000

Dear Tero,

It seems that you missed this text for the address failure codes (Nov 13): 
https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html   

I'm resending it fwiw:

   RFC7296 defines a generic notification code that is related to a
   failure to handle an internal address failure.  That code does not
   explicitly allow an initiator to determine why a given address family
   is not assigned, nor whether it should try using another address
   family.  The Working Group will specify a set of more specific
   notification codes that will provide sufficient information to the
   IKEv2 initiator about the encountered failure.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de Tero Kivinen
> Envoyé : vendredi 17 novembre 2017 06:21
> À : [email-masked]
> Objet : [IPsec] Candidate charter text is now in wiki
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Nov 2017 19:47:47 -0800

Hi Tero,

Here is proposed charter text for the "Mitigating privacy concerns" section:

IKEv2 is currently vulnerable to the two following privacy concerns:

1) It's not possible to run a server that obfuscates IKEv2/IPsec using TLS.
    Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec server on TCP port 443 with TLS.
    However if a government agent tries to send an SA_INIT over that it will discover that this server runs IKEv2/IPsec, and may blacklist it.
    We should add a mechanism to IKEv2 that allows the server to only respond to SA_INIT from known entities (e.g. that possess a shared secret).

2) The privacy of the initiator's identity in the presence of a man in the middle attacker is not protected
    Today an attacker with full control of the network can receive the IDi/IDr sent by the initiator in the first AUTH packet.
    We should add a mechanism to IKEv2 that allows the initiator to only send IDi/IDr to known entities (e.g. that possess a shared secret).

Thanks,
David Schinazi

> On Nov 16, 2017, at 22:35, [email-masked] wrote:
> 
> Dear Tero,
>