Re: [mpls] LDP Security

[Eric Rescorla <[e-mail]>]

I don't understand what you're getting at here. Yes, if people have TCP-AO
then presumably they have SHA-1.

But now we're talking about requiring people to have TCP-AO in this case,
so we should try to move them to SHA-256 at the time we require AO.

-Ekr


On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri <[e-mail]>
wrote:

> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Wednesday, November 08, 2017 3:53 PM
>
> *To:* Uma Chunduri <[e-mail]>
> *Cc:* Stewart Bryant <[e-mail]>; [e-mail];
> [e-mail]; <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail]; <[e-mail]> <[e-mail]>
> *Subject:* Re: [mpls] LDP Security
>
>
>
>
>
>
>
> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <[e-mail]>
> wrote:
>
> In-line [Uma1]:
>
> --
>
> Uma C.
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Wednesday, November 08, 2017 12:53 PM
> *To:* Uma Chunduri <[e-mail]>
> *Cc:* Stewart Bryant <[e-mail]>; [e-mail];
> [e-mail]; <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail]; <[e-mail]> <[e-mail]>
>
>
> *Subject:* Re: [mpls] LDP Security
>
>
>
>
>
>
>
> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <[e-mail]>
> wrote:
>
> Hi Stewart,
>
>
>
> I would note https://tools.ietf.org/html/rfc6952 - where LDP security is
> analyzed from all aspects.
>
>
>
> Eric,
>
>
>
> Quick comments below [Uma]:
>
>
>
> --
>
> Uma C.
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, November 08, 2017 10:00 AM
> *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
>
>
>
> [Uma]: Yes, if we go with RFC 5926 mandatory list..
>
>
>
> 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).
>
>
>
> [Uma]: True.
>
>                But I would indicate some effort done few years back
> regarding key management for pair wise routing protocols (BGP, LDP, PCEP,
> MSDP ..).
>
>                One such proposal is by extending IKEv2 to negotiate TCP-AO
> MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/
> draft-mahesh-karp-rkmp-05
>
>                This also requires some more work with TCP-AO; me & Joe put
> together https://www.ietf.org/archive/id/draft-chunduri-karp-using-
> ikev2-with-tcp-ao-06.txt
>
>            Note the above didn’t progress in the concluded KARP WG (not
> fully sure the reasons on why).
>
>
>
> Yeah, I know that people tried to do this, but my impression was it kinda
> didn't progress much.
>
>
>
>
>
>
>
> 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.
>
>
>
> [Uma]: While the list can be extended - I didn’t see SHA256 in the
> mandatory list in RFC 5926 for MAC.
>
>
>
> Generally we're trying to move away from SHA-1 towards SHA-256.
>
>
>
> [Uma1]: Couple of things:
>
> 1.       *Nothing to be done (from spec pov of course):* Use TCP-AO
> (instead of current MD5) with the RFC 5926 mandated MACs/KDFs – so the
> ‘TBD’ in Stewart suggesting below is already there.
>
> 2.       As #1 too is not good enough from your above note - do SHA-256
> and live with it (no algorithm agility). Still a security benefit in one
> way from existing stuff or even  #1.
>
> I'm not sure why you say "no algorithm agility". You'd be using AO, just
> with a different algorithm than SHA-1. AES-CMAC is still fine as far as I
> know.
>
> [Uma2]: Sure, you have it, if you use AO;
>
>                  But then  I am not getting how we can mandate one MUST
> implement algorithm as suggested below TBD  would actually work
>  (especially - **if** #1 is already deployed somewhere?)
>
>                  Perhaps staying with #1 is the best bet or do negotiation
> through #3, with already mandated and additional stuff.
>
>
>
> -Ekr
>
>
>
> 3.       Do key management and “theoretically” get all we wanted….
>
>
>
> We have been here multiple times; because #1 itself is not **mostly**
> deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3
> for practical deployments. But still it may be good to do #2 any ways.
>
>
>
>
>
> -Ekr
>
>
>
>
>
> -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]>
> 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
>
>
>
>
>
>
>