Re: [tcpm] [mpls] LDP Security

[Joe Touch <[e-mail]>]

Hi, all,

I don't see a problem if there's a need for updating TCP-AO to
include/require other algorithms. It was intended to be extensible.

I agree with the issue of key management. There was some work on
extensions to IKE to enable its use to manage TCP-AO parameters and
keys, but it stalled twice:

M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri,
A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in
IKEv2 <http://www.isi.edu/touch/pubs/draft-mahesh-karp-rkmp-05.txt>,”
(RFC in progress), Nov. 2013.

U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO
<http://www.isi.edu/touch/pubs/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt>,”
(RFC in progress), Feb. 2014.

AFAICT, that would go a long way towards addressing the issues with its
use outside routing environments where keys are already considered
sufficiently managed.

However, the larger problem with TCP-AO is that there are no
implementations available in end system OSes (AFAICT). Designing a new
solution simply to avoid implementing an existing one would be a
significant waste of time.

Joe


On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> +TCPM
>
>  
>
> Please free to discuss changes to TCP-AO on the TCPM list, or speak up
> at the upcoming TCPM meeting.
>
>  
>
> The addition of SHA-256 has been discussed in TCPM already (see
> draft-nayak-tcp-sha2-02), but so far there was not much energy and no
> interest from potential TCP-AO implementers or users.
>
>  
>
> Michael
>
> (TCPM co-chair)
>
>  
>
>  
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, November 08, 2017 7:00 PM
> *To:* Stewart Bryant <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; <[e-mail]>
> <[e-mail]>; [e-mail]; [e-mail];
> <[e-mail]> <[e-mail]>
> *Subject:* Re: [mpls] LDP Security
>
>  
>
> Hi Stewart
>
>  
>
> Thanks for your note.
>
>  
>
> My overall sense of the state of play is, I think much like yours.
>
>  
>
> TCP-MD5 is inadequate in two major respects:
>
> - It uses weak algorithms
>
> - It has a bad negotiation/setuop story (manual key management)
>
>  
>
> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so
> remedies the algorithm
>
> issue but not the key management issue [0]. We haven't made much
> progress on the key
>
> management story, and that seems to be a major impediment to deploying
> either of these
>
> technologies (which I am given to understand don't see a lot of use).
> We should probably
>
> talk in Singapore about that, but that's not going to get better any
> time soon.
>
>  
>
> In the interim, I think the text you have is OK, and "TBD" should read
> "SHA-256", with
>
> the fallback being SHA-256 -> SHA-1 -> MD5.
>
>  
>
> -Ekr
>
>  
>
>  
>
> [0] Technically It has better support for rollover, but this is not a
> huge improvement.
>
> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but
> opportunistic.  That said,
>
> it would provide defense against attackers who gain access to the link
> after connection
>
> setup and doesn't require configuration.
>
>  
>
> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     To the SEC and RTG ADs,
>
>     I am sending the following message on behalf of the MPLS and the
>     PALS WG Chairs.
>
>     There is a concern shared among the security community and the
>     working groups that develop the LDP protocol that LDP is no longer
>     adequately secured. LDP currently relies on MD5 for cryptographic
>     security of its messages, but MD5 is a hash function that is no
>     longer considered to meet current security requirements.
>
>     In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element
>     2. Session communication carried by TCP the following statements
>     is made:
>
>     "LDP specifies use of the TCP MD5 Signature Option to provide for
>     the authenticity and integrity of session messages.
>
>     "[RFC2385] asserts that MD5 authentication is now considered by
>     some to be too weak for this application.  It also points out that
>     a similar TCP option with a stronger hashing algorithm (it cites
>     SHA-1 as an example) could be deployed.  To our knowledge, no such
>     TCP option has been defined and deployed.  However, we note that
>     LDP can use whatever TCP message digest techniques are available,
>     and when one stronger than MD5 is specified and implemented,
>     upgrading LDP to use it would be relatively straightforward."
>
>     We note that BGP has already been through this process, and
>     replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow
>     the same approach to secure LDP. However, as far as we are able to
>     ascertain, there is currently no recommended, mandatory to
>     implement, cryptographic function specified. We are concerned that
>     without such a mandatory function, implementations will simply
>     fall back to MD5 and we will be no further forward
>
>     We think that the best way forward is to publish a draft similar
>     to RFC 7454 that contains the following requirement:
>
>     "Implementations conforming to this RFC MUST implement TCP-AO to
>     secure the TCP sessions carrying LDP in addition to the currently
>     required TCP MD5 Signature Option. Furthermore, the TBD
>     cryptographic mechanism must be implemented and provided to TCP-AO
>     to secure LDP messages. The TBD mechanism is the preferred option,
>     and MD5 is only to be used when TBD is unavailable."
>
>     We are not an experts on this part of the stack, but it seems that
>     TCP security negotiation is still work in progress. If we are
>     wrong, then we need to include a requirement that such negotiation
>     is also required. In the absence of a negotiation protocol,
>     however, we need to leave this as a configuration process until
>     such time as the negotiation protocol work is complete. On
>     completion of a suitable negotiation protocol we need to issue a
>     further update requiring its use.
>
>     Additionally we should note that no cryptographic mechanism has an
>     indefinite lifetime, and that implementation should note the IETF
>     anticipates updating the default cryptographic mechanism over time.
>
>     The TBD default security function will need to be chosen such that
>     it can reasonably be implemented on a typical router route
>     processor, and which will provide adequate security without
>     significantly degrading the convergence time of an LSR. Without a
>     function that does not significantly impact router convergence we
>     simply close one vulnerability and open another.
>
>     As experts on the LDP protocol, but not on security mechanisms,
>     we  need to ask the security area for a review of our proposed
>     approach, and help correcting any misunderstanding of the security
>     issues or our misunderstanding of the existing security
>     mechanisms. We also need the recommendations of a suitable
>     security function (TBD in the above text).
>
>     Best regards
>
>     The MPLS WG Chairs
>     The PALS WG Chairs
>
>  
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm