Re: [secdir] [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-04

["MORTON JR., AL" <[e-mail]>]

Hi Brian,

Revising our key question:

For Encrypted mode:  What if we combined AES-CBC-128 with our current Authentication HASH (SHA-256), for a complete (but two-part) solution?

Will this be acceptable, given our plan to use long-lived keys?

We would abandon the "authenticated encryption" preference stated earlier.

please let us know, thanks,
Al


> -----Original Message-----
> From: MORTON JR., AL
> Sent: Sunday, May 7, 2023 6:55 PM
> To: Brian Weis <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-
> 04
> 
> Hi Brian, reminder of our key question, below,
> Al
> 
> > -----Original Message-----
> > From: MORTON JR., AL
> > Sent: Sunday, April 23, 2023 9:26 AM
> > To: Brian Weis <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [ippm] Secdir early review of draft-ietf-ippm-capacity-
> protocol-
> > 04
> >
> > Hi Brian,
> >
> > We would like to receive your feedback on our proposal for a replacement
> > encryption algorithm:
> >
> > > Ok. We were attracted to the "authenticated encryption" aspect of GCM, but
> > we
> > > can get that with AES-CCM too.
> >
> > Does AES-CCM alleviate the issues and fit our plans to use long-lived keys,
> > etc.?
> >
> > With this feedback, we can proceed with updates to the draft.
> > thanks,
> > Al
> >
> > > -----Original Message-----
> > > From: MORTON JR., AL
> > > Sent: Sunday, March 19, 2023 5:08 PM
> > > To: Brian Weis <[e-mail]>; [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: RE: [ippm] Secdir early review of draft-ietf-ippm-capacity-
> > protocol-
> > > 04
> > >
> > > Hi Brian,
> > >
> > > Thanks for your reply on the second SEC-DIR early review!
> > >
> > > We have summarized the topics for reply, below. Your review is appended.
> > >
> > > Al and Len
> > >
> > >
> > > # Key comments and replies for discussion:
> > >
> > > > — The use of AES-GCM with a long-lived symmetric key (such as one
> > > > on an RFC 7210 key chain) is not safe. ... (suggests a CBC mode) ...
> > > and
> > > > — Unauthenticated encryption is generally seen as risky, so when...
> > >
> > > Ok. We were attracted to the "authenticated encryption" aspect of GCM, but
> > we
> > > can get that with AES-CCM too. The Initialization Vector (IV) will be
> > > generated by a pseudo-random generator with unique seed for each session,
> > and
> > > have sufficient size to avoid duplication over the life of a long-lived
> key.
> > > The IV can be communicated in the clear, so we will.
> > >
> > > > — Also, there are some additional parameters that need to determined
> > > > to guarantee interoperability. For example, which octets are
> > > > encrypted, if a partial block needs to be encrypted how is it padded
> > > > out before encryption to make a full block, and requirements on IV
> > > > generation (e.g., that is must be from a good quality random number
> > > > generator).
> > >
> > > We need to check if padding is needed for any of our PDUs, but the PDUs
> will
> > > be fixed size so it's a static fix.
> > > We'll specify the IV generation method.
> > >
> > >
> > >
> > > # Tension between Security and Measurement operation:
> > >
> > > > — Section 5.1.1 doesn’t say the network addresses and headers are
> > > > included in the digest. It’s generally good practice to include
> (them)...
> > >
> > > Our test scope includes ISP Subscribers, so NAPT transversal is critical
> and
> > > precludes including the addresses.
> > >
> > > > ... a valid message
> > > > (e.g., Setup Request) can be extracted and placed in a different
> > > > measurement flow that is not intended by the original sender. This is
> > > > a substitution attack.
> > >
> > > All of the IPPM test protocols are susceptible to the substitution attack,
> > and
> > > there is no thorough mitigation that we know-of (including time in the
> > digest
> > > is a partial mitigation).
> > >
> > > Packet De-duplication, in DTLS and IPsec:
> > > > This is generally seen as a feature for network
> > > > encryption methods.
> > > Right, but measurement systems expect to observe packet duplication when
> it
> > > occurs. A trade-off is required, and the primary goal is measurement.
> > >
> > >
> > > # Edits and Nits:
> > > We will take care of other requests for clarifications requested
> > > - digest coverage
> > > - MBZ definition
> > > -  “Support for client-server authentication ….”.
> > > - four Security modes, but encrypted tunnel makes five - becomes a
> paragraph
> > > - mismatch
> > >
> > > > -----Original Message-----
> > > > From: ippm <[e-mail]> On Behalf Of Brian Weis via
> Datatracker
> > > > Sent: Saturday, March 4, 2023 5:58 PM
> > > > To: [e-mail]
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: [ippm] Secdir early review of draft-ietf-ippm-capacity-
> protocol-
> > 04
> > > >
> > > > Reviewer: Brian Weis
> > > > Review result: Has Issues
> > > >
> > > > I have reviewed this document as part of the security directorate's
> > > > ongoing effort to review all IETF documents being processed by the
> > > > IESG. These comments were written primarily for the benefit of the
> > > > security area directors. Document editors and WG chairs should treat
> > > > these comments just like any other last call comments.
> > > >
> > > > General comments
> > > >
> > > > (1) The guidance of what bytes are included in the SHA-256 calculation
> > > > and result placed in the authDigest field might need some enhancement.
> > > >
> > > > — Some places say that the authDigest field is zeroed (e.g., Section
> > > > 4.2.2 ) and some says “The SHA-256 calculation SHALL cover all the
> > > > preceding fields.”, which seems to omit the auhDigest field. I guess
> > > > these aren't mutually exclusive statements, but it would be cleaner
> > > > to have all of the description in one place so it is clear.
> > > >
> > > > — Section 5.1.1 doesn’t say the network addresses and headers are
> > > > included in the digest. It’s generally good practice to include
> > > > more context into the digest calculation so that a valid message
> > > > (e.g., Setup Request) can’t be extracted and placed in a different
> > > > measurement flow that is not intended by the original sender. This is
> > > > a substitution attack.
> > > >
> > > > — If network addresses and headers aren’t included in the digest,
> > > > then it will be important to describe why the substitution attack
> > > > isn’t a threat. I understand that if NAT on the client that including
> > > > it's network address is not possible, but there's still an issue.
> > > >
> > > > — Note that the inclusion of authUnixTime with the receiver
> > > > checking “acceptable immediacy” is only a partial mitigation for a
> > > > substitution attack, since the receiver’s notion of “acceptable
> > > > immediacy” is apparently quite long from an attacker's perspective
> > > > “(+/- 2.5 minutes)” and any other message including this PDU sent
> > > > fron an attacker (e.g., with different network headers) during this
> > > > period will be acceptable to the receiver.  Reducing the window
> > > > size won’t completely mitigate this attack either.
> > > >
> > > > (2) There doesn’t seem to be a definition for the MBZ octets and
> > > > remainder bits, or a description of their purpose. (I’m guessing
> > > > it’s “must be zero” but even that should be defined for the reader.)
> > > >
> > > > Specific comments
> > > >
> > > > Section 4.2.4.
> > > >
> > > > — The use of AES-GCM with a long-lived symmetric key (such as one
> > > > on an RFC 7210 key chain) is not safe. The IV used by GCM is not a
> > > > random IV such as used by some other modes of which you might be
> > > > aware (e.g., CBC), but rather it is a counter that must NEVER
> > > > repeat with that key. Ensuring no repeats is not operationally
> > > > feasible for a key kept on a key chain. I.e., The counter must keep
> > > > incrementing between packets, reliably stored over a reboot so that
> > > > it isn't used again, and when the counter reaches the maximum value
> > > > the key is not longer usable. I would recommend specifying CBC mode
> > > > and a randomly chosen IV.
> > > >
> > > > — Also, there are some additional parameters that need to determined
> > > > to guarantee interoperability. For example, which octets are
> > > > encrypted, if a partial block needs to be encrypted how is it padded
> > > > out before encryption to make a full block, and requirements on IV
> > > > generation (e.g., that is must be from a good quality random number
> > > > generator).
> > > >
> > > > — Unauthenticated encryption is generally seen as risky, so when
> > > > encryption is included the the authDigest should also be used as
> > > > it is in the other modes. Figure 2 should have both authDigest AND
> > > > IV fields.
> > > >
> > > > Section 4.2.5. This section mentions that DTLS is not useful because
> > > > “The replay protection would remove duplicated packets and prevent
> > > > transparent measurement of this impairment.”. IPsec will also
> > > > transparently remove duplicate packets, and since TLS is based on
> > > > TCP, which has duplicate segment protection, I would expect that
> > > > the application would also never see duplicate measurement PDUs
> > > > from TLS either. This is generally seen as a feature for network
> > > > encryption methods.
> > > >
> > > > Section 10. “Client-server authentication and integrity protection
> > > > for feedback messages conveying measurements is REQUIRED.” Since
> > > > one of the methods allows “unauthenticated mode for all messages”,
> > > > I think this is meant to start with “Support for client-server
> > > > authentication ….”. That is, the REQUIRED language means
> > > > it must be implemented, but not used.
> > > >
> > > > Nits
> > > >
> > > > — Section 4.2 says “There are four security modes of operation”,
> > > > which is also stated elsewhere, but there seems to actually be five.
> > > > I understand that the fifth one is actually an external security
> > > > mode that can be combined with one of the four modes (e.g.,
> > > > “unauthenticated mode for all messages”) in the PDU. It might be
> > > > clearer to take the fifth one out of the list and just make it a
> > > > paragraph.
> > > >
> > > > — Section 4.2.1 s/miss-match/mismatch/
> > > >
> > > >
> > > > _______________________________________________
> > > > ippm mailing list
> > > > [e-mail]
> > > >
> > >
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
> > > > T!lLiKK4svDahYLFenpa6d7FQa-qA1f4ltd7wjaRx1S-
> > > YZCr9cEveGl5UOAc3B7KuEPYEWE3uif4c$