Subject: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15

From: David Mandelberg <[email-masked]>
Date: Mon, 11 Oct 2021 22:12:10 -0400

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.

The summary of the review is Ready with nits.

(nit) Section 2.3 describes MACs as "based on cryptographic hash 
functions using a secret key". If the intent is to limit this to MACs 
that use cryptographic hash functions, I'd suggest using the term HMAC 
instead of MAC. If not, I think there are other MAC algorithms that 
don't use hashes.

(nit) The description of Chunk Length in Section 3.2 seems a bit 
complicated. (Not a lot complicated, just a bit.) I'd expect at least 
occasional security issues from incorrect implementations in programming 
languages that don't enforce in-bounds memory access. I'm guessing it's 
either too late to simplify the field, or there are good reasons for it 
to be the way it is? Are there any lessons learned by existing 
implementations that would be worth mentioning to help future 
implementors avoid issues with out-of-bounds memory access here? ("No" 
is a fine answer if this turns out to not have been a problem.)

(nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is longer 
than the lifespan carried in the State Cookie, then ... the endpoint 
MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the 
peer endpoint.' That's different from the behavior if the MAC fails in 
bullet point 2. Does that mean that endpoints are REQUIRED to keep track 
of every secret they've ever used, so that they can distinguish between 
failed MACs and expired cookies for very old cookies? Should that be 
relaxed a bit to let implementations only store moderately recent secrets?

(nit) Section 12.2.3 says "Regardless of where confidentiality is 
provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] 
SHOULD be used for key management." That makes sense for ESP, but is it 
intended to apply to DTLS too? (DTLS is mentioned earlier in the same 
section.)

P.S. This was a very long document, so I ended up just skimming a bunch 
of the parts that I guessed were less likely to be relevant to security. 
Let me know if there are any particular sections I should take a closer 
look at.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Oct 2021 20:30:29 -0700

Hi David,

Thanks for the review!

> instead of MAC. If not, I think there are other MAC algorithms that 

This is a very good point to raise about the precise definition of MACs,
though I think HMAC is not going to be quite right either even for the
hash-based case.

A MAC is inherently going to involve a secret key; otherwise it would just
be a checksum.  But HMAC is not the only game in town for hash-based MACs
(e.g., KMAC), and cipher-based MACs like CMAC are also defined.  I think we
will need the authors to help clarify whether the fully general MAC is the
appropriate definition or a more-specific subset is intended.

-Ben

---

From: David Mandelberg <[email-masked]>
Date: Mon, 11 Oct 2021 23:48:27 -0400

> appropriate definition or a more-specific subset is intended.

Oh good point. I didn't realize there were MAC algorithms other than 
HMAC that used hashes, but that makes sense.

Thinking about it more, does it even have to be a MAC? It's always 
verified by the same party than generated it, and it's opaque to 
everybody else, right? So MAC makes perfect sense today when MACs are 
generally much faster than asymmetric signatures (I think?), but 
couldn't it just as easily be an asymmetric signature if the only 
important property is that the party that generated it needs to be able 
to verify it? (I think it's fine to specify it as a MAC, I'm just 
curious if I correctly understood the properties it needs.)

---

From: [email-masked]
Date: Thu, 14 Oct 2021 16:46:27 +0200

> \On 12. Oct 2021, at 04:12, David Mandelberg <[email-masked]> wrote:
> 
Hi David,

thank you very much for your review. Please see my comments in-line.

Best regards
Michael
> (nit) Section 2.3 describes MACs as "based on cryptographic hash functions using a secret key". If the intent is to limit this to MACs that use cryptographic hash functions, I'd suggest using the term HMAC instead of MAC. If not, I think there are other MAC algorithms that don't use hashes.
I can change it to HMAC, if that is a better term. The description you are citing ends with:
SCTP uses this term with the same meaning as in [RFC2104].
The title of RFC 2104 is "HMAC: Keyed-Hashing for Message Authentication".
Just let me know.
> 
> (nit) The description of Chunk Length in Section 3.2 seems a bit complicated. (Not a lot complicated, just a bit.) I'd expect at least occasional security issues from incorrect implementations in programming languages that don't enforce in-bounds memory access. I'm guessing it's either too late to simplify the field, or there are good reasons for it to be the way it is? Are there any lessons learned by existing implementations that would be worth mentioning to help future implementors avoid issues with out-of-bounds memory access here? ("No" is a fine answer if this turns out to not have been a problem.)
In RFC 2960 was an issue how to handle the padding of the last parameter in a chunk. Should
it be considered the padding of the parameter (and therefore included in the length of the chunk)
or considered the padding of the chunk (and therefore not included in the length of the chunk).

This was addressed RFC 4960 by:
https://datatracker.ietf.org/doc/html/rfc4460#section-2.3

Besides of that I'm aware of (fixed) bugs in implementations, which were caused by not
checking the length field. However, the problem was that the check was not done, not that
it was not clear which values should be checked. So I guess this can not be improved here.

However, if you can suggest a wording which describes things better or in a clearer way,
I'm open to include that.
> 
> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is longer than the lifespan carried in the State Cookie, then ... the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.' That's different from the behavior if the MAC fails in bullet point 2. Does that mean that endpoints are REQUIRED to keep track of every secret they've ever used, so that they can distinguish between failed MACs and expired cookies for very old cookies? Should that be relaxed a bit to let implementations only store moderately recent secrets?
This is exactly how it is implemented in FreeBSD. There are two keys (the current and the one before).
If a COOKIE which is way too old, it would just be dropped. The current lifetime of a secret is 60 minutes,
and the maximum time you can report in the stale cookie is about 70 minutes.

So what about using:

<li><t>Compute a MAC using the information carried in the State Cookie and
the secret key.
The timestamp in the State Cookie MAY be used to determine which secret
key to use.
If secrets are kept only for a limited amount of time and the secret key to use
is not available anymore, the packet containing the COOKIE ECHO chunk MUST be
silently discarded.
> 
> (nit) Section 12.2.3 says "Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key management." That makes sense for ESP, but is it intended to apply to DTLS too? (DTLS is mentioned earlier in the same section.)
The reference to DTLS was added recently. You are right, the IKE reference should only apply to ESP.
I changed the text to read:
<t>Regardless of where confidentiality is provided, the Internet Key
Exchange Protocol version 2 (IKEv2) <xref target='RFC7296'/> SHOULD be used for
key management of ESP.</t>
> 
> P.S. This was a very long document, so I ended up just skimming a bunch of the parts that I guessed were less likely to be relevant to security. Let me know if there are any particular sections I should take a closer look at.

---

From: [email-masked]
Date: Thu, 14 Oct 2021 16:52:56 +0200

> On 12. Oct 2021, at 05:30, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi David,
> 
> Thanks for the review!
> 
Hi Benjamin,

the usecase is:

An endpoint has some information (the cookie) it sends to its peer. The peer
will send it back. The endpoint must be able to check that the peer did not
modify the cookie. There is no requirement on confidentiality.
In FreeBSD, we use am HMAC for it.

Best regards
Michael

---

From: David Mandelberg <[email-masked]>
Date: Thu, 14 Oct 2021 13:57:16 -0400

> The title of RFC 2104 is "HMAC: Keyed-Hashing for Message Authentication".

 From a security perspective, there are multiple good options for MAC 
algorithms to use here, including some HMAC algorithms. (I don't know 
enough about MAC algorithms to be too much more specific.)

 From a standards perspective, I think the doc should be clear about 
what the requirements actually are. This seems like an unusual case, 
because there are no interoperability concerns as far as I can tell. 
(Except maybe length? Are there constraints on the length of the field?) 
I don't know what the right thing to do here is, but I'd lean towards 1) 
documenting the requirements for interoperability, 2) documenting the 
requirements for security, and 3) providing an example algorithm that 
implementations should use unless they have a reason to pick something 
different. Do other people think that's a good way to go? Or should it 
be kept simpler and just recommend something specific?

If it helps, here's some draft text of what I'm thinking:

The State Cookie MUST include information (e.g., a MAC or digital 
signature) that the sender of the INIT ACK chunk can later use to 
cryptographically authenticate the State Cookie. It MUST NOT cause the 
size of the State Cookie to exceed X bytes in total, and it SHOULD 
provide at least Y bits of security. For example, the State Cookie's 
authenticity protection could use Z.

I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 
with some specific key length (256 bits?) but like I said above, I don't 
know enough about MAC algorithms to provide good guidance here.

None of that really solves the terminology problem though. "State 
Cookie's authenticity protection" is a bit verbose. Given the 
performance advantages of MACs over digital signatures, maybe use the 
term MAC throughout, with a note in one place that a digital signature 
could also be used if an implementation has a reason to?

> I'm open to include that.

Nope, feel free to keep it as is. And thanks for the background.
> is not available anymore, the packet containing the COOKIE ECHO chunk MUST be

Sounds good.

> key management of ESP.</t>

Sounds good.

---

From: [email-masked]
Date: Thu, 14 Oct 2021 21:31:23 +0200

> On 14. Oct 2021, at 19:57, David Mandelberg <[email-masked]> wrote:
> 
> From a security perspective, there are multiple good options for MAC algorithms to use here, including some HMAC algorithms. (I don't know enough about MAC algorithms to be too much more specific.)
> 
> From a standards perspective, I think the doc should be clear about what the requirements actually are. This seems like an unusual case, because there are no interoperability concerns as far as I can tell. (Except maybe length? Are there constraints on the length of the field?) I don't know what the right thing to do here is, but I'd lean towards 1) documenting the requirements for interoperability, 2) documenting the requirements for security, and 3) providing an example algorithm that implementations should use unless they have a reason to pick something different. Do other people think that's a good way to go? Or should it be kept simpler and just recommend something specific?
> 
You are suggesting to add this to section 5.1.3, I guess. So are you suggesting to remove the MAC entry from Section 2.3?
> 
> The State Cookie MUST include information (e.g., a MAC or digital signature) that the sender of the INIT ACK chunk can later use to cryptographically authenticate the State Cookie. It MUST NOT cause the size of the State Cookie to exceed X bytes in total, and it SHOULD provide at least Y bits of security. For example, the State Cookie's authenticity protection could use Z.
Well, we are not that specific about size, especially regarding Y. We only mention:

An implementation SHOULD make the cookie as small as possible to ensure interoperability.

This is basically about trying that the packet containing the INIT-ACK does not need to be fragmented
at the IP layer.

If you think, I can add a statement about the length of the key being used in the operation.
> 
> I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 with some specific key length (256 bits?) but like I said above, I don't know enough about MAC algorithms to provide good guidance here.
We actually left that open. Since you compute the cookie when responding to an INIT chunk, it is also
important that you don't spend too many cycles on generating it. How you balance the level of
protection against the cookie modification and protection against the CPU load during an INIT flood
depends on the system, the application, and is left open.

The cookie mechanism is used on the server side to avoid keeping state before the server
has validated that it communicates with the IP address it is thinking it communicates with.

So I'm not too concerned about this. But I follow any advice you are giving...
> 
> None of that really solves the terminology problem though. "State Cookie's authenticity protection" is a bit verbose. Given the performance advantages of MACs over digital signatures, maybe use the term MAC throughout, with a note in one place that a digital signature could also be used if an implementation has a reason to?
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Oct 2021 13:02:24 -0700

Admin note: is there a reason this review isn't in the datatracker?

On Thu, Oct 14, 2021 at 12:31 PM <[email-masked]> wrote:

> functions using a secret key". If the intent is to limit this to MACs that
> use cryptographic hash functions, I'd suggest using the term HMAC instead
> of MAC. If not, I think there are other MAC algorithms that don't use
> hashes.
> > From a standards perspective, I think the doc should be clear about what
> the requirements actually are. This seems like an unusual case, because
> there are no interoperability concerns as far as I can tell. (Except maybe
> length? Are there constraints on the length of the field?) I don't know
> what the right thing to do here is, but I'd lean towards 1) documenting the
> requirements for interoperability, 2) documenting the requirements for
> security, and 3) providing an example algorithm that implementations should
> use unless they have a reason to pick something different. Do other people
> think that's a good way to go? Or should it be kept simpler and just
> recommend something specific?
> >
> You are suggesting to add this to section 5.1.3, I guess. So are you
> suggesting to remove the MAC entry from Section 2.3?
> >
> cryptographically authenticate the State Cookie. It MUST NOT cause the size
> of the State Cookie to exceed X bytes in total, and it SHOULD provide at
> least Y bits of security. For example, the State Cookie's authenticity
> protection could use Z.
> Cookie's authenticity protection" is a bit verbose. Given the performance
> advantages of MACs over digital signatures, maybe use the term MAC
> throughout, with a note in one place that a digital signature could also be
> used if an implementation has a reason to?
> >
> either too late to simplify the field, or there are good reasons for it to
> be the way it is? Are there any lessons learned by existing implementations
> that would be worth mentioning to help future implementors avoid issues
> with out-of-bounds memory access here? ("No" is a fine answer if this turns
> out to not have been a problem.)
> >>> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is
> longer than the lifespan carried in the State Cookie, then ... the endpoint
> MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer
> endpoint.' That's different from the behavior if the MAC fails in bullet
> point 2. Does that mean that endpoints are REQUIRED to keep track of every
> secret they've ever used, so that they can distinguish between failed MACs
> and expired cookies for very old cookies? Should that be relaxed a bit to
> let implementations only store moderately recent secrets?
> >>> P.S. This was a very long document, so I ended up just skimming a
> bunch of the parts that I guessed were less likely to be relevant to
> security. Let me know if there are any particular sections I should take a
> closer look at.
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 14 Oct 2021 13:05:22 -0700

> Admin note: is there a reason this review isn't in the datatracker?

I assume the original review was manually sent as an email.
I think that Tero will notice it and update the datatracker review entry in
the next day or so when he updates the assignments.

-Ben

---

From: David Mandelberg <[email-masked]>
Date: Thu, 14 Oct 2021 16:37:09 -0400

> I assume the original review was manually sent as an email.

Yup. Should I start using the datatracker at some point?

---

From: David Mandelberg <[email-masked]>
Date: Thu, 14 Oct 2021 16:55:09 -0400

> You are suggesting to add this to section 5.1.3, I guess. So are you suggesting to remove the MAC entry from Section 2.3?

Yes, if you think that makes sense.

> An implementation SHOULD make the cookie as small as possible to ensure interoperability.

Oops, I missed that. No need to add more about the State Cookie size 
then, as far as I'm concerned.

> If you think, I can add a statement about the length of the key being used in the operation.

I think telling people to use cryptography without giving any guidance 
about what algorithms or parameters to use could potentially lead to 
implementations accidentally picking insecure options. So I think it 
would be nice to see some guidance there, even if it's non-normative.

> depends on the system, the application, and is left open.

Oh that's a good point. Was that in the doc and I missed it? If not, it 
might be nice to mention as guidance for implementors on how to pick the 
right algorithm and parameters. Though I'd probably still lean towards 
also including a reasonable example, for implementors to use by default 
if they're unsure of what to pick.

> So I'm not too concerned about this. But I follow any advice you are giving...

I'm not too concerned about it either :) I think some clarification and 
an example (as discussed above) would be good, but I don't feel strongly 
about any of the specifics. (Just maybe don't recommend HMAC-MD5 
truncated to 32 bits.)

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Oct 2021 19:20:51 +0300

> Admin note: is there a reason this review isn't in the datatracker?

It was sent directly to list, meaning the reviewer did not use the
datatracker to complete the review request. This means that secdir
secretary (me) needs to manually close the review request, and provide
link to the review.

I normally do that every Thursday when I do new round of review
requests, but last week there was M3AAWG meeting and other things
going on so I didn't have time to do secdir reviews until today.

Now the link should be in the datatracker.

Unfortunately there were too many responses in the email thread and
the datatracker only shows me last 10 messages with that subject, so I
could not pick the actual review email in the datatracker form. This
meant that I needed to manually find the review link from the list,
and fill that in to the datatracker, and it case the datatracker does
not fetch the email text from the url, thus the email text is not is
not included in the datatracker. This means you need to click on the
link of the review text to be able to see the actual email.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Oct 2021 20:02:16 +0300

> would be nice to see some guidance there, even if it's non-normative.

I first assumed this cookie is similar than what for example IKEv2
uses, i.e. generated and verified by one and reflected by the other
end to verify that the other end did see the previous message.

When I checked the draft I noticed it is not at all similar than what
is used by IKEv2 or Photuris, because the Cookie contains both the
"minimal subset of information" and the MAC.

To see how IKEv2 specifies this see section 2.6 of RFC7296 and the
description about the COOKIE notification, but here is relevant text
from there (note this example uses just simple hash with secret, which
is not that safe as a MAC, but should be enough for this kind of
purposes what IKEv2 does):

----------------------------------------------------------------------
2.6.  IKE SA SPIs and Cookies
...
   An IKE implementation can implement its responder cookie generation
   in such a way as to not require any saved state to recognize its
   valid cookie when the second IKE_SA_INIT message arrives.  The exact
   algorithms and syntax used to generate cookies do not affect
   interoperability and hence are not specified here.  The following is
   an example of how an endpoint could use cookies to implement limited
   DoS protection.

   A good way to do this is to set the responder cookie to be:

   Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

   where <secret> is a randomly generated secret known only to the
   responder and periodically changed and | indicates concatenation.
   <VersionIDofSecret> should be changed whenever <secret> is
   regenerated.  The cookie can be recomputed when the IKE_SA_INIT
   arrives the second time and compared to the cookie in the received
   message.  If it matches, the responder knows that the cookie was
   generated since the last change to <secret> and that IPi must be the
   same as the source address it saw the first time.  Incorporating SPIi
   into the calculation ensures that if multiple IKE SAs are being set
   up in parallel they will all get different cookies (assuming the
   initiator chooses unique SPIi's).  Incorporating Ni in the hash
   ensures that an attacker who sees only message 2 can't successfully
   forge a message 3.  Also, incorporating SPIi in the hash prevents an
   attacker from fetching one cookie from the other end, and then
   initiating many IKE_SA_INIT exchanges all with different initiator
   SPIs (and perhaps port numbers) so that the responder thinks that
   there are a lot of machines behind one NAT box that are all trying to
   connect.

   If a new value for <secret> is chosen while there are connections in
   the process of being initialized, an IKE_SA_INIT might be returned
   with other than the current <VersionIDofSecret>.  The responder in
   that case MAY reject the message by sending another response with a
   new cookie or it MAY keep the old value of <secret> around for a
   short time and accept cookies computed from either one.  The
   responder should not accept cookies indefinitely after <secret> is
   changed, since that would defeat part of the DoS protection.  The
   responder should change the value of <secret> frequently, especially
   if under attack.

   When one party receives an IKE_SA_INIT request containing a cookie
   whose contents do not match the value expected, that party MUST
   ignore the cookie and process the message as if no cookie had been
   included; usually this means sending a response containing a new
   cookie.  The initiator should limit the number of cookie exchanges it
   tries before giving up, possibly using exponential back-off.  An
   attacker can forge multiple cookie responses to the initiator's
   IKE_SA_INIT message, and each of those forged cookie replies will
   cause two packets to be sent: one packet from the initiator to the
   responder (which will reject those cookies), and one response from
   responder to initiator that includes the correct cookie.

   A note on terminology: the term "cookies" originates with Karn and
   Simpson [PHOTURIS] in Photuris, an early proposal for key management
   with IPsec, and it has persisted.  The Internet Security Association
   and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header
   includes two eight-octet fields called "cookies", and that syntax is
   used by both IKEv1 and IKEv2, although in IKEv2 they are referred to
   as the "IKE SPI" and there is a new separate field in a Notify
   payload holding the cookie.
----------------------------------------------------------------------

As in this draft cookie is not only a cookie, as it also needs to
include the data needed to reconstruct the state this puts much more
emphasis on the properties of the MAC.

In IKEv2 cookie is simply a MAC of things that is already somewhere
else in the incoming packet (which are cryptographically proteced
later anyways). I.e., the cookie is just used to verify that initiator
has already done one round trip to the server before we create state
based on the data that is in the first packet.

Now as the cookie here contains more than just MAC part, it makes
cookie to have more security issues. Now the cookie needs to have more
of internal structure and recipient needs to parse it properly. This
also means that if attacker is able to modify the cookie in such way
that it still passes the checks it might be able to mount more serious
attacks. In IKEv2 case that is not possible, as cookie is just HASH of
data elsewhere on the packet, thus there is no structure to mess up.
I.e., in IKEv2 it would be possible to use very short MAC, as even
with one octet MAC that will limit the resource consumption to 1/256th
of the non cookie case, but one octet MAC is not going to be good
enough to protect the subset of information needed to re-create the
TCB. 

In addition to that your cookie generation might even leak out some
internal data from the server if implemnetor really creates a TCB and
then includes too much data from the TCB to cookie (i.e., if someone
just created TCB, didn't bother to create minimal subset of
information, but simply decided that TCB is small enough that it can
be used as such, and then TCB might include some pointers to other
structures that are internal to the kernel).

Because of this I do recommend using the proper cryptographic message
authentication code (MAC) and not a thing that IKEv2 and Photurus
used, i.e. simple hash with secret at the end (which would most likely
still be safe for this use, but proper MAC is better). Also you do
want to say something that the MAC part of that cookie, needs to have
certain length to protect against forgery attempts, you are not using
cookie to just protect against denial of service.
-- 
[email-masked]

---

From: [email-masked]
Date: Sun, 24 Oct 2021 00:46:33 +0200

> On 14. Oct 2021, at 22:55, David Mandelberg <[email-masked]> wrote:
> 
OK, removed the text from Section 2.3.

I updated the text in Section 5.1.3 such that the new paragraph reads:

<t>The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk.
The use of a MAC is mandatory to prevent denial-of-service attacks.
There is a tradeoff between to computational complexity and the level of
security the MAC provides.
Using the HMAC-SHA1 might be an acceptable compromise.
The secret key SHOULD be random (<xref target='RFC4086'/> provides some
information on randomness guidelines).
The secret keys need to have an appropriate size.
When using HMAC-SHA1, secret keys of at least 160 bits are appropriate according
to <xref target='RFC2104'/>.
The secret key SHOULD be changed reasonably frequently, and the timestamp in the
State Cookie MAY be used to determine which key is used to verify the MAC.</t>

I use HMAC-SHA1 since this seems to be what is used in the FreeBSD and Linux implementations.
> Oops, I missed that. No need to add more about the State Cookie size then, as far as I'm concerned.
> 
> I think telling people to use cryptography without giving any guidance about what algorithms or parameters to use could potentially lead to implementations accidentally picking insecure options. So I think it would be nice to see some guidance there, even if it's non-normative.
Done in the above text. Referring to HMAC-SHA1 in non-normative way.
>>> I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 with some specific key length (256 bits?) but like I said above, I don't know enough about MAC algorithms to provide good guid…
Since I'm using HMAC-SHA1, I'm using a length of at least 160 bits.
> Oh that's a good point. Was that in the doc and I missed it? If not, it might be nice to mention as guidance for implementors on how to pick the right algorithm and parameters. Though I'd probably still lean towards also including a reasonable example, for implementors to use by default if they're unsure of what to pick.
I mention it in the above cited text.
> I'm not too concerned about it either :) I think some clarification and an example (as discussed above) would be good, but I don't feel strongly about any of the specifics. (Just maybe don't recommend HMAC-MD5 truncated to 32 bits.)
The text above talks about using HMAC-SHA1 and the text says to put the MAC in the cookie. So
no truncation. 

Best regards
Michael

---

From: [email-masked]
Date: Sun, 24 Oct 2021 20:55:50 +0200

> On 18. Oct 2021, at 19:02, Tero Kivinen <[email-masked]> wrote:
> 
> David Mandelberg writes:
In the FreeBSD implementation, we put the INIT and INIT ACK chunk
in the cookie. And when parsing this information, we do it the same way
as parsing any inout from the network.
> structures that are internal to the kernel).
The specification does not require the cookie to be encrypted. So the
sender should not put any information in the cookie that can't be shared.
In the FreeBSD case, most of the information was already on the wire...
> cookie to just protect against denial of service.
The text I added to address Davids issue, refers to HMAC-SHA1.
Is that acceptable?

Best regards
Michael

---

From: David Mandelberg <[email-masked]>
Date: Tue, 26 Oct 2021 14:35:47 -0400

> <t>The hashing method used to generate the MAC is strictly a private

How about just "The method ..." in case people want to use 
non-hash-based MAC algorithms?

> The secret key SHOULD be changed reasonably frequently, and the timestamp in the

What is "reasonably frequently"? Maybe add "(e.g., daily)" or some other 
example frequency?

> I use HMAC-SHA1 since this seems to be what is used in the FreeBSD and Linux implementations.

 From a DoS perspective, that seems fine to me, but I'd like to hear 
Tero's response too about if this needs to do more than just protect 
against DoS.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 29 Oct 2021 03:46:04 +0300

> as parsing any inout from the network.

Adding that kind of implementation guidance would be good idea for the
draft too, but on the other hand that does not really follow the
suggestion of using minimal subset of data, or is it really true that
INIT and INIT ACK do not have any unneeded information in them? Do you
include the IP addresses etc where the frame came, i.e. do you use
whole IP packet or only the inner payload? One of the attacks against
this is to generate lots of valid cookies from thousands of IP
addresses than then resend them with faked source address to cause
denial service attack on that one address. If the cookie does not have
IP addresses in it then this attack is possible. 

> In the FreeBSD case, most of the information was already on the wire...

But the draft does not suggest the method used by FreeBSD, but instead
suggest creating TCB and taking minimal subset of it. TCB might have
some private data in it, so perhaps adding some comment about that
too.

I.e., say that as the cookie is not encrypted care must be taken when
constructing cookie, so that the cookie does not leak out any
information that should not be leaked.

> The text I added to address Davids issue, refers to HMAC-SHA1.

Altough HMAC-SHA1 is still acceptable, there is common confusion where
people confuse the fact that plain SHA1 is being deprecated, and
assume that also means HMAC-SHA1. In some cases libraries have been
removing support for code for deprecated algorithms and then suddenly
there might be case that you can't use HMAC-SHA1 anymore as SHA1
algorithm got removed.

Anyways as this is internal matter to the implementation I do not
think we need to recommend any specific algorithm, we could simply say
any MAC with acceptable security properties is fine, and if we really
want to suggest something suggesting HMAC-SHA256 or similar might be
better.

Anyways as there is no data that needs to be properly authenticated
(and parsed with care) plain hash + secret should not be used (like is
used in Photurus and IKEv2), and proper MAC is needed.
-- 
[email-masked]

---

From: [email-masked]
Date: Fri, 29 Oct 2021 11:15:34 +0200

> On 26. Oct 2021, at 20:35, David Mandelberg <[email-masked]> wrote:
> 
> How about just "The method ..." in case people want to use non-hash-based MAC algorithms?
Sure. Text changed.
> What is "reasonably frequently"? Maybe add "(e.g., daily)" or some other example frequency?
In FreeBSD this can be controlled by a sysctl variable and the default is 1 hour.
But I'm adding the text you suggest.
> From a DoS perspective, that seems fine to me, but I'd like to hear Tero's response too about if this needs to do more than just protect against DoS.
OK.

Thanks for your comments!

Best regards
Michael

---

From: [email-masked]
Date: Sun, 31 Oct 2021 22:13:25 +0100

> On 29. Oct 2021, at 02:46, Tero Kivinen <[email-masked]> wrote:
> 
I just wanted to provide information how this can be implemented. I don't
want to require any implementation to do it that way.
I think you need to have all the information for the INIT and INIT-ACK
chunk available. So you could only try to use a more compact representation.
But this comes with other drawbacks. So this is also a compromise...
> whole IP packet or only the inner payload? One of the attacks against
FreeBSD uses the INIT and INIT ACK (without the cookie) in addition
to some other information, which includes the source and destination
address of the packet containing the INIT chunk.

In general, the cookie needs to contain the address lists contained in
the INIT and INIT ACK chunks and the corresponding source addresses of
the packets containing the INIT chunk and the INIT ACK chunk, since
these addresses are the ones that will be used by the association.
> IP addresses in it then this attack is possible. 
So if the source address of the packet containing the COOKIE ECHO chunk
is not one of the addresses reported earlier in the INIT chunk or used
as the source address of the packet containing the INIT chunk, it won't
be used.

Please note that the attacker can send packets containing the COOKIE
ECHO chunk from spoofed addresses, but the attacker can also include
these addresses in the INIT chunk.
So the only address the receiver of the COOKIE ECHO chunk considers
confirmed is the address the INIT ACK was sent to.
> some private data in it, so perhaps adding some comment about that
The text has changed. It doesn't mention the TCB anymore in this subsection.

It reads:

Inside this State Cookie, the sender SHOULD include a MAC (see [RFC2104]
for an example), a timestamp on when the State Cookie is created, and the
lifespan of the State Cookie, along with all the information necessary for
it to establish the association including the port numbers and the
verification tags.
> information that should not be leaked.
Sure. What about adding the following sentence:

Since the State Cookie is not encrypted, it MUST NOT contain information
which is not being envisioned to be shared.
> want to suggest something suggesting HMAC-SHA256 or similar might be
OK. So I remove (the recently added) sentence:

and replace it by

A MAC with acceptable security properties SHOULD be used.

Then it makes sense to also remove (the recently added) sentence:

Should I also change back "reasonably frequently (e.g., daily)" to "reasonably frequently"
when describing that the secret should be changed?