Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 19 May 2014 21:16 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B7B1A038B; Mon, 19 May 2014 14:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 6hYsg1CvN6yB; Mon, 19 May 2014 14:16:45 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8440F1A0176; Mon, 19 May 2014 14:16:44 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id f8so4874885wiw.8 for <multiple recipients>; Mon, 19 May 2014 14:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qBz5p210DiQmsvWhCqMET+O5IQToN2iBw3X8rYZJacM=; b=k+gLNcbmTzWJ3SupzeL6Oi4p75U4UkjTOYpXesJgrKeEHp+w0fyR39kbpnB0CMYtqm MFQp5Gje7hCO1iUFnCswOso95xHuBGR6RFFvzR7aprQqwLqOcHhuWLQx+5ONyteqT1VC BL32NYxi31h2bvXzabqo8G7ZmiolcqXHK3e6M0egrdUiiE7O23x0Emfeo9kQwk4WW98z vTfnbech32SAPKXk8aa3u5xqBlXVoccFl8zZ/Svu5J5eLiTwgR4z/ZNM7aAtSeJXnM+J gSDrQkWQ4wKfG7mKD3n1YYI9dMemQXuUdspFtt8wFajiaXs6QXjhRhBTmCQtuPVAknUd S64Q==
X-Received: by 10.180.187.111 with SMTP id fr15mr620459wic.57.1400534203106; Mon, 19 May 2014 14:16:43 -0700 (PDT)
Received: from [10.0.0.5] (bzq-109-66-60-226.red.bezeqint.net. [109.66.60.226]) by mx.google.com with ESMTPSA id dk10sm8532533wib.1.2014.05.19.14.16.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 14:16:42 -0700 (PDT)
Message-ID: <537A74B9.6000107@gmail.com>
Date: Tue, 20 May 2014 00:16:41 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ross Callon <rcallon@juniper.net>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" <draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>
References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <00ea53d8fd3e4bf9b2fb3a9c4266bdfd@CO2PR05MB636.namprd05.prod.outlook.com>
In-Reply-To: <00ea53d8fd3e4bf9b2fb3a9c4266bdfd@CO2PR05MB636.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/btCVNQYTjBgqfgMWqoskra1DO6Y
Cc: "manavbhatia@gmail.com" <manavbhatia@gmail.com>
Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 21:16:47 -0000

It hasn't been a great success (as far as I know), but msec 
(http://tools.ietf.org/wg/msec/) spent a lot of energy and published a 
lot of documents in this area. For example, RFC 4535.

Thanks,
	Yaron

On 05/19/2014 11:59 PM, Ross Callon wrote:
> I have what may be a slightly ignorant question, but...
>
> When I looked at automated key management protocols many years ago, they worked between two systems (system A talks to system B). In particular, at some point multiple years ago the automated key management protocols did not work between many routers all talking to each other across a broadcast LAN, which for example might need to multicast routing traffic among themselves.
>
> Is this still true?
>
> Thanks, Ross
>
> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Sent: Monday, May 19, 2014 4:28 PM
> To: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org
> Cc: manavbhatia@gmail.com
> Subject: Re: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
>
> Hi Manav, thanks for your response. Please see clarifications below.
>
> 	Yaron
>
> On 05/19/2014 03:17 AM, Bhatia, Manav (Manav) wrote:
>> Hi Yaron,
>>
>> Thanks for the comments. My comments inline.
>>
>>>
>>> • The main issue is that only a symmetric crypto option is defined.
>>> IMHO, adding a public-key based scheme would be invaluable. Public keys
>>> do not necessarily imply certificates, and can be used with little
>>> added
>>> complexity compared to the current proposal. As far as I can see, the
>>> current use is not so performance constrained to preclude public key
>>> operations. And public keys would enable much easier and more secure
>>> deployment in many cases:
>>> 	∘ Different organizations can accept messages from one another,
>>> without
>>> needing to share the same keys. So even if groups keys are used (which
>>> is certainly not the best practice), public keys have an advantage.
>>> 	∘ Revocation is much simpler: to be able to revoke each
>>> individual
>>> sender (e.g. when a router is decomissioned), you need N**2 SAs in the
>>> symmetric case, vs. N keys when public keys are used.
>>
>> The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP.
>>
>> With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details).
>>
>> Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards.
>>
>> Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations.
>>
>
> I understand the statement "we do not know where we're going, so let's
> not over-design now". But note that even with SDN and even with a key
> management protocol, public keys have an advantage over symmetric keys
> for this scenario. And if you have automated key
> management/distribution, the simplicity of symmetric keys actually
> becomes less important.
>
>>> • Managing the 32-bit SAID manually in a large network is extremely
>>> onerous. So in practice keys would be rarely on never changed.
>>
>> Ok, so whats the point?
>
> That you need automated key management, otherwise this mechanism is an
> overkill.
>
>>
>>>
>>> • 2.2: the authentication algorithm and the authentication key are not
>>> "independent", because the algorithm normally determines the key
>>> length.
>>
>> This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo.
>>
>
> Sure, this is a nit.
>
>> Authentication Key
>>
>>         This value denotes the cryptographic authentication key associated
>>         with the LDP SA.  The length of this key is variable and depends
>>         upon the authentication algorithm specified by the LDP SA.
>
> Good.
>
>>
>>>
>>> • 2.2: the various time values included in the SA essentially require
>>> (rough) time synchronization between the nodes. If this is the case,
>>> time values could have been used for replay protection, which would
>>> have
>>> been much simpler to implement than the 64-bit sequence number which
>>> needs to persist across reboots.
>>
>> The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection.
>
> Note that the timer values are optional (the draft says they can be left
> "unspecified"), but the draft doesn't say what value should be in the
> field if the values are to be omitted. I *guess* it should be "0",
> please clarify it.
>
>>
>> Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862)
>
> That really depends on what data is signed by the key. But I see your point.
>
>>
>>>
>>> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This
>>> reviewer does not have the appropriate background to critique the
>>> proposed solution, but there must be an overwhelming reason to reopen
>>> cryptographic primitives.
>>
>> This is a decision that was taken by Sec Ads when we were doing the crypto protection for the IGPs based on some feedback from NIST. This mathematics is not new and has been done for all IGPs and has been approved and rather encouraged by the Security ADs.
>>
>
> Then I guess I disagree, but I am not familiar with the background for
> this decision.
>
>>>
>>> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too
>>> short for others. In general, the recommended key length is not
>>> constant. It depends on the algorithm.
>>
>> This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough?
>
> Personally, I think 128 bits are great :-) Seriously, if people are
> using HMAC-SHA-512 then 128 is not appropriate. You can argue that you
> don't need more than 128 bits of entropy, but then I would suggest to
> remove SHA-512 from the draft. The general point is that different
> algorithms require different key lengths.
>
>>>
>>> • "The mechanism described herein is not perfect and does not need to
>>> be
>>> perfect." This is kind of vague, and would be better replaced by your
>>> security goals.
>>
>> I think we can just delete this! :-)
>
> Please do.
>
>>
>> Cheers, Manav
>>
>>>
>>> Thanks,
>>> 	Yaron