Subject: [saag] Fate of BFD extended authentication mechanisms

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 May 2016 15:24:00 -0400

Security-folk,

Partially as a response to work concluded in the KARP Working Group, there
was previously some effort to enhance the cryptographic authentication
mechanisms present in BFD.  The core BFD protocol is described in RFC 5880,
including its authentication mechanisms.

The two main documents covering this work are below:

https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06
https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05

To somewhat tritely summarize the work in these two documents, the generic
doc provides for:
- Increase the number space of authentication sequence number to 64 bits
  from 32.
- Provide a larger numbering space for key identifiers, from 8 bits to 16
  bits.
- Re-using this structure for all future types rather than making it a
  property of the individual authentication section for a given mechanism.

The hmac-sha doc describe SHA-2 variants of ciphers.

In general, these are understood to be the Right Things to do for BFD.
However, lack of interest in the industry from either vendors or customers,
and lack of drive from within the working group have contributed to these
documents going stale.

There is also the secondary issue that as a result of the speed at which BFD
operates and the fact it is often operating under extremely constrained
compute resources, even existing ciphers are not well deployed in spite of
the known weaknesses in the strength of those ciphers.  There is a separate
effort beginning in BFD that may mitigate these issues, but I have requested
the authors of that draft to contact the security area separately to discuss
their proposal:

https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

Now to my question:

It's generally understood that implementations of security mechanisms often
lag their specifications.  It's also generally understood that you want
those specifications to exist because when you need them, it's possibly
already too late.

Given this, I'm looking at options to help drive the BFD generic crypto and
hmac-sha document to publication.

As mentioned, the interest in the BFD WG is low.

My question is what is the perceived status of security related documents
that are on the Experimental track?  

For these documents to progress on the standards track, they'd have to have
some likelihood of being deployed.  That point is, as above, unclear.

-- Jeff

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 25 May 2016 02:03:00 +0000

Jeffrey Haas <[email-masked]> writes:

>mechanisms present in BFD.

Boston Fire Department?  Big F**cking Deal?  Bad Fur Day?  Bidirectional
Forwarding Detection?  Binary File Descriptor?  Block Flow Diagram?  Base
Flood Depth?  Bowling for Dollars?  Blood Fire Death?

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 24 May 2016 22:45:54 -0700

Hi Peter,

Peter Gutmann <[email-masked]> writes:

> >Partially as a response to work concluded in the KARP Working Group,
> >there was previously some effort to enhance the cryptographic
> >authentication mechanisms present in BFD.
> 

My guess would be this one:

  IETF BFD WG => Bidirectional Forward Detection (bfd)
  https://datatracker.ietf.org/wg/bfd/documents/

And I suspect that this is the effort at hand...

Optimizing BFD Authentication
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

See also RFCs: 5880 5881 5882 5883 5884 7130 7330 7331 7419 7226

Of course, I could be wrong and one of your suggestions might be correct. :-)

	Enjoy!
	-- Mark

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 25 May 2016 10:22:49 -0400

Peter,

> On May 24, 2016, at 10:03 PM, Peter Gutmann <[email-masked]> wrote:
> 

You cut off the next immediate sentence:

The core BFD protocol is described in RFC 5880,
including its authentication mechanisms.

Jokes about the acronym aside (I've heard them all before), please stop the trolling.  While I generally have good intentions toward Doing The Right Thing for security issues, the security ADs will happily confirm my patience for the process is weak at the best of times.

-- Jeff