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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 20 May 2014 20:37 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 595961A0791; Tue, 20 May 2014 13:37:02 -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 fMYiS6U6aKu7; Tue, 20 May 2014 13:37:00 -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 62C331A0793; Tue, 20 May 2014 13:37:00 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id f8so6590169wiw.14 for <multiple recipients>; Tue, 20 May 2014 13:36:58 -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=DsQWwEo12usyJGRI+zO43lk4X4nyaDtAZCecjTrf3gA=; b=cfWA67AKFHsPrfSX28tpIiCnFqI97KZz+e4vZbvuQrswkIgxAfXj/btCG3dg2pUAHY PF3c7y9g0b2vKoI72qh6R+tNo6OBL7Xuy21bvU0J2Gf4LkDBST8YgPS2D7ayjxrZk4BL zyekGwHGjwy+gRp8XF78KsZ0zlcB0re38Ch32UufKhrfX7Jk6b59hfX69IvOdRUYUM0B f9LElrKnEfBKKbHVG6sVclmW1ihHQo1BoC4PBi1qFyWFNfBKJOJQjmUP+wJ5/ohoMjTX V2mpSYEIChAiyGcE4+DSpjauGL/Krws+uxDhR2GiNR1q6lU1ZuKgqYUTS/4/vb7RX7/L vJUQ==
X-Received: by 10.194.189.116 with SMTP id gh20mr39304224wjc.41.1400618218700; Tue, 20 May 2014 13:36:58 -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 nb8sm22558057wic.18.2014.05.20.13.36.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 13:36:58 -0700 (PDT)
Message-ID: <537BBCE9.3060803@gmail.com>
Date: Tue, 20 May 2014 23:36:57 +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: "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> <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com>
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qb_5v5pHhKwqu-s_RWFlSutLlwA
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: Tue, 20 May 2014 20:37:02 -0000

Hi Manav,

On 05/20/2014 01:35 PM, Bhatia, Manav (Manav) wrote:
> Hi Yaron,
>
[...]

>>>>
>>>> • 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.
>
> We have the following text in the draft:
>
>     In order to achieve smooth key transition, KeyStartAccept SHOULD be
>     less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
>     KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
>     unspecified, the time will default to 0 and the key will be used
>     immediately.  If KeyStopGenerate or KeyStopAccept are left
>     unspecified, the time will default to infinity and the key's lifetime
>     will be infinite.
>
> Can you suggest what else needs to be added to make it clearer?

I suggest to add: "Any unspecified values are encoded as zero."
>
>>
[...]
>>
>>>> • 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.
>
> I think you missed the text in Sec 5.1 which says:
>
>     The LDP Cryptographic Protocol ID is appended to the Authentication
>     Key (K) yielding a Protocol Specific Authentication Key (Ks).  In
>     this application, Ko is always L octets long.  While [RFC2104]
>     supports a key that is up to B octets long, this application uses L
>     as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
>     [RFC7166].
>
> In case of HMAC-SHA-512 the key size would be 512 bits.
>
> We never restrict the key size to 128.
>

I was referring to the following text, which I still think is misguided: 
"Deployments SHOULD use sufficiently long and random values for the 
Authentication Key so that guessing and other cryptographic attacks on 
the key are not feasible in their environments.  Furthermore, it is 
RECOMMENDED that Authentication Keys incorporate at least 128 
pseudo-random bits to minimize the risk of such attacks."

Crypto keys should have random bits amounting to their full length, 
rather than just a 128-bit subset of the key.

>>
>>>>
[...]

>
> Cheers, Manav
>