Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv-05

[John Mattsson]

Hi,

I think the idea of introducing "implicit IV" also in IPsec is great and 
something that absolutely should be done. Some comments:

- The abstract/introduction/security consideration gives the idea that it 
defines implicit IV for ENCR_AES_CTR which is does not. I think AES-CTR could 
be removed from the document.

- I think the the terminology of IV, nonce etc. in this document is very 
confusing. At least RFC 4106 defines IV to be the 8 octet ESP IV, while nonce 
is used for the 12 octet AEAD nonce, aligning with RFC 5116. I think this 
document should also follow this convention. e.g. I think the sentences should 
talk about IV instead of nonce.

   "but all of the algorithms mentioned above take an 8-octet nonce."

   "Currently this nonce is sent in each ESP packet"

- "Nonce generation for these algorithms has not been explicitly defined. 
   It has been left to the implementation"

I do not understand how implementation specific nonce (or IV) generation could 
be interoperable between implementation? If I understand correctly, the only 
thing sent in the ESP packet is the sequence number.

- If we go to the trouble of designing new encryption algorithms for ESP, I 
think this document does too little and misses opportunities to with very 
little work also make the algorithms stronger cryptographically as was done 
with TLS 1.2 -> TLS 1.3. I stongly suggest to change the nonce generation to 
follow current best practices established by e.g. TLS 1.3. Suggestion (here 
examplified for AES-128 in GCM mode)

   1. The KEYMAT requested for each AES-GCM key is 28 octets.  The first
16 octets are the 128-bit AES key, and the remaining 12 octets
are used as the salt value in the nonce.

   2. The nonce format is changed to a format following Section 4.4 of 
draft-mcgrew-iv-gen [XX] where IV = implicit IV

   0  1  2  3  4  5  6  7  8  9 10 11
 +--+--+--+--+--+--+--+--+--+--+--+--+
 |00|00|00|00|   IV  |---+
 +--+--+--+--+--+--+--+--+--+--+--+--+   |
 |
 +--+--+--+--+--+--+--+--+--+--+--+--+   |
 |salt   |->(+)
 +--+--+--+--+--+--+--+--+--+--+--+--+   |
 |
 +--+--+--+--+--+--+--+--+--+--+--+--+   |
 |nonce  |<--+
 +--+--+--+--+--+--+--+--+--+--+--+--+

  Figure: Nonce Format

   3. The salt is kept secret

In [YY] it is shown that this can be understood as a key-length extension 
that essentially extends the 128-bit key of AES-GCM to a 224-bit key giving 
significatntly better multi-user security (and single-user security)

- A large secret salt is useful for IKEv2 as well, I think the algorithms 
should be defined for IKEv2 as but with IV = explicit IV.

Cheers,
John


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

Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02

[Daniel Migault]

Hi Tero,

Thanks for the response. Version 4 of the draft has been updated with this
alternative.

Yours,
Daniel

On Thu, May 10, 2018 at 10:53 AM, Tero Kivinen  wrote:

> Daniel Migault writes:
> > another alternative could be:
> >
> > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
> >used, Implicit IV as described in this document MUST NOT be used in
> >setups with the chance that the Sequence Number overlaps for one SA.
> >Multicast as described in [RFC5374], [RFC6407] and
> >[I-D.yeung-g-ikev2] is a prominent example, where many senders share
> >one secret and thus one SA.  As
> >such, it is NOT RECOMMENDED to use Implicit IV with Multicast.
>
> I would actually prefer to this. I think it is better to say don't do
> it, than provide ways it could be done before saying don't do it
>
> I.e., if someone is interested in this then we need to write new
> specification that will specify how it is done, so there is no point
> of speculating here what it could be.
> --
> kivi...@iki.fi
>
> ___
> 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] Comments about draft-ietf-ipsecme-implicit-iv-02

[Tero Kivinen]

Daniel Migault writes:
> another alternative could be:
> 
> As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
>    used, Implicit IV as described in this document MUST NOT be used in
>    setups with the chance that the Sequence Number overlaps for one SA.
>    Multicast as described in [RFC5374], [RFC6407] and
>    [I-D.yeung-g-ikev2] is a prominent example, where many senders share
>    one secret and thus one SA.  As
>    such, it is NOT RECOMMENDED to use Implicit IV with Multicast.

I would actually prefer to this. I think it is better to say don't do
it, than provide ways it could be done before saying don't do it

I.e., if someone is interested in this then we need to write new
specification that will specify how it is done, so there is no point
of speculating here what it could be.
-- 
kivi...@iki.fi

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

Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02

[Daniel Migault]

Hi,

Thank you Tero for the review. Please find in line my responses in line.
version 02 of the draft has been updated accordingly to your review.

Yours,
Daniel

On Fri, Apr 6, 2018 at 4:08 PM, Tero Kivinen  wrote:

> While doing my IANA review on the document I found some small nits
> about it. Here are my comments to the document:
>
> --
>
> Typo in abstract:
>
> This avoids
>sending the nonce itself, and savec in the case of AES-GCM, AES-CCM,
>  ^
>
> I assume it should be "saves".


This has been changed to 'saves'.


> --
>
> In section 2 missing closing parenthesis and period:
>
> ... The same applies for
>ChaCha20-Poly1305 ([RFC7634].  Currently this nonce is sent in each
>^
>
> add missing ")".
>
> The missing ")" has been added

> --
>
> In section 4, I think SA is better word than SPI to describe the IPsec
> security association. SPI is just the number identifying the SA, SA is
> the actual security association which includes sequence number, key,
> direction, algorithms etc.
>
> So change:
>
>As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
>used, Implicit IV as described in this document MUST NOT be used in
>setups with the chance that the Sequence Number overlaps for one SPI.
>Multicast as described in [RFC5374], [RFC6407] and
>[I-D.yeung-g-ikev2] is a prominent example, where many senders share
>one secret and thus one SPI.
>
> with
>
>As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
>used, Implicit IV as described in this document MUST NOT be used in
>setups with the chance that the Sequence Number overlaps for one
>SA. Multicast as described in [RFC5374], [RFC6407] and
>[I-D.yeung-g-ikev2] is a prominent example, where many senders
>share one secret and thus one SA.
>
> The three occurrences of SPI have been changed to SA.


> --
>
> This text is bit misleading
>
>A similar mechanism could be used by associating the most
>significant byte of the Sequence Number to a sender, while the 3
>remaining bytes will be used to carry the counter value. Such
>mechanism prevents the use of Extended Sequence Number and limits
>the number of packet to be sent to 2** 24 = 16777216, that is 16 M.
>
> To solve the issue you could of course move the sender byte as the
> least significant byte in the sequence number, i.e., in that case the
> system could use extended sequence numbers, and the limit of the
> packet would not be that bad. Of course this still has the issue that
> normal replay window processing does not work with cases where
> sequence numbers are not used in numeric order (this same issue is in
> the normal RFC6407 cases).
>
> On the other hand, I think it might be better to just forbid the
> implicit IV on multicast cases, and we do not need to explain all the
> issues there.
>
>
I propose to add your comment and mention that Implicit IV is not
recommended with multicast so the reader interested in multicast
understands the motivation for not using it.


As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
   used, Implicit IV as described in this document MUST NOT be used in
   setups with the chance that the Sequence Number overlaps for one SA.
   Multicast as described in [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a prominent example, where many senders share
   one secret and thus one SA.  Section 3.5 of [RFC6407] provides a
   mechanism that MAY be used to prevent IV collisions when the same key
   is used by multiple users.  The mechanism consists in partitioning
   the IV space between users by assigning the most significant byte to
   a user.  When implicit IV transforms are used, such mechanism cannot
   be applied as the IV is not sent, but instead it is derived from the
   Sequence Number.  A similar mechanism could be used by associating
   the most significant byte of the Sequence Number to a sender, while
   the 3 remaining bytes will be used to carry the counter value.  Such
   mechanism prevents the use of Extended Sequence Number and limits the
   number of packet to be sent to 2** 24 = 16777216, that is 16 M.  Note
   that associating instead the least significant byte of the Sequence
   Number to the sender, would enable the system to use Extended
   Sequence Number and as such extend the limit of packet to be sent to
   2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P.  Note also that
   in both cases the Sequence Number are not interpreted as numeric
   values which impacts the replay window processing defined in
   [RFC4302] and [RFC4302].

   Unless some mechanism are provided to avoid collision between
   Sequence Number, ( and so IV ), Implicit IV MUST NOT be used.  As
   such, it is NOT RECOMMENDED to use Implicit IV with Multicast.

another alternative could be:


As the IV 

Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

[Daniel Migault]

Thanks a lot Scott for the response. I am publishing the draft asap.
Yours,
Daniel

On Tue, Mar 27, 2018 at 2:04 PM, Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:

>
>
> *From:* mglt.i...@gmail.com <mglt.i...@gmail.com> *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, March 27, 2018 1:22 PM
> *To:* Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>
> *Cc:* IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>
> *Subject:* Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv
>
>
>
> Thank you Scott for your comments.
>
> I understand the first comment as a text clarification to comment on the
> mechanism provided by section 3.5 of RFC6407 and explicitely mention that
> is does not apply here. Does the replacement below addresses your concern ?
>
> OLD:
>Section 3.5 of [RFC6407] explains how
>repetition MAY BE prevented by using a prefix for each group member,
>which could be prefixed to the Sequence Number.  Otherwise, Implicit
>IV MUST NOT be used in multicast scenarios.
>
> NEW:
>Section 3.5 of [RFC6407] provides a mechanism that MAY be used to
> prevent IV collisions when the same key is used by multiple users. The
> mechanism consists in partitioning the IV space between users by assigning
> the most significant byte to a user. When implicit IV transforms are used,
> such mechanism cannot be applied as the IV is not sent, but instead it is
> derived from the Sequence Number. A similar mechanism could be used by
> associating the most significant byte of the Sequence Number to a sender,
> while the 3 remaining bytes will be used to carry the counter value. Such
> mechanism prevents the use of Extended Sequence Number and limits the
> number of packet to be sent to 2** 24 =  16777216, that is 16 M.
>
> Unless some mechanism are provided to avoid collision between Sequence
> Number, ( and so IV ), Implicit IV MUST NOT be used.
>
>
>
> That works…
>
>
>
>
> Regarding the second comment, I guess the idea was to mention that a
> responser cannot select a IIV Transform unless being sent by the initiator.
> I propose the following text. Do it address your comment ?
>
> OLD:
>
>The rules of SA payload processing ensure that the responder will
>never send an SA payload containing the IIV indicator to an initiator
>that does not support IIV.
>
>
> NEW:
>
>The rules of SA payload processing ensure that the responder will
>never send an SA payload containing the IIV transform to an initiator
>that does not support IIV.
>
>
>
> I’m wondering whether this is necessary to state this.  For example, RFC
> 7634 (the ChaCha IPsec transform) does not have any similar language, even
> though (like this draft) they define a new transform id.
>
>
>
> However, I’m not demanding any change; the text just sounds redundant to
> me…
>
>
>
>
>
> The reason for not having AES_CTR was that the transform is on its way to
> be retired. I propose to remove AES-CTR, but if there is a need to provide
> AES-CTR with implicit IV we coudl also add additional code points.
>
> I am currently proposing the following text:
>
> OLD:
>AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>implement the implicit IV described in this document.
>
> NEW:
>
>AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>implement the implicit IV described in this document.
>
>
>
> Works for me.
>
>
>
>
>
> Yours,
>
> Daniel
>
> On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) <
> sfluh...@cisco.com> wrote:
>
> -  Section 4: “Section 3.5 of [RFC6407] explains how repetition
> MAY BE prevented by using a prefix for each group member”
>
> Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8
> bits of the 8 byte sequence number.  Used literally, this doesn’t work, as
> the top 8 bits of the 8 byte sequence number are never expressed in the
> packet in implicit-iv.  You could put them in the top 8 bits of the 4 byte
> sequence number (which means you can’t use ESN, but it didn’t work in the
> multisender case anyways), but that would mean that each sender would be
> limited to 16M packets. I believe that these details are distinct enough
> that (if this is considered a viable alternative) they should be explicitly
> listed (including the 16M packet restriction).  Alternatively, we can just
> forbid this transform in the multisender case.
>
>
>
> -  Section 6: “The rules of SA payload processing ensure that the
> responder will never send an SA payload containing the IIV indicator to an
> initiator that does not support IIV”
>
> I believe that this is 

Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

[Scott Fluhrer (sfluhrer)]

From: mglt.i...@gmail.com <mglt.i...@gmail.com> On Behalf Of Daniel Migault
Sent: Tuesday, March 27, 2018 1:22 PM
To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>
Cc: IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

Thank you Scott for your comments.

I understand the first comment as a text clarification to comment on the 
mechanism provided by section 3.5 of RFC6407 and explicitely mention that is 
does not apply here. Does the replacement below addresses your concern ?

OLD:
   Section 3.5 of [RFC6407] explains how
   repetition MAY BE prevented by using a prefix for each group member,
   which could be prefixed to the Sequence Number.  Otherwise, Implicit
   IV MUST NOT be used in multicast scenarios.

NEW:
   Section 3.5 of [RFC6407] provides a mechanism that MAY be used to prevent IV 
collisions when the same key is used by multiple users. The mechanism consists 
in partitioning the IV space between users by assigning the most significant 
byte to a user. When implicit IV transforms are used, such mechanism cannot be 
applied as the IV is not sent, but instead it is derived from the Sequence 
Number. A similar mechanism could be used by associating the most significant 
byte of the Sequence Number to a sender, while the 3 remaining bytes will be 
used to carry the counter value. Such mechanism prevents the use of Extended 
Sequence Number and limits the number of packet to be sent to 2** 24 =  
16777216, that is 16 M.

Unless some mechanism are provided to avoid collision between Sequence Number, 
( and so IV ), Implicit IV MUST NOT be used.

That works…



Regarding the second comment, I guess the idea was to mention that a responser 
cannot select a IIV Transform unless being sent by the initiator. I propose the 
following text. Do it address your comment ?

OLD:

   The rules of SA payload processing ensure that the responder will
   never send an SA payload containing the IIV indicator to an initiator
   that does not support IIV.


NEW:

   The rules of SA payload processing ensure that the responder will
   never send an SA payload containing the IIV transform to an initiator
   that does not support IIV.

I’m wondering whether this is necessary to state this.  For example, RFC 7634 
(the ChaCha IPsec transform) does not have any similar language, even though 
(like this draft) they define a new transform id.

However, I’m not demanding any change; the text just sounds redundant to me…



The reason for not having AES_CTR was that the transform is on its way to be 
retired. I propose to remove AES-CTR, but if there is a need to provide AES-CTR 
with implicit IV we coudl also add additional code points.

I am currently proposing the following text:

OLD:
   AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
   implement the implicit IV described in this document.

NEW:

   AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
   implement the implicit IV described in this document.

Works for me.


Yours,
Daniel
On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) 
<sfluh...@cisco.com<mailto:sfluh...@cisco.com>> wrote:

-  Section 4: “Section 3.5 of [RFC6407] explains how repetition MAY BE 
prevented by using a prefix for each group member”
Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bits of 
the 8 byte sequence number.  Used literally, this doesn’t work, as the top 8 
bits of the 8 byte sequence number are never expressed in the packet in 
implicit-iv.  You could put them in the top 8 bits of the 4 byte sequence 
number (which means you can’t use ESN, but it didn’t work in the multisender 
case anyways), but that would mean that each sender would be limited to 16M 
packets. I believe that these details are distinct enough that (if this is 
considered a viable alternative) they should be explicitly listed (including 
the 16M packet restriction).  Alternatively, we can just forbid this transform 
in the multisender case.


-  Section 6: “The rules of SA payload processing ensure that the 
responder will never send an SA payload containing the IIV indicator to an 
initiator that does not support IIV”

I believe that this is stale text; the current draft doesn’t use an indicator; 
instead, it defines separate transforms IDs.


-  Section 8 has “AES-CTR … [is] likely to implement the implicit IV 
described in this document”; however the transform ENCR_AES_CTR_IIV is not 
defined.  Is this intended?  Should we either remove the AES-CTR algorithm from 
the list of “likely to implement”, or should we actually define the transform 
id for it?



___
IPsec mailing list
IPsec@ietf.org<mailto: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] Comments on draft-ietf-ipsecme-implicit-iv

[Daniel Migault]

Thank you Scott for your comments.

I understand the first comment as a text clarification to comment on the
mechanism provided by section 3.5 of RFC6407 and explicitely mention that
is does not apply here. Does the replacement below addresses your concern ?

OLD:
   Section 3.5 of [RFC6407] explains how
   repetition MAY BE prevented by using a prefix for each group member,
   which could be prefixed to the Sequence Number.  Otherwise, Implicit
   IV MUST NOT be used in multicast scenarios.

NEW:
   Section 3.5 of [RFC6407] provides a mechanism that MAY be used to
prevent IV collisions when the same key is used by multiple users. The
mechanism consists in partitioning the IV space between users by assigning
the most significant byte to a user. When implicit IV transforms are used,
such mechanism cannot be applied as the IV is not sent, but instead it is
derived from the Sequence Number. A similar mechanism could be used by
associating the most significant byte of the Sequence Number to a sender,
while the 3 remaining bytes will be used to carry the counter value. Such
mechanism prevents the use of Extended Sequence Number and limits the
number of packet to be sent to 2** 24 =  16777216, that is 16 M.

Unless some mechanism are provided to avoid collision between Sequence
Number, ( and so IV ), Implicit IV MUST NOT be used.


Regarding the second comment, I guess the idea was to mention that a
responser cannot select a IIV Transform unless being sent by the initiator.
I propose the following text. Do it address your comment ?

OLD:

   The rules of SA payload processing ensure that the responder will
   never send an SA payload containing the IIV indicator to an initiator
   that does not support IIV.


NEW:

   The rules of SA payload processing ensure that the responder will
   never send an SA payload containing the IIV transform to an initiator
   that does not support IIV.


The reason for not having AES_CTR was that the transform is on its way to
be retired. I propose to remove AES-CTR, but if there is a need to provide
AES-CTR with implicit IV we coudl also add additional code points.

I am currently proposing the following text:

OLD:
   AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
   implement the implicit IV described in this document.

NEW:

   AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
   implement the implicit IV described in this document.


Yours,
Daniel

On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:

> -  Section 4: “Section 3.5 of [RFC6407] explains how repetition
> MAY BE prevented by using a prefix for each group member”
>
> Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8
> bits of the 8 byte sequence number.  Used literally, this doesn’t work, as
> the top 8 bits of the 8 byte sequence number are never expressed in the
> packet in implicit-iv.  You could put them in the top 8 bits of the 4 byte
> sequence number (which means you can’t use ESN, but it didn’t work in the
> multisender case anyways), but that would mean that each sender would be
> limited to 16M packets. I believe that these details are distinct enough
> that (if this is considered a viable alternative) they should be explicitly
> listed (including the 16M packet restriction).  Alternatively, we can just
> forbid this transform in the multisender case.
>
>
>
> -  Section 6: “The rules of SA payload processing ensure that the
> responder will never send an SA payload containing the IIV indicator to an
> initiator that does not support IIV”
>
> I believe that this is stale text; the current draft doesn’t use an
> indicator; instead, it defines separate transforms IDs.
>
>
>
> -  Section 8 has “AES-CTR … [is] likely to implement the implicit
> IV described in this document”; however the transform ENCR_AES_CTR_IIV is
> not defined.  Is this intended?  Should we either remove the AES-CTR
> algorithm from the list of “likely to implement”, or should we actually
> define the transform id for it?
>
>
>
> ___
> 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] Comments on draft-ietf-ipsecme-implicit-iv

[Scott Fluhrer (sfluhrer)]

Rereading this, I have to do one correction:

From: IPsec  On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 2:11 PM
To: IPsecme WG (ipsec@ietf.org) 
Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv


-  Section 4: "Section 3.5 of [RFC6407] explains how repetition MAY BE 
prevented by using a prefix for each group member"
Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bits of 
the 8 byte sequence number.
I meant "the top 8 bits of the 8 byte explicit IV"...

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