Re: [tcpm] [mpls] LDP Security

Jeff Tantsura <jefftant.ietf@gmail.com> Sat, 11 November 2017 03:12 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F08129408; Fri, 10 Nov 2017 19:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thX2hvXQ8o4B; Fri, 10 Nov 2017 19:12:06 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82C21200C1; Fri, 10 Nov 2017 19:12:06 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id l19so6195164pgo.2; Fri, 10 Nov 2017 19:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zeZ75tWzpVvem0+C/MRWXQ47EzxfApCKHS2ZCdNWwCU=; b=odCN5jbcl6P5YDIcNe/ge1V9tf6yF/uLGjCAJx4qwv3DxLYQaSaIIhDlLHDjb+CmWf Lqb64EdE16zFuytPjJHvhjDxUUEF5TE5LCuYdOZy8Nmux29E4QaKlKdXM6I1vDHdvm0X uo76DFVAx7LqVUOxnm9MKKSSUDgZ7qiKLIPWn1Au3RyVP5D6Lez2AqioyrSqY92STA2w ly98gk/uzDjfZGek9B4vjuoz3hVHpjbaUjhhFZOL4CT/59oQBQhNrUHTh1UmDD5rmE2d V+YkzRNPcyjj4T3KYnvAo5kaPUjZA/apnztmjARpP0uHsgDilK4yNIrBSEjCBP8Lk/84 BRZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zeZ75tWzpVvem0+C/MRWXQ47EzxfApCKHS2ZCdNWwCU=; b=PA/2lB/BQYO1hZWF87ige6jeKIsy02f/05qAI1BekyXJO96xr2peY2Zl7+l4tbF8v2 6kdhFL3KeiynbSPUEUU0jG8WdYhVrUFsEp9fp4oPRBo7gbV1j9wxSSauImU949ceIg6y XRnwK9QJQpYH+DitPnjj7SZ4o6bU0kG6F8NYm1Jt+WDsyYPQTJCImEVQbGVTWgGsHzv2 AWpjwQOGrSTvyhxbbmyZLzHZ6DLxKiCZDB2lWAaItCAgq8CtcfV+J2W8y3uNe68Gadkp 2brm0CUhm3LZ92KqIEZr2x2RI4PSnS5BTZZffuMXydvwZWcLbgln1OL1/Dh01MeyFNVy +F7w==
X-Gm-Message-State: AJaThX5r4YdnuR1HXTjxLE2mTHuqRp2eLni9wZYBFTxdenIkG98L8dZE R5Eb6kgxaWd2JMWtxByD9Hd8/4nS
X-Google-Smtp-Source: AGs4zMYxPkolZPjIywUbUf2DIuhV7bt/Q8lGrgna87LIrO9U1ILVl3FcyY4E4MMyc+ovC60j84SeCg==
X-Received: by 10.98.196.143 with SMTP id h15mr2532599pfk.126.1510369926015; Fri, 10 Nov 2017 19:12:06 -0800 (PST)
Received: from [31.133.148.178] (dhcp-94b2.meeting.ietf.org. [31.133.148.178]) by smtp.gmail.com with ESMTPSA id q70sm24612425pfj.39.2017.11.10.19.12.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:12:05 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-FDE8250F-18F6-4B4B-B7B0-459161C5CC0F"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com>
Date: Sat, 11 Nov 2017 11:11:57 +0800
Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, Eric Rescorla <ekr@rtfm.com>, Stewart Bryant <stewart.bryant@gmail.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "<sec-ads@ietf.org>" <sec-ads@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com>
References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <CAA=duU2YLjSg8Q5PDT+u9cxn9u2xsiPu-imBJrnyL3bfkQFW7A@mail.gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <CAA=duU3nJsS86udidgkH9jhB9ZD+xaRa2A4MniAVL1BpGE78ZQ@mail.gmail.com> <cf0cb5a4-cc21-97e1-1c26-38974bf9c0be@pi.nu> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <CAA=duU2R9kBMWnRdwPPO49LF1Jc1tyrxvwkyTgaE6SC6jsVruw@mail.gmail.com> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <CAA=duU1qV-LiU5pR7VtLLVGtb-8nZHrnUqVyOKpST3-6Dr-Xgw@mail.gmail.com> <ce2c75b6-156d-da80-91d7-b7e6ba2059a0@gmail.com> <CAA=duU1xvV0genbR0CBx2rmpOWUkFmRJX3qrMEp21gTd1HOVww@mail.gmail.com> <f0d553da-0ac4-e794-5cd5-d9cc95063dc6@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <CABcZeBOr5x=98nXeBCT8O-wjk90ga1F3EVk2ktMYoAj9Q8tRkg@mail.gmail.com> <AM5PR0701MB25472EFBB94C1C98EA2606B393540@AM5PR0701MB2547.eurprd07.prod.outlook.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/66oZiGJYz77gEpgEq9SdBX78fS0>
X-Mailman-Approved-At: Sat, 11 Nov 2017 08:04:13 -0800
Subject: Re: [tcpm] [mpls] LDP Security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2017 03:12:10 -0000

Joe,

There’s no problem with updating, the problem is with adoption...

Regards,
Jeff

> On Nov 11, 2017, at 08:48, Joe Touch <touch@strayalpha.com> wrote:
> 
> 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,” (RFC in progress), Nov. 2013.
> 
> U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO,” (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:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Wednesday, November 08, 2017 7:00 PM
>> To: Stewart Bryant <stewart.bryant@gmail.com>
>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
>> 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 <stewart.bryant@gmail.com> 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
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls