Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Daniel Migault]

Hi Tero,

Thank you for the feed back, my understanding is that we have a a consensus
that Transform ID is the preferred way. I will update the draft accordingly
and post a new version next week.

BR,
Daniel

On Fri, Jun 17, 2016 at 9:41 AM, Tero Kivinen  wrote:

> Daniel Migault writes:
> > Regarding the negotiation of the use of the implicit IV three ways have
> been
> > proposed. Currently it seems that the consensus is more encline to define
> > Transform IDs. However, it has been raised that Transform Attributes
> might be
> > a better protocol design choice.
>
> My personal preference is for Transform IDs.
>
> > I would like to understand if there are any guidance whether using
> attributes
> > is preferred to ID or vice versa and if there is any preference in using
> > IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute.
>
> Both with Transform IDs and Transform Attributes you need to duplicate
> each cipher support things. The payload would be either:
>
>  SA Payload
>  |
>  +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
>  |   |7 transforms,  SPI = 0x052357bb )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 128 )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 192 )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 256 )
>  |   |
>  |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
>  |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
>  |   +-- Transform ESN ( Name = ESNs )
>  |   +-- Transform ESN ( Name = No ESNs )
>  |
>  +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
>  |6 transforms,  SPI = 0x35a1d6f2 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 128 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 256 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
>  | +-- Attribute ( Key Length = 128 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
>  | +-- Attribute ( Key Length = 256 )
>  |
>  +-- Transform ESN ( Name = ESNs )
>  +-- Transform ESN ( Name = No ESNs )
>
> Or:
>
>  SA Payload
>  |
>  +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
>  |   |7 transforms,  SPI = 0x052357bb )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 128 )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 192 )
>  |   |
>  |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
>  |   | +-- Attribute ( Key Length = 256 )
>  |   |
>  |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
>  |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
>  |   +-- Transform ESN ( Name = ESNs )
>  |   +-- Transform ESN ( Name = No ESNs )
>  |
>  +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
>  |6 transforms,  SPI = 0x35a1d6f2 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 128 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 256 )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 128 )
>  | +-- Attribute ( Implicit = Yes )
>  |
>  +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
>  | +-- Attribute ( Key Length = 256 )
>  | +-- Attribute ( Implicit = Yes )
>  |
>  +-- Transform ESN ( Name = ESNs )
>  +-- Transform ESN ( Name = No ESNs )
>
> where missing Implicit would mean same as Implicit = No.
>
> The Transform ID version provides more compact encoding, and I think
> it is cleaner.
>
> If transform attribute version is used, that would provide easy way to
> expand this for every cipher we have, i.e. including
> ENCR_CAMELLIA_CCM, i.e. if we just say it is allowed for
> ENCR_CAMELLIA_CCM too, then it can use it. For the Transform ID option
> we need to allocate separate ID for ENCR_CAMELLIA_CCM_IIV to allow it
> using implicit IV.
>
> Transform IDs are fairly cheap, and I think it is better that we
> explictly mention which ciphers can use this, and doing this by
> allocating separate number for them is clean way of indicating that.
> Otherwise we need table listing which attributes are allowed with
> which cipher...
> --
> 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] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Tero Kivinen]

Daniel Migault writes:
> Regarding the negotiation of the use of the implicit IV three ways have been
> proposed. Currently it seems that the consensus is more encline to define
> Transform IDs. However, it has been raised that Transform Attributes might be
> a better protocol design choice.

My personal preference is for Transform IDs. 

> I would like to understand if there are any guidance whether using attributes
> is preferred to ID or vice versa and if there is any preference in using 
> IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute.

Both with Transform IDs and Transform Attributes you need to duplicate
each cipher support things. The payload would be either:

 SA Payload
 |
 +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
 |   |7 transforms,  SPI = 0x052357bb )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 128 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 192 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 256 )
 |   |
 |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
 |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
 |   +-- Transform ESN ( Name = ESNs )
 |   +-- Transform ESN ( Name = No ESNs )
 |
 +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
 |6 transforms,  SPI = 0x35a1d6f2 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 128 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 256 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
 | +-- Attribute ( Key Length = 128 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
 | +-- Attribute ( Key Length = 256 )
 |
 +-- Transform ESN ( Name = ESNs )
 +-- Transform ESN ( Name = No ESNs )

Or:

 SA Payload
 |
 +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
 |   |7 transforms,  SPI = 0x052357bb )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 128 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 192 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   | +-- Attribute ( Key Length = 256 )
 |   |
 |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
 |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
 |   +-- Transform ESN ( Name = ESNs )
 |   +-- Transform ESN ( Name = No ESNs )
 |
 +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
 |6 transforms,  SPI = 0x35a1d6f2 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 128 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 256 )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 128 )
 | +-- Attribute ( Implicit = Yes )
 |
 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
 | +-- Attribute ( Key Length = 256 )
 | +-- Attribute ( Implicit = Yes )
 |
 +-- Transform ESN ( Name = ESNs )
 +-- Transform ESN ( Name = No ESNs )

where missing Implicit would mean same as Implicit = No.

The Transform ID version provides more compact encoding, and I think
it is cleaner.

If transform attribute version is used, that would provide easy way to
expand this for every cipher we have, i.e. including
ENCR_CAMELLIA_CCM, i.e. if we just say it is allowed for
ENCR_CAMELLIA_CCM too, then it can use it. For the Transform ID option
we need to allocate separate ID for ENCR_CAMELLIA_CCM_IIV to allow it
using implicit IV. 

Transform IDs are fairly cheap, and I think it is better that we
explictly mention which ciphers can use this, and doing this by
allocating separate number for them is clean way of indicating that.
Otherwise we need table listing which attributes are allowed with
which cipher...
-- 
kivi...@iki.fi

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Paul Wouters]

On Wed, 15 Jun 2016, Daniel Migault wrote:


You are right. Would the word "generate" more appropriated ?


"obtain" ?


Or just reveal your "secret" and state "is taken from the ESP sequence number".

Paul

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Daniel Migault]

Hi Yoav,

You are right. Would the word "generate" more appropriated ?

OLD:

This document defines how to compute the nonce locally when it is implicit.
It also specifies how peers agree with Internet Key Exchange version 2
IKEv2 on using an implicit IV versus an explicit IV.

NEW:

This document defines how to generate the nonce locally when it is
implicit. It also specifies how peers agree with Internet Key Exchange
version 2 IKEv2 on using an implicit IV versus an explicit IV

BR,
Daniel

On Wed, Jun 15, 2016 at 3:56 PM, Yoav Nir  wrote:

> Hi, Daniel
>
> I think since we didn’t go with some of the wild ideas that would allow
> implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re
> pretty much just copying the sequence number. “Compute” implies something a
> bit more CPU intensive.
>
> Yoav
>
> On 15 Jun 2016, at 10:50 PM, Daniel Migault 
> wrote:
>
> Hi Paul,
>
> I hope this has been clarified. In order to clarify this I updated the
> text in the intro:
>
> OLD:
> This document defines how to compute the nonce locally when it is
> implicit. It also specifies how to negotiate this behavior within the
> Internet Key Exchange version 2 (IKEv2 - RFC7296).
>
> NEW:
>
> This document defines how to compute the nonce locally when it is
> implicit. It also specifies how peers agree with Internet Key Exchange
> version 2 IKEv2 on using an implicit IV versus an explicit IV
>
>
> Please let us know if that address your purpose.
>
> BR,
> Daniel
>
> On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir  wrote:
>
>> Hi, Paul
>>
>> On 10 Jun 2016, at 5:42 AM, Paul Wouters  wrote:
>>
>> > On Thu, 9 Jun 2016, Daniel Migault wrote:
>> >
>> >> Please find our new proposal with ESP using implicit IV [1]. We would
>> like to present and discuss it at the next IETF meeting.
>> >
>> > I must understand it wrong...
>> >
>> > Aren't these IVs different per ESP packet? And unrelated to IKE
>> > values? How do both parties calculate the IV if it is not send as part
>> > of the packet?
>> >
>> >> From what I understand, only part of that comes from IKE (aka the salt
>> > values that are taken from the IKE KEYMAT). As far as I understand, it
>> > still needs to be unpredictable?
>> >
>> > If this IV somehow comes from IKE, it might be very tricky for FIPS
>> > certifications, because the security of the ESP IV then depends on
>> > the IKE userland.
>> >
>>
>> All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM,
>> ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP
>> packet.
>>
>> For all of those algorithms, the respective RFC recommends to use a
>> counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead,
>> but a counter is simpler.
>>
>> ESP already has a counter - the packet sequence. If you follow the advice
>> in the RFCs the ESP header will look like this:
>>
>>  0   1   2   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>> |   Security Parameters Index (SPI) | ^Int.
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
>> |  Sequence Number  | |ered
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
>> |  IV   | |
>> |   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
>>
>>
>> And the Sequence Number and IV fields will hold the exact same number,
>> except that one is 32-bit while the other is 64-bit.
>>
>> Our draft simply negotiates omitting the IV field since it is redundant.
>>
>> Hope this helps
>>
>> Yoav
>>
>>
>> ___
>> 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-mglt-ipsecme-implicit-iv-00.txt

[Daniel Migault]

Hi,

Regarding the negotiation of the use of the implicit IV three ways have
been proposed. Currently it seems that the consensus is more encline to
define Transform IDs. However, it has been raised that Transform Attributes
might be a better protocol design choice.

I would like to understand if there are any guidance whether using
attributes is preferred to ID or vice versa and if there is any preference
in using  IMPLICIT IV Transform ID versus an IMPLICIT IV Transform
Attribute.


Here is a summary of the comments we received on the different ways to
negotiate the use of the implicit IV.

   - a) IMPLICIT Transform Type seems to over complexify the the management
   of proposals.
   - b) IMPLICIT IV Transform ID seems the easiest way to move forward. In
   addition, IKEv2 is known to behave properly with new Transform IDs.
   - c) IMPLICIT IV Transform Attribute requires additional parsing. This
   is something that is not widely used outside key sizes. This solution might
   be preferred if it is considered a better architecture design than b).


   BR,
Daniel




On Wed, Jun 15, 2016 at 4:14 PM, Daniel Migault  wrote:

> Hi Yaron,
>
> Thanks Yaron for the comments so I updated my local copy replacing RFC4104
> by RFC4106 ;-)
> I also assume that leaving AES-CTR is fine, and so keep it in the draft.
>
> In the first version of the draft we described a way to have an implicit
> IV with AES-CBC. It was based on an additional key derivation for each
> direction and the IV was the sequence number encrypted with the key.
> During the presentation, we agreed that the additional complexity would not
> worth. The reason for that text is to make it clear that would be feasible.
>
> BR,
> Daniel
>
>
> On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffer 
> wrote:
>
>> On 13/06/16 06:00, Yoav Nir wrote:
>>
>>>
>>> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer > wrote:

 Hi,

 The document takes care to not define Implicit IV for AES-CBC, and I
 believe the underlying reason is malleability of the encryption. The
 same would apply to AES-CTR. So I would suggest to:

   * Exclude AES-CTR from this draft, or...
   * Better yet, restrict the draft to AEAD algorithms.

 BTW, the reference for AES-GCM is incorrect. Should be 4106.

 Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key
 material. Is that kept intact by the current proposal?


>>> Hi, Yaron
>>>
>>> AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
>>> confusing terminology:
>>>
>>>   * The 32-bit per-SA value derived from IKE is called “nonce” in RFC
>>> 3686 and “salt” in RFC 4106 (thanks for the corrected reference).
>>>   * The concatenation of 32-bit per-SA value and IV is called “nonce” in
>>> RFC 4106 and doesn’t have a name in RFC 3686.
>>>   * The concatenation of 32-bit per-SA value, IV, and block counter is
>>> called “counter block”  in RFC 3686, but isn’t explicitly mentioned
>>> in RFC 4106. The GCM spec also calls it “counter block”.
>>>
>>>
>>> AFAICT it is not malleable like CBC. In CBC the issue was that an
>>> attacker knowing the next IV would be able to generate the first block
>>> of the next message such that IV xor Block0 would be whatever the
>>> attacker wanted. That block would be the input to the encryption
>>> function and thus the attacker could force the encryptor to encrypt
>>> whatever block it wanted. With counter mode (or GCM or CCM) the attacker
>>> has no control on the inputs to the encryption function. That is why RFC
>>> 3686 has text similar to the other documents:
>>>
>>> The same
>>> IV and key combination MUST NOT be used more than once.  The
>>> encryptor can generate the IV in any manner that ensures uniqueness.
>>> Common approaches to IV generation include *incrementing a counter*
>>> for
>>> each packet and linear feedback shift registers (LFSRs).
>>>
>>> So I think CTR belongs in this draft as much as the others.
>>>
>>> And yes, the GCM salt or the CTR nonce are derived in the same way and
>>> used in the same way.
>>>
>>> Yoav
>>>
>>>
>> AES-CTR is potentially malleable by a MITM who can change counter values
>> into ones she'd observed before. However since RFC 3686 is very emphatic
>> about the need for integrity protection (Sec. 3.3), we should be fine.
>>
>> Thanks,
>> Yaron
>>
>>
>> ___
>> 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-mglt-ipsecme-implicit-iv-00.txt

[Daniel Migault]

Hi Yaron,

Thanks Yaron for the comments so I updated my local copy replacing RFC4104
by RFC4106 ;-)
I also assume that leaving AES-CTR is fine, and so keep it in the draft.

In the first version of the draft we described a way to have an implicit IV
with AES-CBC. It was based on an additional key derivation for each
direction and the IV was the sequence number encrypted with the key.
During the presentation, we agreed that the additional complexity would not
worth. The reason for that text is to make it clear that would be feasible.

BR,
Daniel


On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffer 
wrote:

> On 13/06/16 06:00, Yoav Nir wrote:
>
>>
>> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer >> > wrote:
>>>
>>> Hi,
>>>
>>> The document takes care to not define Implicit IV for AES-CBC, and I
>>> believe the underlying reason is malleability of the encryption. The
>>> same would apply to AES-CTR. So I would suggest to:
>>>
>>>   * Exclude AES-CTR from this draft, or...
>>>   * Better yet, restrict the draft to AEAD algorithms.
>>>
>>> BTW, the reference for AES-GCM is incorrect. Should be 4106.
>>>
>>> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key
>>> material. Is that kept intact by the current proposal?
>>>
>>>
>> Hi, Yaron
>>
>> AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
>> confusing terminology:
>>
>>   * The 32-bit per-SA value derived from IKE is called “nonce” in RFC
>> 3686 and “salt” in RFC 4106 (thanks for the corrected reference).
>>   * The concatenation of 32-bit per-SA value and IV is called “nonce” in
>> RFC 4106 and doesn’t have a name in RFC 3686.
>>   * The concatenation of 32-bit per-SA value, IV, and block counter is
>> called “counter block”  in RFC 3686, but isn’t explicitly mentioned
>> in RFC 4106. The GCM spec also calls it “counter block”.
>>
>>
>> AFAICT it is not malleable like CBC. In CBC the issue was that an
>> attacker knowing the next IV would be able to generate the first block
>> of the next message such that IV xor Block0 would be whatever the
>> attacker wanted. That block would be the input to the encryption
>> function and thus the attacker could force the encryptor to encrypt
>> whatever block it wanted. With counter mode (or GCM or CCM) the attacker
>> has no control on the inputs to the encryption function. That is why RFC
>> 3686 has text similar to the other documents:
>>
>> The same
>> IV and key combination MUST NOT be used more than once.  The
>> encryptor can generate the IV in any manner that ensures uniqueness.
>> Common approaches to IV generation include *incrementing a counter*
>> for
>> each packet and linear feedback shift registers (LFSRs).
>>
>> So I think CTR belongs in this draft as much as the others.
>>
>> And yes, the GCM salt or the CTR nonce are derived in the same way and
>> used in the same way.
>>
>> Yoav
>>
>>
> AES-CTR is potentially malleable by a MITM who can change counter values
> into ones she'd observed before. However since RFC 3686 is very emphatic
> about the need for integrity protection (Sec. 3.3), we should be fine.
>
> Thanks,
> Yaron
>
>
> ___
> 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-mglt-ipsecme-implicit-iv-00.txt

[Yoav Nir]

Hi, Daniel

I think since we didn’t go with some of the wild ideas that would allow 
implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re pretty 
much just copying the sequence number. “Compute” implies something a bit more 
CPU intensive.

Yoav

> On 15 Jun 2016, at 10:50 PM, Daniel Migault  
> wrote:
> 
> Hi Paul, 
> 
> I hope this has been clarified. In order to clarify this I updated the text 
> in the intro:
> 
> OLD:
> This document defines how to compute the nonce locally when it is implicit. 
> It also specifies how to negotiate this behavior within the Internet Key 
> Exchange version 2 (IKEv2 - RFC7296).
> 
> NEW:
> 
> This document defines how to compute the nonce locally when it is implicit. 
> It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 
> on using an implicit IV versus an explicit IV
> 
> 
> Please let us know if that address your purpose.
> 
> BR, 
> Daniel
> 
> On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir  > wrote:
> Hi, Paul
> 
> On 10 Jun 2016, at 5:42 AM, Paul Wouters  > wrote:
> 
> > On Thu, 9 Jun 2016, Daniel Migault wrote:
> >
> >> Please find our new proposal with ESP using implicit IV [1]. We would like 
> >> to present and discuss it at the next IETF meeting.
> >
> > I must understand it wrong...
> >
> > Aren't these IVs different per ESP packet? And unrelated to IKE
> > values? How do both parties calculate the IV if it is not send as part
> > of the packet?
> >
> >> From what I understand, only part of that comes from IKE (aka the salt
> > values that are taken from the IKE KEYMAT). As far as I understand, it
> > still needs to be unpredictable?
> >
> > If this IV somehow comes from IKE, it might be very tricky for FIPS
> > certifications, because the security of the ESP IV then depends on
> > the IKE userland.
> >
> 
> All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, 
> ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP 
> packet.
> 
> For all of those algorithms, the respective RFC recommends to use a counter 
> to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a 
> counter is simpler.
> 
> ESP already has a counter - the packet sequence. If you follow the advice in 
> the RFCs the ESP header will look like this:
> 
>  0   1   2   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> |   Security Parameters Index (SPI) | ^Int.
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
> |  Sequence Number  | |ered
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
> |  IV   | |
> |   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
> 
> 
> And the Sequence Number and IV fields will hold the exact same number, except 
> that one is 32-bit while the other is 64-bit.
> 
> Our draft simply negotiates omitting the IV field since it is redundant.
> 
> Hope this helps
> 
> Yoav
> 
> 
> ___
> 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-mglt-ipsecme-implicit-iv-00.txt

[Yaron Sheffer]

On 13/06/16 06:00, Yoav Nir wrote:



On 10 Jun 2016, at 5:39 PM, Yaron Sheffer > wrote:

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I
believe the underlying reason is malleability of the encryption. The
same would apply to AES-CTR. So I would suggest to:

  * Exclude AES-CTR from this draft, or...
  * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key
material. Is that kept intact by the current proposal?



Hi, Yaron

AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
confusing terminology:

  * The 32-bit per-SA value derived from IKE is called “nonce” in RFC
3686 and “salt” in RFC 4106 (thanks for the corrected reference).
  * The concatenation of 32-bit per-SA value and IV is called “nonce” in
RFC 4106 and doesn’t have a name in RFC 3686.
  * The concatenation of 32-bit per-SA value, IV, and block counter is
called “counter block”  in RFC 3686, but isn’t explicitly mentioned
in RFC 4106. The GCM spec also calls it “counter block”.


AFAICT it is not malleable like CBC. In CBC the issue was that an
attacker knowing the next IV would be able to generate the first block
of the next message such that IV xor Block0 would be whatever the
attacker wanted. That block would be the input to the encryption
function and thus the attacker could force the encryptor to encrypt
whatever block it wanted. With counter mode (or GCM or CCM) the attacker
has no control on the inputs to the encryption function. That is why RFC
3686 has text similar to the other documents:

The same
IV and key combination MUST NOT be used more than once.  The
encryptor can generate the IV in any manner that ensures uniqueness.
Common approaches to IV generation include *incrementing a counter* for
each packet and linear feedback shift registers (LFSRs).

So I think CTR belongs in this draft as much as the others.

And yes, the GCM salt or the CTR nonce are derived in the same way and
used in the same way.

Yoav



AES-CTR is potentially malleable by a MITM who can change counter values 
into ones she'd observed before. However since RFC 3686 is very emphatic 
about the need for integrity protection (Sec. 3.3), we should be fine.


Thanks,
Yaron

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Tommy Pauly]

Here are my thoughts on the options for communicating the Implicit IV option in 
the proposal:

- A new transform type is problematic, as pointed out by Valery and Paul 
already, because it adds complexity to the proposal structure for configuring 
and parsing. This seems to be the least desirable option.

- The new transform ID is easy to add to implementations because it is just 
another value for an existing field. There is a slight downside in needing new 
ID allocations for what will be essentially a duplicate algorithm, but numbers 
are cheap. I think this is the easiest option to adopt and pass between 
implementation layers (userspace, kernel, etc), but once the layer doing 
encryption is using the value, it will probably want to flatten the information 
out into the original algorithm value and a flag that the IV is implicit.

- A new transform attribute is attractive as a clean protocol design, since it 
seems to be the type of information that transform attributes are meant to 
hold. There aren't many uses of transform attributes currently, so this may add 
work to protocol parsers. This may require passing the flag for implicit IVs 
separately throughout the implementation, rather than as part of the transform 
ID, but I would be willing to do this as an implementer for the sake of a 
cleaner protocol.

As such, I vote for either option 2 or 3: 2 for ease of implementation, 3 for 
clean protocol design.

Thanks,
Tommy

> On Jun 9, 2016, at 9:19 AM, Daniel Migault  
> wrote:
> 
> Hi,
> 
> Please find our new proposal with ESP using implicit IV [1]. We would like to 
> present and discuss it at the next IETF meeting.
> 
> We would be happy to have the WG opinion on which you think is the better way 
> to negotiate the implicit IV between two peers. The different options are 
> detailed in section 5 and copy paste here in the email:
> 
> """
>   Negotiation of the use of implicit IV can be done in 3 different
>   ways:
> 
>   o  An IMPLICIT IV Transform Type.  A proposal that contains this
>  transform type requires (if accepted) that IPsec use the implicit
>  IV and not include an explicit IV in the packets.  To facilitate
>  backward compatibility with non-supporting implementations the
>  Initiator SHOULD add another proposal that does not include this
>  transform type as well as cryptographic suite the Initiator does
>  not support the implicit IV.
> 
>   o  An IMPLICIT IV Transform ID.  This doubles the number of ENCR
>  transform IDs by creating an ENCR_AES_CCM_16_IIV for each
>  ENCR_AES_CCM_16.
> 
>   o  An IMPLICIT IV Transform Attribute, which would be associated to a
>  Transform Type ID, specifying the use of an implicit IV. marks a
>  particular ENCR transform as using implicit IVs.  To facilitate
>  backward compatibility with non-supporting implementations the
>  Initiator SHOULD add another ENCR transform for each algorithm so
>  marked.  In other words, for each ENCR_AES_CCM_16 with
>  keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16
>  with keylength=256 and no IIV attribute.
> 
> """  
> 
> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> Sent: Thursday, June 09, 2016 12:12 PM
> To: Tobias Guggemos; Yoav Nir; Daniel Migault
> Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt
> 
> 
> A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
> 
> Name: draft-mglt-ipsecme-implicit-iv
> Revision: 00
> Title:Implicit IV for Counter-based Ciphers in IPsec
> Document date:2016-06-09
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00
> 
> 
> Abstract:
>   IPsec ESP sends an initialization vector (IV) or nonce in each
>   packet, adding 8 or 16 octets.  Some algorithms such as AES-GCM, AES-
>   CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not
>   require an unpredictable nonce.  When using such algorithms the
>   packet counter value can be used to generate a nonce, saving 8 octets
>   per packet.  This document describes how to do this.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec 

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Yaron Sheffer]

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I 
believe the underlying reason is malleability of the encryption. The 
same would apply to AES-CTR. So I would suggest to:


 * Exclude AES-CTR from this draft, or...
 * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key 
material. Is that kept intact by the current proposal?


Thanks,

Yaron

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Paul Wouters]

On Fri, 10 Jun 2016, Yoav Nir wrote:


All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, 
ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP 
packet.

For all of those algorithms, the respective RFC recommends to use a counter to 
guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a counter is 
simpler.

ESP already has a counter - the packet sequence. If you follow the advice in 
the RFCs the ESP header will look like this:


Ok, now I understand. Thanks.

I'm with Valery about using a new algorithm number. The proposal parser
is already pretty ugly as-is without adding more complexity. It also
allows to re-use the existing userland -> kernel infrastructure as no
new options need to be added to that communication layer. Just another
algorithm number.

Paul

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Yoav Nir]

Hi, Paul

On 10 Jun 2016, at 5:42 AM, Paul Wouters  wrote:

> On Thu, 9 Jun 2016, Daniel Migault wrote:
> 
>> Please find our new proposal with ESP using implicit IV [1]. We would like 
>> to present and discuss it at the next IETF meeting.
> 
> I must understand it wrong...
> 
> Aren't these IVs different per ESP packet? And unrelated to IKE
> values? How do both parties calculate the IV if it is not send as part
> of the packet?
> 
>> From what I understand, only part of that comes from IKE (aka the salt
> values that are taken from the IKE KEYMAT). As far as I understand, it
> still needs to be unpredictable?
> 
> If this IV somehow comes from IKE, it might be very tricky for FIPS
> certifications, because the security of the ESP IV then depends on
> the IKE userland.
> 

All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, 
ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP 
packet.

For all of those algorithms, the respective RFC recommends to use a counter to 
guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a counter is 
simpler.

ESP already has a counter - the packet sequence. If you follow the advice in 
the RFCs the ESP header will look like this:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|  Sequence Number  | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
|  IV   | |   
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 


And the Sequence Number and IV fields will hold the exact same number, except 
that one is 32-bit while the other is 64-bit.

Our draft simply negotiates omitting the IV field since it is redundant.

Hope this helps

Yoav


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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Paul Wouters]

On Thu, 9 Jun 2016, Daniel Migault wrote:


Please find our new proposal with ESP using implicit IV [1]. We would like to 
present and discuss it at the next IETF meeting.


I must understand it wrong...

Aren't these IVs different per ESP packet? And unrelated to IKE
values? How do both parties calculate the IV if it is not send as part
of the packet?


From what I understand, only part of that comes from IKE (aka the salt

values that are taken from the IKE KEYMAT). As far as I understand, it
still needs to be unpredictable?

If this IV somehow comes from IKE, it might be very tricky for FIPS
certifications, because the security of the ESP IV then depends on
the IKE userland.

Paul

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Daniel Migault]

Hi,

Please find our new proposal with ESP using implicit IV [1]. We would like to 
present and discuss it at the next IETF meeting.

We would be happy to have the WG opinion on which you think is the better way 
to negotiate the implicit IV between two peers. The different options are 
detailed in section 5 and copy paste here in the email:

"""
   Negotiation of the use of implicit IV can be done in 3 different
   ways:

   o  An IMPLICIT IV Transform Type.  A proposal that contains this
  transform type requires (if accepted) that IPsec use the implicit
  IV and not include an explicit IV in the packets.  To facilitate
  backward compatibility with non-supporting implementations the
  Initiator SHOULD add another proposal that does not include this
  transform type as well as cryptographic suite the Initiator does
  not support the implicit IV.

   o  An IMPLICIT IV Transform ID.  This doubles the number of ENCR
  transform IDs by creating an ENCR_AES_CCM_16_IIV for each
  ENCR_AES_CCM_16.

   o  An IMPLICIT IV Transform Attribute, which would be associated to a
  Transform Type ID, specifying the use of an implicit IV. marks a
  particular ENCR transform as using implicit IVs.  To facilitate
  backward compatibility with non-supporting implementations the
  Initiator SHOULD add another ENCR transform for each algorithm so
  marked.  In other words, for each ENCR_AES_CCM_16 with
  keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16
  with keylength=256 and no IIV attribute.

"""  

[1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, June 09, 2016 12:12 PM
To: Tobias Guggemos; Yoav Nir; Daniel Migault
Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt


A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt
has been successfully submitted by Daniel Migault and posted to the IETF 
repository.

Name:   draft-mglt-ipsecme-implicit-iv
Revision:   00
Title:  Implicit IV for Counter-based Ciphers in IPsec
Document date:  2016-06-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt
Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00


Abstract:
   IPsec ESP sends an initialization vector (IV) or nonce in each
   packet, adding 8 or 16 octets.  Some algorithms such as AES-GCM, AES-
   CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not
   require an unpredictable nonce.  When using such algorithms the
   packet counter value can be used to generate a nonce, saving 8 octets
   per packet.  This document describes how to do this.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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