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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 21 May 2014 07:55 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C6E751A0835; Wed, 21 May 2014 00:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 qcw-fh6UXQDE; Wed, 21 May 2014 00:55:03 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0295E1A0831; Wed, 21 May 2014 00:55:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6592BE53; Wed, 21 May 2014 08:54:56 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcxXU7dR58EL; Wed, 21 May 2014 08:54:55 +0100 (IST)
Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 43AC9BE51; Wed, 21 May 2014 08:54:55 +0100 (IST)
Message-ID: <537C5BCE.4010801@cs.tcd.ie>
Date: Wed, 21 May 2014 08:54:54 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com>
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z7ZMB5wr8-Vhxh7G8O2cLlB9xdY
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: Wed, 21 May 2014 07:55:05 -0000

Manav,

On 21/05/14 08:39, Bhatia, Manav (Manav) wrote:
> Hi Stephen,
> 
> The crypto mathematics in our draft (and RFC 5310, 5709, 6506, .. and
> quite a few other RFCs/drafts) is slightly different from the basic
> HMAC. In all these RFCs we've introduced an additional pad
> (unimaginatively called the "Apad") that's used in the hash
> computation. We were asked to include the Apad when we were
> originally writing the IS-IS and OSPFv2 security (RFC 5310 and 5709)
> RFCs. Ran Atkinson along with Mathhew Fanto (from NIST) had earlier
> written the RIPv2 RFC which had first employed the Apad. I was
> unequivocally told (by the Security ADs as well) that the Apad had to
> be included since that's what NIST wanted. I am sure Ran Atkinson can
> explain you more clearly about what the actual deal was. However,
> ever since then, we've been including the Apad in all our standards
> (at least the ones coming out of the Routing Area WG).
> 
> This has now been extensively implemented and there are libraries
> available that account for the Apad when computing the hash for the
> routing protocols.
> 
> The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why
> LDP should be an exception. The same has been proposed for BFD btw.

Even given the above, I fail to see why you repeat this text over
and over and over. Is there a real logic for that?

S

> 
> Cheers, Manav
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, 2014
>> 2:53 AM To: Bhatia, Manav (Manav); IETF Security Directorate; The
>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc:
>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of
>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>> 
>> 
>> 
>> On 19/05/14 21:27, Yaron Sheffer wrote:
>>>>> 
>>>>> * 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.
>> 
>> The above does not sound like something I recognise. I have
>> repeatedly asked that documents not re-define HMAC. Perhaps this
>> time, I'll make that a DISCUSS and not budge. I probably should
>> have done that before TBH.
>> 
>> If you are revising that doc, *please* get rid of the re-definition
>> and just properly refer to HMAC. Its about time to stop repeating
>> that error.
>> 
>> S.
> 
> 
>