Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Michael
> Richardson
> Sent: Wednesday, January 13, 2016 11:59 AM
> To: ipsec@ietf.org
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
> 
> 
> Scott Fluhrer (sfluhrer)  wrote:
> > - It defines the transform of the nonce from the on-the-wire version 
> into
> the
> > one presented to the IKEv2 KDF (mixing in the PPK).
> 
> > - The initiator gives an indication of which PPK to use (without 
> leaking any
> > information about it to someone two doesn’t know the value).
> 
> > For the first use, it would be reasonable to have the initiator define a
> > bitmask of the algorithms it supports, and the responder to select one
> 
> That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
> IANA values for all the algorithms involved? (shouldn't we have them)

The 'bitmask idea' was off the top of my head; we could certainly give a list 
of IANA values (such as the IKEv2 PRF).  My chief fear is that we don't 
overengineer this; this really is a "short term solution" (with the usual 
caveat that there are no short term solutions), and that a post-quantum DH-like 
function is the Right Thing (only we haven't agreed on that yet).  The issue 
with having a complex negotiation process is that may be a lot of rarely 
executed code, and that in itself may lead to security vulnerabilities.

> 
> > This second use is rather trickier to have agility; it is sent before 
> the
> > initiator has any contact to the responder. I don’t see how the
> > responder can
> > indicate which algorithms it supports (without adding a round trip to 
> the
> > protocol).
> 
> This is why I suggested... if you have to add a round trip anyway... might as
> well solve a puzzle or something along the way.

One of the constraints that we felt we had to live within was to minimize the 
changes we made to IKEv2, both from a crypto standpoint, and from a state 
machine standpoint.  Hence, we decided that adding vendor id payloads (or 
notification payloads) to existing messages we OK, however adding additional 
round trips was out of bounds.

If one were to add additional round trips, a cleaner solution would be to 
negotiate the initial IKE SA as per the RFC, and then if the two sides decide 
that they need QR, create a child SA (in a PQR manner).  The current approach 
has the issue that we need to stir in the post-quantum magic before the 
identities were exchanged (and hence the initiator gives the indication of the 
ppk). If you establish a secure connection (and exchange identities) first, 
then it becomes much cleaner (as both sides would know who they are talking to, 
and which ppk they should use).  However, that was deemed to be too large of an 
delta.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] meeting at IETF-95 ?

[Yoav Nir]

I believe around that time CFRG and TLS will be done with the signatures 
document and rfc4492bis respectively, so we could proceed and finish 
draft-ietf-ipsecme-safecurves.

So count me as a +1 as well.

> On 12 Jan 2016, at 4:56 PM, Paul Wouters  wrote:
> 
> 
> I hope we are scheduling a meeting for IETF-95. Last time we did not
> meet and ended up meeting in the hallway. This time there are more
> drafts being suggested and worked on.
> 
> Paul
> 
> ___
> 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-smyslov-ipsecme-ikev2-compression-00.txt

[Valery Smyslov]

As I've already said I'm not an expert in the IoT world. And I still think 
that the compression can
also be used in a "big world". It would allow to keep the IKE_SA_INIT message 
size bounded
when more features are added into the protocol. And I don't see it as an 
alternative to
TCP encapsulation. As you wrote in the TCP encapsulation draft it has a 
number of issues
(for example TCP in TCP) and thus it should be considered as a "last resort". 
Compression

would make those occasions when TCP encapsulation is needed more rare,
when it is _really_ needed (e.g. when UDP traffic is blocked). Sure 
compression cannot

replace TCP encapsulation.


I thought Tommy had data that showed that IKE fragmentation is not
an issue.  If UDP flows then IKE fragmentation works too. It is only
when udp is blocked that TCP was needed.


The IKE_SA_INIT message size is an issue here. If it is too long
then IKE fragmentation won't help (it starts working from the IKE_AUTH).
In this case if crippled NAT box is in between the peers would 
be unable to complete the IKE_SA_INIT exchange and would
switch to TCP encapsulation. If the IKE_SA_INITmessage 
were smaller, they could have completed the IKE_SA_INIT

and then would have communicated using UDP without suffering
from TCP encapsulation issues.


I'm still not really convinced this is much of a gain compared to the
added complexity on the protocol.

The only real use case I've heard so far is "less bytes is less
battery", but still find it weak as the newly setup IPsec tunnel
is going to get used and send more bytes.


IPsec tunnels can use IPcomp too, as recommended for the 
low-power consumption devices.



Paul


Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Paul Wouters]

On Wed, 13 Jan 2016, Valery Smyslov wrote:


 I thought Tommy had data that showed that IKE fragmentation is not
 an issue.  If UDP flows then IKE fragmentation works too. It is only
 when udp is blocked that TCP was needed.


The IKE_SA_INIT message size is an issue here. If it is too long
then IKE fragmentation won't help (it starts working from the IKE_AUTH).


Ah right. That's a fair point.

IPsec tunnels can use IPcomp too, as recommended for the low-power 
consumption devices.


Did anyone actually meassure battery costs of this versus not using it?
Is burning main CPU cheaper than burning a bit more in the transmission
chip?

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] meeting at IETF-95 ?

[Daniel Migault]

+1

On Wed, Jan 13, 2016 at 10:10 AM, Valery Smyslov  wrote:

> Count me too.
>
> Regards,
> Valery.
>
>
> +1 to having a meeting at IETF 95.
>>
>> Thanks,
>> Tommy
>>
>> On Jan 12, 2016, at 6:56 AM, Paul Wouters  wrote:
>>>
>>>
>>> I hope we are scheduling a meeting for IETF-95. Last time we did not
>>> meet and ended up meeting in the hallway. This time there are more
>>> drafts being suggested and worked on.
>>>
>>> Paul
>>>
>>> ___
>>> 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
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Valery Smyslov]

Hi Tommy,


In those environments the IKEv2 is used to negotiate link keys between
two devices. The payloads are already quite compacted, i.e. there will
not be several proposals for ciphers, only one, and all extra payloads
are omitted anyways.


Tero’s comments seem to confirm the idea that constrained devices will generally
be using a small set of proposals, and thus do not need compression.


Well, I'm not an expert in IoT devices. And it's true that with minimal set of 
transforms
and with reduced number of supported features the compression won't help much 
in IKEv2.
However, I'm a bit afraid of oversimplifying the whole picture. It seems to me 
that
there may be different kinds of constrained devices, and some of them would
be more advanced, then the most restricted ones. And I think that the IoT world
won't be isolated, so that at least some of the IoT devices would have to 
communicate
with the "big world" peers and thus would have to support more IKEv2 features 
and extensions,
that would make their messages larger. And for those devices the compression 
could be useful.


The document referred to in the draft as IPSEC-IOT-REQS, 
draft-mglt-6lo-diet-esp-requirements-01,
recommends essentially one algorithm for the Child SA algorithm (AES-CCM),
so it may be safe to assume that IoT devices could converge to a small set of 
IKE SA algorithms
to standardly use. And, while this document does recommend compression for ESP 
packets,
I can see more of an argument being made for compressing ESP traffic (which may 
be many packets)
than for compressing the IKE_SA_INIT packet, which is already a one-time-cost 
small packet.


The compression draft is not only about the IKE_SA_INIT messages. It also 
allows the subsequent
messages to be compressed. While the IKE_AUTH is also one-time message, I can 
imagine
that some restricted devices could use IKE SA to transmit application data (it 
can appear to be easier
than to implement ESP). In this case the compression would be useful too.


Valery, do you have specific real-world examples of IKE_SA_INIT packets that 
are being used
by IoT devices that get a benefit from this compression? Without this, it seems 
that adding
compression to IKE would add a fair amount of complexity to optimize a packet 
that is already
fairly inexpensive to send.


As I've already said I'm not an expert in the IoT world. And I still think that 
the compression can
also be used in a "big world". It would allow to keep the IKE_SA_INIT message 
size bounded
when more features are added into the protocol. And I don't see it as an 
alternative to
TCP encapsulation. As you wrote in the TCP encapsulation draft it has a number 
of issues
(for example TCP in TCP) and thus it should be considered as a "last resort". 
Compression
would make those occasions when TCP encapsulation is needed more rare,
when it is _really_ needed (e.g. when UDP traffic is blocked). Sure compression 
cannot
replace TCP encapsulation.

And here some data from my experiments with compression
of the IKEv2 messages using DEFLATE algorithm:

1. IKE_SA_INIT, single transform of each type:

HDR,
SA[48]{
  P[44]{
   Encryption=AES-CBC {KeyLen=128},
   PRF=SHA1-HMAC,
   Integrity=SHA1-HMAC96,
   Group=MODP-1536}},
 NONCE[36],
 KE[200](MODP-1536),
 N[28](NAT_DETECTION_SOURCE_IP),
 N[28](NAT_DETECTION_DESTINATION_IP),
 N[8](IKEV2_FRAGMENTATION_SUPPORTED),
 N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
 N[8](REDIRECT_SUPPORTED),
 VID[26]

In this case using compression results in roughly the same message size
(you can save or loose a few bytes).

2. IKE_SA_INIT, multiple transforms of each type:

HDR,
 SA[264]{
  P[104]{
   Encryption=AES-CBC {KeyLen=256}, AES-CBC {KeyLen=128},
   PRF=SHA2.256-HMAC, SHA2.384-HMAC, SHA2.512-HMAC,
   Integrity=SHA2.256-HMAC128, SHA2.384-HMAC192, SHA2.512-HMAC256,
   Group=ECP-256, ECP-384, ECP-521},
  P[84]{
   Encryption=AES-CBC {KeyLen=128}, 3DES-CBC,
   PRF=SHA1-HMAC, SHA2.256-HMAC,
   Integrity=SHA1-HMAC96, SHA2.256-HMAC128,
   Group=MODP-1024, ECP-224, ECP-256},
  P[72]{
   Encryption=DES-CBC,
   PRF=SHA1-HMAC, MD5-HMAC,
   Integrity=SHA1-HMAC96, MD5-HMAC96,
   Group=MODP-1024, MODP-768, ECP-192}},
 NONCE[36],
 KE[72](ECP-256),
 N[28](NAT_DETECTION_SOURCE_IP),
 N[28](NAT_DETECTION_DESTINATION_IP),
 N[8](IKEV2_FRAGMENTATION_SUPPORTED),
 N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512},
 N[8](REDIRECT_SUPPORTED),
 VID[26]

In this case using compressions results in saving of ~150 bytes out of initial 
~530 bytes (~30%).

3. IKE_AUTH with certificate, single proposal of each type, simple traffic 
selectors:

HDR,
SK[1720]{
 IDi[63](DN),
 CERT[1167](X.509 Cert),
 CERTREQ[45](X.509 Cert),
 IDr[38](DN),
 AUTH[150](Sig){sha1RSA[13]},
 N[8](INITIAL_CONTACT),
 N[8](IKEV2_MESSAGE_ID_SYNC_SUPPORTED),
 N[12](SET_WINDOW_SIZE),
 CP[16](REQUEST),
 SA[44]{
  P[40]{
   Encryption=AES-CBC {KeyLen=128},
   Integrity=SHA1-HMAC96,
   ESN=Off}},
 TSi[40],
 TSr[40],
 

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Paul Wouters]

On Wed, 13 Jan 2016, Valery Smyslov wrote:

Well, I'm not an expert in IoT devices. And it's true that with minimal set 
of transforms
and with reduced number of supported features the compression won't help much 
in IKEv2.
However, I'm a bit afraid of oversimplifying the whole picture. It seems to 
me that

there may be different kinds of constrained devices, and some of them would
be more advanced, then the most restricted ones. And I think that the IoT 
world
won't be isolated, so that at least some of the IoT devices would have to 
communicate
with the "big world" peers and thus would have to support more IKEv2 features 
and extensions,
that would make their messages larger. And for those devices the compression 
could be useful.


This seems like a very unclear use case. More of a hypothetical use case.

The compression draft is not only about the IKE_SA_INIT messages. It also 
allows the subsequent
messages to be compressed. While the IKE_AUTH is also one-time message, I can 
imagine
that some restricted devices could use IKE SA to transmit application data 
(it can appear to be easier

than to implement ESP). In this case the compression would be useful too.


And that is a use case for something not even in the specification.

As I've already said I'm not an expert in the IoT world. And I still think 
that the compression can
also be used in a "big world". It would allow to keep the IKE_SA_INIT message 
size bounded
when more features are added into the protocol. And I don't see it as an 
alternative to
TCP encapsulation. As you wrote in the TCP encapsulation draft it has a 
number of issues
(for example TCP in TCP) and thus it should be considered as a "last resort". 
Compression

would make those occasions when TCP encapsulation is needed more rare,
when it is _really_ needed (e.g. when UDP traffic is blocked). Sure 
compression cannot

replace TCP encapsulation.


I thought Tommy had data that showed that IKE fragmentation is not
an issue.  If UDP flows then IKE fragmentation works too. It is only
when udp is blocked that TCP was needed.

I'm still not really convinced this is much of a gain compared to the
added complexity on the protocol.

The only real use case I've heard so far is "less bytes is less
battery", but still find it weak as the newly setup IPsec tunnel
is going to get used and send more bytes.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] meeting at IETF-95 ?

[Valery Smyslov]

Count me too.

Regards,
Valery.


+1 to having a meeting at IETF 95.

Thanks,
Tommy


On Jan 12, 2016, at 6:56 AM, Paul Wouters  wrote:


I hope we are scheduling a meeting for IETF-95. Last time we did not
meet and ended up meeting in the hallway. This time there are more
drafts being suggested and worked on.

Paul

___
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] NIST question concerning IKEv2 and quantum resistance

[Michael Richardson]

Scott Fluhrer (sfluhrer)  wrote:
> - It defines the transform of the nonce from the on-the-wire version into 
the
> one presented to the IKEv2 KDF (mixing in the PPK).

> - The initiator gives an indication of which PPK to use (without leaking 
any
> information about it to someone two doesn’t know the value).

> For the first use, it would be reasonable to have the initiator define a
> bitmask of the algorithms it supports, and the responder to select one

That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
IANA values for all the algorithms involved? (shouldn't we have them)

> This second use is rather trickier to have agility; it is sent before the
> initiator has any contact to the responder. I don’t see how the
> responder can
> indicate which algorithms it supports (without adding a round trip to the
> protocol).

This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec