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

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

Thanks very much, Brian.

Another quick question came-up:
Do we need to use different keys for the AUTH and Encrypt processes, or can we use the same long-lived key for both?

Al

> -----Original Message-----
> From: Brian Weis <[e-mail]>
> Sent: Thursday, May 25, 2023 12:26 AM
> To: MORTON JR., AL <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; CIAVATTONE, LEN <[e-mail]>
> Subject: Re: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-
> 04
> 
> Hi Al,
> 
> Many apologies for the late response. Yes, combining AES-CBC-128 ad SHA-256 is
> a reasonable solution. They are often used together, and are safe to use with
> long-lived keys. I notice that some of the PDUs defined in -04 (e.g., Figure
> 2) have a field defined as "authDigest[AUTH_DIGEST_LENGTH](256 bits)  or
> Initialization Vector (IV)”, but actually both fields are needed: an IV for
> AES-CBC-128, and the authDigest for SHA-256.
> 
> Hope that helps,
> Brian
> 
> > On May 19, 2023, at 8:44 AM, MORTON JR., AL <[e-mail]> wrote:
> >
> > 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$