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

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

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$