Re: [IPsec] Teaser for pitch talk at IETF 108

[Tero Kivinen <[e-mail]>]

Steffen Klassert writes:
> We have already the option to send the high sequence number bits
> when a combined mode algorithm is used.
> 
> RFC 4303, Section 2.2.1. says:
> 
> If a combined mode algorithm is employed, the algorithm choice determines
> whether the high-order ESN bits are transmitted or are included implicitly
> in the computation.

We do not have any algorithms that use that feature, and we do not
have option to negotiate it in IKEv2.

We could add new value for transform type 5 (Extended Sequence
Numbers) to say that we use extended sequence number, and that we
actually transmit the full extended sequence number. 

> We could just give multicast the same option if it wants to use
> replay protection.

As others have already pointed out earlier, with multicast the upper
layer must make care of replays and dropped packets themselves in any
case, so doing that also on the IPsec level does not really provide
that much more security. I mean if the multicast protocol run over UDP
over IPsec simply has internal sequence number inside the UDP, which
will then be authenticated by the IPsec that should be good enough for
replay protection.

There is issue that in that case attacker could do Denial of Service
attack against the IPsec, by replaying packets, and then the IPsec
gateway would decrypt and forward them.

When using multicast you already need to use SPI, and destination
address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2
there. On the other hand you could use the SPI, destination address,
and source address to find the replay window and largest sequence
number used if you want to do anti-replay protection on multicast SAs
so that each sender has separate replay windows.

I assume this is not normally done as it would create so much more
extra work for keeping track of replay windows for every single
sender, and where the benefit is not that big as upper layer protocols
usually do have anti-replay built in.

> > And about security. In order to have IV combined with 
> > ESN and sub-windows identifiers this proposal removes secret 
> > salt from the nonce. This may have impact on security. 
> > I'm not a cryptographer, but I believe the impact is not negligible.
> > On the last CFRG session a draft draft-wood-cfrg-aead-limits was
> > discussed that calculates limits of data to be safely encrypted
> > by various AEAD ciphers. The authors claimed that having 
> > secret salt in the nonce increases this limits in case of multi-user
> > attacks and that the results in the draft are calculated
> > for this case. If plain AEAD ciphers (with no secret salt) are used
> > the limits are lower. 
> 
> A secret salt in the nonce would be a new requirement anyway.
> I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for
> ChaCha20-Poly1305), both don't require a secret salt.

It is true that they do not need secret salt, but they do have
unpredictable salt, which is created by the key derivation step. My
understanding was that this proposal did get rid of that salt too:

----------------------------------------------------------------------
4.  Nonce Format

   The nonce passed to the GCM-AES encryption algorithm has the
   following layout:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Salt                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2: Nonce Format

   The components of the nonce are as follows:

   Salt
      The salt field is a four-octet value that is assigned at the
      beginning of the security association, and then remains constant
      for the life of the security association.  The salt SHOULD be
      unpredictable (i.e., chosen at random) before it is selected, but
      need not be secret.  We describe how to set the salt for a
      Security Association established via the Internet Key Exchange in
      Section 8.1.

-- 
[e-mail]