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

[Brian Weis <[e-mail]>]

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$