Re: [IPsec] Summary of charter discussion

[David Schinazi]

Hello Tero,

Regarding charter item 4 (mitigating privacy concerns), I have submitted the 
following draft:

https://tools.ietf.org/html/draft-dschinazi-ipsecme-sa-init-privacy-addition 


I'd like to discuss the problem statement and potential solution in London.
I would personally recommend not deciding on its addition to the charter until 
this has been discussed.

Thanks,
David Schinazi


> On Mar 4, 2018, at 12:18, Tero Kivinen  wrote:
> 
> There was very little discussion about the "ready" parts of the
> charter (one comment from Wouters, but no new text or explination why
> "mesh" is different than host-to-host.
> 
> Additional items:
> 
> 
> Item 1 responder MOBIKE
> 
>   We had some discussion already on the list, and several people
>   commented (Paul Wouters, Hu Jun) that they do want to have
>   more discussion about the goal before going to the the
>   solutions. I also think that the item is not well enough
>   explained in the charter that we can work on it, so perhaps we
>   leave this out for now and continue discussion in the list and
>   in the next meeting about what we really want.
> 
> Item 2 Address Failure Errors
> 
>   We got some support (Michael Richardson), and Paul Wouters
>   wanted to have more discussion about this. I myself think this
>   is clear enough and we can add it to the charter.
> 
> Item 3 Labeled IPsec
> 
>   We had concerns (Yoav Nir, Valery Smyslov) that this should
>   not affect implementations which do not implement this, so I
>   think the charter item should be modified to explictly say so.
>   I.e., add text which says there will not be any need to change
>   old implementations.
> 
> Item 4 Mitigating privacy concerns
> 
>   We had very little support for this and some concerns about
>   this getting in the arms race with goverments etc. I myself do
>   not think this item is ready yet to be taken as charter item,
>   we need research on this before we can actually start working
>   on the protocol changes.
> 
> --
> 
> This means the final proposed chater would be:
> 
> --
> 
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
> RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec
> security architecture (RFC 4301). IPsec is widely deployed in VPN
> gateways, VPN remote access clients, and as a substrate for
> host-to-host, host-to-network, and network-to-network security.
> 
> The IPsec Maintenance and Extensions Working Group continues the work
> of the earlier IPsec Working Group which was concluded in 2005. Its
> purpose is to maintain the IPsec standard and to facilitate discussion
> of clarifications, improvements, and extensions to IPsec, mostly to
> ESP and IKEv2. The working group also serves as a focus point for
> other IETF Working Groups who use IPsec in their own protocols.
> 
> The current work items include:
> 
> IKEv1 using shared secret authentication was partially resistant to
> quantum computers. IKEv2 removed this feature to make the protocol
> more usable. The working group will add a mode to IKEv2 or otherwise
> modify IKEv2 to have similar quantum resistant properties than IKEv1
> had.
> 
> Split-DNS is a common configuration for VPN deployments, in which only
> one or a few private DNS domains are accessible and resolvable via the
> tunnel. Adding new configuration attributes to IKEv2 for configuring
> Split-DNS would allow more deployments to adopt IKEv2. This
> configuration should also allow verification of the domains using
> DNSSEC. Working group will specify needed configuration attributes for
> IKEv2.
> 
> Currently, widely used counter mode based ciphers send both the ESP
> sequence number and IV in form of counter, as they are very commonly
> the same. There has been interest to work on a document that will
> compress the packet and derive IV from the sequence number instead of
> sending it in separate field. The working group will specify how this
> compression can be negotiated in the IKEv2, and specify how the
> encryption algorithm and ESP format is used in this case.
> 
> The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based
> protocol for negotiating group keys for both multicast and unicast
> uses. The Working Group will develop an IKEv2-based alternative that
> will include cryptographic updates. A possible starting point is
> draft-yeung-g-ikev2
> 
> Postquantum Cryptography brings new key exchange methods. Most of
> these methods that are known to date have much larger public keys then
> conventional Diffie-Hellman public keys. Direct using these methods in
> IKEv2 might lead to a number of problems due to the increased size of
> initial IKEv2 messages. The 

[IPsec] Summary of charter discussion

[Tero Kivinen]

There was very little discussion about the "ready" parts of the
charter (one comment from Wouters, but no new text or explination why
"mesh" is different than host-to-host.

Additional items:


Item 1 responder MOBIKE

We had some discussion already on the list, and several people
commented (Paul Wouters, Hu Jun) that they do want to have
more discussion about the goal before going to the the
solutions. I also think that the item is not well enough
explained in the charter that we can work on it, so perhaps we
leave this out for now and continue discussion in the list and
in the next meeting about what we really want.

Item 2 Address Failure Errors

We got some support (Michael Richardson), and Paul Wouters
wanted to have more discussion about this. I myself think this
is clear enough and we can add it to the charter.

Item 3 Labeled IPsec

We had concerns (Yoav Nir, Valery Smyslov) that this should
not affect implementations which do not implement this, so I
think the charter item should be modified to explictly say so.
I.e., add text which says there will not be any need to change
old implementations.

Item 4 Mitigating privacy concerns

We had very little support for this and some concerns about
this getting in the arms race with goverments etc. I myself do
not think this item is ready yet to be taken as charter item,
we need research on this before we can actually start working
on the protocol changes.

--

This means the final proposed chater would be:

--

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group continues the work
of the earlier IPsec Working Group which was concluded in 2005. Its
purpose is to maintain the IPsec standard and to facilitate discussion
of clarifications, improvements, and extensions to IPsec, mostly to
ESP and IKEv2. The working group also serves as a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The current work items include:

IKEv1 using shared secret authentication was partially resistant to
quantum computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or otherwise
modify IKEv2 to have similar quantum resistant properties than IKEv1
had.

Split-DNS is a common configuration for VPN deployments, in which only
one or a few private DNS domains are accessible and resolvable via the
tunnel. Adding new configuration attributes to IKEv2 for configuring
Split-DNS would allow more deployments to adopt IKEv2. This
configuration should also allow verification of the domains using
DNSSEC. Working group will specify needed configuration attributes for
IKEv2.

Currently, widely used counter mode based ciphers send both the ESP
sequence number and IV in form of counter, as they are very commonly
the same. There has been interest to work on a document that will
compress the packet and derive IV from the sequence number instead of
sending it in separate field. The working group will specify how this
compression can be negotiated in the IKEv2, and specify how the
encryption algorithm and ESP format is used in this case.

The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based
protocol for negotiating group keys for both multicast and unicast
uses. The Working Group will develop an IKEv2-based alternative that
will include cryptographic updates. A possible starting point is
draft-yeung-g-ikev2

Postquantum Cryptography brings new key exchange methods. Most of
these methods that are known to date have much larger public keys then
conventional Diffie-Hellman public keys. Direct using these methods in
IKEv2 might lead to a number of problems due to the increased size of
initial IKEv2 messages. The working group will analyze the possible
problems and develop a solution, that will make adding Postquantum key
exchange methods more easy. The solution will allow post quantum key
exchange to be performed in parallel with (or instead of) the existing
Diffie-Hellman key exchange.

A growing number of use cases for constraint network - but not limited
to - have shown interest in reducing ESP (resp. IKEv2) overhead by
compressing ESP (resp IKEv2) fields. The WG will define extensions of
ESP and IKEv2 to enable ESP header compression.

draft-mglt-ipsecme-diet-esp and
draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good
starting points for ESP compression.