Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02
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 Kivinenwrote: > 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
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
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 Kivinenwrote: > 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
[IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02
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". -- In section 2 missing closing parenthesis and period: ... The same applies for ChaCha20-Poly1305 ([RFC7634]. Currently this nonce is sent in each ^ add missing ")". -- 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. -- 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. -- Section 5 and 6 need more text. I.e., you do not actually describe how the Implicit IV is negotiated in the IKE. You just tell that yes, it is negotiated, and there is no issues. So I suggest rewriting them as follows: -- 5. Initiator Behavior An initiator supporting this feature SHOULD propose implicit IV algorithms in the Transform Type 1 (Encryption Algorithm) Substructure of the Proposal Substructure inside the SA Payload. To facilitate backward compatibility with non-supporting peers the initiator SHOULD also include those same algorithms without Implicit IV (IIV) as separate transforms. 6. Responder Behavior The rules of SA Payload processing require that responder picks its algorithms from the proposal sent by the initiator, thus this will ensure that the responder will never send an SA payload containing the IIV transform to an initiator that did not propose it. -- In section 8 I do not understand what the first sentence is trying to say. I think it should be better to rewrite the 1st paragraph in IANA fConsiderations section as follows: This section assigns new code points to the recommended AEAD suites provided in [RFC8221], thus the new Transform Type 1 - Encryption Algorithm Transform IDs [IANA] are as defined below: -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec