Re: [secdir] Security directorate review of draft-ietf-tcpm-yang-tcp-06

["Scharf, Michael" <[e-mail]>]

Hi Hilarie,

Thanks a lot for this review.

We have changed the wording regarding TCP-AO to be more explicit that TCP-AO is only required if TCP authentication is required (i.e., not IPsec or TLS). The suggested wording is now:

   Given an installed base, the model also allows enabling of the legacy
   TCP MD5 [RFC2385] signature option.  The TCP MD5 signature option was
   obsoleted by TCP-AO in 2010.  If current implementations require TCP
   authentication, it is RECOMMENDED to use TCP-AO TCP-AO [RFC5925].

The lack of authentication failure statistics is indeed a good catch. Yet, I believe that authentication failure statistics could be modeled generically for several security protocols, i.e., they may not be specific to TCP-AO. As a result, an alternative approach might be a generic YANG model for such statistics, which could hopefully be used by TCP-AO implementations as well. Yet, the TCPM WG would not be the right place for specifying such a more widely applicable statistics model.

Version -07 tries to address also other IETF last call reviews and thus includes several changes. Please have a look at the new version (https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-07) or the diff (https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-07) and let us know if more is needed.

Best regards

Michael


> -----Original Message-----
> From: Hilarie Orman <[e-mail]>
> Sent: Wednesday, March 2, 2022 7:57 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Security directorate review of draft-ietf-tcpm-yang-tcp-06
> 
>                     Security review of
> A YANG Model for Transmission Control Protocol (TCP) Configuration
>                 draft-ietf-tcpm-yang-tcp-06
> 
> Do not be alarmed.  I generated this review of 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
> with the intent of improving security requirements and considerations
> in IETF drafts.  Comments not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> The abstract:
>    This document specifies a minimal YANG model for TCP on devices that
>    are configured by network management protocols.  The YANG model
>    defines a container for all TCP connections and groupings of
>    authentication parameters that can be imported and used in TCP
>    implementations or by other models that need to configure TCP
>    parameters.  The model also includes basic TCP statistics.
> 
> This is a well-written document that brings up a troubling issue, the
> outdated use of a keyed hash for authentication in TCP.  The fact that
> there is such an option seems to be an expediency introduced long ago.
> Originally, the hash algorithm was MD5, which made sense at the time.
> Apparently that has become deeply embedded in network infrastructure.
> Although the Authentication Option was later updated to include a
> better hash algorithm, the unfortunate choice was SHA-1.  Both MD5 and
> SHA-1 are considered "broken".
> 
> The keyed hash with MD5 or SHA-1 might be justified as "better than
> nothing" or "good enough for our use cases", but it has the effect of
> forcing two bad hash algorithms to reside permanently in the code base
> for network management.  There are security efforts to move to
> post-quantum cryptography and a quantum Internet, yet the oldest and
> most unsuitable cryptographic algorithms seem set in stone.  It is as
> though one looked into an ALU with a microscope and found a tiny
> abacus etched into the silicon for backwards compatibility.
> 
> >From a security standpoint, it would be best if the YANG TCP document
> were to recommend strongly against using TCP authentication no matter
> what the hash algorithm is.  The recommended security solution is to
> use IPSec or TLS to secure connections.
> 
> In the event that TCP authentication remains in YANG, I note that
> there are no statistics kept for authentication failures.  If a shared
> key falls out of synch, the statistics might help detect that.
> 
> Hilarie
>