Re: [saag] Fate of BFD extended authentication mechanisms

[Stephen Farrell <[e-mail]>]

Folks,

Is there anyone who'll be in Berlin who'd be able to take a few
minutes to chat with Jeff and friends about bfd security?

We're often quite rightly scathing when folks develop protocols
in the IETF that have no or not well designed security and in
this case Jeff is asking for help to try avoid that bad outcome
and hoefully lead to the kind of good outcome that we security
folks keep on saying is what's needed.

If you're willing to meet Jeff and co for a chat/beer/coffee in
Berlin please drop Kathleen or I a line and we'll send the right
set of intros.

In case it helps, I think this could be an interesting enough
challenge - iiuc bfd is trying to amortise crypto costs over a
bunch of messages in the face of pretty tight performance
constraints.

Anyway, we'd really appreciate if if someone could help out here,
Thanks in advance,
S.

On 24/05/16 20:24, Jeffrey Haas wrote:
> 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
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>