Comments on draft-ietf-bfd-secure-sequence-numbers-10

[Jeffrey Haas <[e-mail]>]

Authors,

Thank you for the substantive update on this draft.  I think we're most of
the way there!

Aside from my questions about the auth seq number space being shared between the
different modes (ISAAC vs. strong), my comments are largely editorial.

Comments below in the idnits numbered document:


112	3.  Meticulous Keyed ISAAC
[...]

150	   Sequence Number

152	      The sequence number for this packet.  For Meticulous Keyed ISAAC
153	      Authentication, this value is incremented for each successive
154	      packet transmitted for a session.  This provides protection
155	      against replay attacks.

I believe this sequence number is effectively per-seed.  Perhaps say something
about that here?

180	   While the rest of the contents of the BFD packet are unauthenticated
181	   and may be modified by an attacker, the same is true of stronger Auth
182	   Types, such as MD5 or SHA1.  The Auth Type methods are not designed
183	   to prevent such attacks.  Instead, they are designed to prevent an
184	   attacker from spoofing identities, and an attacker from artificially
185	   keeping a session "Up".

This detail is incorrect for the MD5/SHA1 mechanisms.  They are computed over
the entire BFD Control packet.  (RFC 5880, §6.7.3)  

It's reasonable to call out that the BFD Control packet containing the
Meticulous Keyed ISAAC authentication mechanism that no authentication is done
over the packet.  This is no different than the Simple Password mechanism in
terms of authentication over the packet, but clearly significantly better in
terms of detection of modification due to the randomness of the authkey.

187	4.  Operation

[...]

201	   Note that since the packets are not signed with this authentication
202	   type, the Meticulous Keyed ISAAC method MUST NOT be used to signal
203	   BFD state changes.  For BFD state changes, and a more optimized way
204	   to authenticate packets, please refer to BFD Authentication
205	   [I-D.ietf-bfd-optimizing-authentication].  Instead, the packets
206	   containing Meticulous Keyed ISAAC are only a signal that the sending
207	   party is still alive, and that the sending party is authentic.  That
208	   is, these Auth Type methods must only be used when
209	   bfd.SessionState=Up, and the State (Sta) field equals 3 (Up).

A detail that needs to be clarified in the interactions between these two drafts
is keeping track of Sequence Numbers between the competing mechanisms.

If it is the case that the Sequence Number is intended to be a single continuous
space used by both the Meticulous Keyed ISAAC and the stronger authentication
while performing state changes, I think we know how this should work.

Mostly what is needed is mention of this use of the same sequence numbers.
Review of the optimizing authentication procedures for this integration is also
probably wise.

211	4.1.  Seeding and Operation of ISAAC
[...]

216	   The origin of the Seed field is discussed later in this document.
217	   For now, we note that each time a new Seed is used, the
218	   bfd.XmitAuthSeq value MUST be set to zero.  The Seed MUST be changed
219	   when a BFD session transitions into the "Up" state.  In order to
220	   prevent continuous rekeying, the Seed MUST NOT be changed while a
221	   session is in the "Up" state.

Here is where the sequence numbers would need to be coordinated.

Since Meticulous Keyed ISAAC is only expected to be done in the Up state after
the optimized procedures, the sequence number should be non-zero.  I think the
primary consequence is that when ISAAC procedures kick in for a particular seed,
it could be necessary to generate some number of next-pages to permit index into
the space.

Clearly the mechanism won't work great if so great a time passes that the
sequence numbers have turned through multiple pages.  This isn't the expected or
desired behavior since optimizing authentication procedures are there solely for
securing state changes.  However, those consequences should likely be mentioned.

248	   The Sequence Number can increment without bounds, though it can wrap
249	   once it reaches the limit of the 32-bit counter field.  ISAAC has a
250	   cycle length of 2^8287, so there is no issue with using more than
251	   2^32 values from it.

For the case where the sequence number wraps, what's the expected ISAAC
behavior?  Should it to be to regenerate the page for the supplied credentials
back at sequence number zero?  (I expect the usual security AD commentary about
this opening things up to replay attacks, but also expect to point them to the
usual 2^32 is a Very Big Number point.)

The comment below suggests this is a reset.

253	   The result of the above operation is an infinite series of numbers
254	   which are unguessable, and which can be used to authenticate the
255	   sending party.

Depending on the answer to the prior point, you may want to delete this line.

263	4.2.  Secret Key

265	   For interoperability, the management interface by which the key is
266	   configured MUST accept ASCII strings, and SHOULD also allow for the
267	   configuration of any arbitrary binary string in hexadecimal form.
268	   Other configuration methods MAY be supported.

I suggest a forward reference here to the "re-use of keys" section.


283	4.3.  Seeding ISAAC

[...]

334	   Note that this construct requires that the "Your Discriminator" field
335	   not change during a session.  However, it does allow the "My
336	   Discriminator" field to change as permitted by RFC5880 Section 6.3
337	   [RFC5880]

Your Discriminator is only known after the systems start talking to each other,
and thus go to Up.  Mostly mentioned as another point towards the auth seq#
being non-zero for the strong mode.

350	5.  Meticulous Keyed ISAAC Authentication

[...]

366	   Transmission Using Meticulous Keyed ISAAC Authentication

373	      The Seed field MUST be set to the value of the current seed used
374	      for this sequence.

Discussion point for authors: Should we this a state variable name?
bfd.LocalIsaacSeed, e.g.

380	      For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on
381	      each packet, in a circular fashion (when treated as an unsigned
382	      32-bit value).  The bfd.XmitAuthSeq MUST NOT be incremented by
383	      more than one for a packet.

The point above suggests a page reset to 0 when we wrap.

385	   Receipt using Meticulous Keyed ISAAC Authentication

398	      If the Seed field does not match the current Seed value, the
399	      packet MUST be discarded.

See prior question about state variable name.

437	7.  Security Considerations

478	7.1.  Spoofing

480	   When Meticulous Keyed ISAAC is used, it is possible for an attacker
481	   who can see the packets to observe a particular Auth Key value, and
482	   then copy it to a different packet as a "man-in-the-middle" attack.
483	   However, the usefulness of such an attack is limited by the
484	   requirements that these packets must not signal state changes in the
485	   BFD session, and that the Auth Key changes on every packet.

487	   Performing such an attack would require an attacker to have the
488	   following information and capabilities:

490	      This is man-in-the-middle active attack.

492	      The attacker has the contents of a stable packet

494	      The attacker has managed to deduce the ISAAC key and knows which
495	      per-packet key is being used.

497	   The attack is therefore limited to keeping the BFD session up when it
498	   would otherwise drop.

500	   However, the usual actual attack which we are protecting BFD from is
501	   availability.  That is, the attacker is trying to shut down then
502	   connection when the attacked parties are trying to keep it up.  As a
503	   result, the attacks here seem to be irrelevant in practice.

I would like to congratulate the authors in creating the best summary of "some
attacks on BFD are silly".  It is quite likely the chairs will recommend a form
of this text as boilerplate in future BFD specifications.

-- Jeff