Subject: [babel] Comments on the MAC authentication for Babel draft

From: Antonin Décimo <[email-masked]>
Date: Wed, 26 Aug 2020 11:51:13 +0200

Hello all,

I have some comments on the MAC authentication for Babel draft.
The first three date from 2020-12-28, the others are new.

1. Key length

This is the change I'm proposing in §7:

 Keys must be chosen in a manner that makes them difficult to guess.
-Ideally, they should have a length of 32 octets (both for HMAC-SHA256
-and Blake2s), and be chosen randomly.
+Ideally, they should be chosen randomly, and have the maximum key
+length supported by the MAC algorithm (32 octets for keyed BLAKE2S)
+or no less than the block size of the MAC algorithm (64 octets for
+HMAC-SHA256).

2. Digest length

Reading the length of the MAC TLV in order to compute a MAC of this
length is not compliant with the protocol (§4.3) since MACs are
computed without looking into the packet.

> Then, for each key configured on the receiving interface, the
> receiver computes the MAC of the packet. It then compares every
> generated MAC against every MAC included in the packet;

Still, it was an error I was almost going to make. I propose the
following change to ensure that we're always using the maximum digest
length of the MAC algorithm.

This is the change I'm proposing in §4.1:

 implementation MUST implement HMAC-SHA256 as defined in
 <xref target="RFC6234"/> and Section 2 of <xref target="RFC2104"/>,
 SHOULD implement keyed BLAKE2s <xref target="RFC7693"/>, and MAY implement
 other MAC algorithms.
+The length of the MAC MUST be the maximum MAC length computable by
+the MAC algorithm (32 octets for both HMAC-SHA256 and keyed
+BLAKE2S).

3. Lazy computation

With the idea that computing a MAC is more costly than comparing MACs,
and that there's a very limited amount of MACs to check, I propose we
lazily compute MACs. Instead of computing the MAC for every key on
packet reception, we compute the MAC with the first key, then check it
against the MACs carried by the packet. If there's a match, the packet
is immediately accepted. If there's no match, we the proceed to the
next key until all keys are exhausted, and the packet is rejected.

This is the change I'm proposing in §4.3:

-Then, for each key configured on the receiving interface, the
-receiver computes the MAC of the packet.  It then compares every
-generated MAC against every MAC included in the packet; if there is
-at least one match, the packet passes the MAC test; if there is none,
-the packet MUST be silently dropped and processing stops at this
-point.
+Then, for each key configured on the receiving interface, the
+receiver computes the MAC of the packet and compares it against every
+MAC included in the packet; if there is at least one match, the
+packet passes the MAC test; if there is none, the receiver proceeds
+with the next key.  If none of the MAC matched, the packet MUST be
+silently dropped and processing stops at this point.

4. Accepting Challenges

When receiving a challenge reply, a node must check if there was a
challenge in progress before validating the challenge.

§ 3.2 Neighbour table
> The Nonce and expiry timer are initially undefined

§ 4.3.1.3. Receiving challenge replies
> If no challenge is in progress, i.e., if there is no Nonce stored in
> the Neighbour Table entry or the Challenge timer has expired, the
> Challenge Reply MUST be silently ignored and the challenge has
> failed.

However the text does not explicitly describe if there are changes
to be made to the overall state when the challenge succeeds.

> Otherwise, the node compares the Nonce contained in the Challenge
> Reply with the Nonce contained in the Neighbour Table entry. If the
> two are equal (they have the same length and content), then the
> challenge has succeeded; otherwise, the challenge has failed.

As it is not possible to have a running or expired timer and an
uninitialised Nonce field, I think that the timer should be
initialised in the "expired" state. The "challenge is in progress"
test can be simplified to "is the timer expired?", and then if the
challenge succeeds, the timer should be set into the "expired" state,
so that duplicated or incorrect challenge replies are rejected.

5. Replying to challenges

Section 4.3.1.2. Replying to challenges, the sentence

> A challenge sent to a multicast address MUST be silently ignored.

could be moved earlier, as it describes a case where the challenge
request should be ignored, but it is after the text indicating how to
construct and send a challenge reply.

6. Timers

I was confused at first between the "challenge expiry timer", the two
rate limits, and the neighbour state expiry timer. I suggest, for
consistency, the following changes:

section 3.2:
- The Nonce and expiry timer are initially undefined
+ The Nonce and challenge expiry timer are initially undefined

section 4.3.1.3
- the Challenge timer has expired
+ the challenge timer has expired

7. TLV names shouldn't be pluralised

Section 4.3
- ignored except PC TLVs, Challenge Requests and Challenge Replies.
+ ignored except PC, Challenge Request, and Challenge Reply TLVs.

- 4.3.1.  Challenge Requests and Replies
+ 4.3.1.  Challenge requests and replies

8. Consistency

Section 6.2
replace "4 octet" with "4-octet" (single dash)

Section 7
- nonces included in challenge requests and responses can
+ nonces included in challenge requests and replies can

9. Relations with the Information Model

The MAC draft defines (amongst other) three optionaly tunable parameters:
- the rate limit for sending Challenge Replies;
- the rate limit for sending Challenge Requests;
- various strategies for expiring neighbour state, with their own
  tunable parameters.
Should they be reflected in the models?

All the best,

-- Antonin

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Aug 2020 12:26:05 +0200

Dear Antonin,

While many of these are good changes, Donald is telling me that at this
stage we're not making any changes that are not actual bug fixes.  (He's
been telling me that for the best part of a year now, sigh.)

Antonin -- what we're dealing with here is a hostile bureaucratic
organisation (similar to our University's administration), so we must
choose our battles.  I don't think any of the battles below are worth
fighting.

> 1. Key length

I disagree.  Using 64 octets for SHA-256 gives no additional security.

  https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256

> computed without looking into the packet.

No.  The digest length is part of the algorithm.  The algorithm is carried
out-of-band.

In other words -- when a key is configured in a router, it is configured
together with the associated algorithm.  The algorithm implies a digest
length.  For example, SHA-256 truncated to 128 bits is a different
algorithm than SHA-256 with full digests.

I agree that this could be made clearer, but we're not tweaking this at
this stage.

> 3. Lazy computation

This is already legal — your proposed tweak doesn't violate any of the
MUST in this paragraph.  I agree that your wording is better, but we're
not making this change at this stage.

> to be made to the overall state when the challenge succeeds.

Right.  The obvious implementation strategy is to discard the challenge
state after a challenge has succeded.  Not doing that does not cause any
security issues (it's not required by the proof of correctness).

I think we should add « SHOULD discard the state » here, but it requires
Donald's permission.

> consistency, the following changes:

Right.  Unfortunately, we're no longer allowed to improve the wording.

> Section 4.3.1.2. Replying to challenges, the sentence [...] could be moved
> earlier

Right again.  Not worth fighting for, IMHO.

> 7. TLV names shouldn't be pluralised

Same.

> The MAC draft defines (amongst other) three optionaly tunable parameters:
[...]
> Should they be reflected in the models?

No.  The protocol is robust enough that the exact values are irrelevant to
its security.

-- Juliusz

---

From: Antonin Décimo <[email-masked]>
Date: Wed, 26 Aug 2020 13:52:24 +0200

> https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256

Ok, thanks.

> > 2. Digest length
> when a key is configured in a router, it is configured together with
> the associated algorithm. The algorithm implies a digest length.

Ah, I see. This is just what I had missed.

Thanks for reviewing my comments. I don’t see any bugs left in the
draft. I’m sorry to see that it’s too late for clarifications.

-- Antonin

---

From: David Schinazi <[email-masked]>
Date: Wed, 26 Aug 2020 11:08:46 -0700

To be slightly pedantic about the IETF process here
(chairs, please correct me if I'm wrong), it's not too late
to make editorial changes to the document. It is too
late to make big technical changes, as that would require
the relevant ADs to re-review the document, but as authors
you can feel free to clarify the wording. Another option is that
you'll be able to also change wording during AUTH48 (one
of the very last steps of the process where the authors go
back and forth with the RFC Editor to get all the editorial
details right). All that will be required is for the responsible
AD (in this case Martin Vigoureux) to review the AUTH48
changes and confirm that they are editorial. I would suggest
making small editorial changes now right before we send
this off to the RFC Editor.

David

On Wed, Aug 26, 2020 at 5:22 AM Antonin Décimo <[email-masked]>
wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Aug 2020 18:00:38 -0400

Hi David,

On Wed, Aug 26, 2020 at 2:09 PM David Schinazi <[email-masked]> wrote:
> you can feel free to clarify the wording.

It's just a little complicated to cover all the paths a draft can take
but at this point the draft has been through AD review, IETF Last
Call, Directorate Reviews, and IESG balloting. If significant
technical changes/extensions are made at this stage, it might require
sending the draft back to the WG to go through that process again.
However, the draft can simply be cloned under a new file name (like
draft-ietf-babel-hmacbis-00 or the like) and the changes made there.

Of course, if there is a fatal technical flaw, it is probably the
right thing to pull the draft back and have it go through the process
again. If it is a bad enough problem, it can even be pulled back from
the RFC Editor's queue or at any point until it is actually released
as an RFC. (After that, you have to do a new RFC to obsolete it.)

> Another option is that

We can make small editorial/clarification changes at this point.

After the RFC Editor gets it, you don't have to wait for AUTH48. The
RFC Editor will send out editorial questions and suggestions to the
authors along with a request that they review the document and
editorial fixes can be resolved then.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

> David
>
> On Wed, Aug 26, 2020 at 5:22 AM Antonin Décimo <[email-masked]> wrote:
>>
>> > > 1. Key length
>> >

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Aug 2020 18:01:14 -0400

Hi Antonin and Juliusz,

I'll just reply where I think I can add to Juliusz responses.

On Wed, Aug 26, 2020 at 6:26 AM Juliusz Chroboczek <[email-masked]> wrote:
> ...
> I agree that this could be made clearer, but we're not tweaking this at

I am opposed to the blanket requirement suggested by Antonin as follows:

Some MAC algorithms may produce very long MACs whose non-truncated use
would squeeze out too much useful data. This is a factor in the engineering
tradeoff that is being ignored in this suggested change. Truncated MACs are
quite common in IETF protocols, although there is usually a floor size
below which you are not permitted to go. And there are even arguments that
a modest amount of truncation can strengthen a MAC. (Also, from a different
point of view, the proposed requirement is trivially evaded because you
could just define a new MAC algorithm with the truncation or other
condensation of the MAC value from another MAC algorithm and say that this
new MAC algorithm is what you are using.)

> state after a challenge has succeeded.  Not doing that does not cause any

I think adding this "SHOULD" would be too much of a change. In principle it
doesn't require my permission, it requires Martin Vigoureux's permission
since the draft is out of the WG and in the IESG.

Since it doesn't affect correct operation, I would suggest just creating a
draft-ietf-babel-hmacbis-00 draft and putting it in that. There seems to be
enough WG interest in this that I don't see any need for a formal WG
adoption call.

6. Timers

> Right.  Unfortunately, we're no longer allowed to improve the wording.

I don't see any problem with typo fixes and clarifications so the changes
in point 6 seem fine to me.

> > 7. TLV names shouldn't be pluralised

I think the changes in Section 7 would be OK also.

> No.  The protocol is robust enough that the exact values are irrelevant to

Prior to writing this message, I reviewed the entire Babel hmac draft and
noticed the following: In Section 4.1, the empty box in the IPv4
psuedo-header diagram bothers me. I think it should say the following in
that box:

Dest address (cont.)

for destination address continued.

But I'm not sure it is worth fixing these editorial things right now. When
the draft is actually processed by the RFC Editor, all the authors will get
a message including what editorial problems or ambiguities the RFC Editor
thinks they have found along with a request to review the entire draft. At
that point any editorial things can be cleared up.

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2020 14:58:42 +0200

> doesn't require my permission, it requires Martin Vigoureux's permission since
> the draft is out of the WG and in the IESG.

Shall I ask Martin?

> draft-ietf-babel-hmacbis-00 draft and putting it in that.

I'm not volunteering.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 Aug 2020 16:41:17 -0400

Hi Juliusz,

> > the draft is out of the WG and in the IESG.

You are welcome to do so if you want.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]