Re: [secdir] secdir review of draft-ietf-mpls-gach-adv-06

Dan Frost <> Mon, 18 February 2013 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FBDB21F8A2F; Mon, 18 Feb 2013 06:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xAhDte98xLPa; Mon, 18 Feb 2013 06:31:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B421421F8A14; Mon, 18 Feb 2013 06:31:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2668; q=dns/txt; s=iport; t=1361197905; x=1362407505; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WpagxTaNX9dBuN8jXMsA8s5mjGbRU48GsvzSPH6yR2M=; b=hvyEBV7RDBmEPilAzsF0XIQH133+ol4Q45MH3fAkyodp8o8vDVN+A1xn 5YXIVubEJVQTQl09a7IBgm4+gjht+seudK7ZN2ckLOn/KNQBsGBebE1Cr HO2gag6YPXVGKZM6FmCipLxhyk8a8lh6QNx7axfCdsaBxguhkPuKNcuqT I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADo6IlGtJXG+/2dsb2JhbABFwCOBAxZzgh8BAQEDAToxDgULCxgJJQ8FSYgfBsBDjzcHgl9hA5YrAZBYgweBayQ
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="175311582"
Received: from ([]) by with ESMTP; 18 Feb 2013 14:31:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r1IEVi6c008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 14:31:45 GMT
Received: from (isolaria []) by (8.13.1/8.13.1) with ESMTP id r1IEVgW9029648; Mon, 18 Feb 2013 09:31:44 -0500
Received: (from danfrost@localhost) by (8.13.1/8.13.1/Submit) id r1IEVgSK029647; Mon, 18 Feb 2013 14:31:42 GMT
Date: Mon, 18 Feb 2013 14:31:42 +0000
From: Dan Frost <>
To: Leif Johansson <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc:, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-mpls-gach-adv-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Feb 2013 14:31:47 -0000

Hi Leif,

On Mon, Feb 18, 2013 at 02:08:15PM +0100, Leif Johansson wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> The technology is somewhat outside my area of expertise but I found
> the document relatively easy to follow anyway.

Thanks for your review.

> I'm a fan of writing crypto-related algorithms with very little left 
> for the imagination of the reader. To that end I would strongly suggest 
> specifying what goes into the GAP message hash even more clearly. 
> In this case I suspect the intent is that the inner hash is over all 
> bytes of GAP message except the GAP authentication TLV which is added 
> to the message _after_ the hash is computed.

No need to suspect; the current text is explicit.  ;)  It says:

   2.  First Hash

          First, the Authentication Data field is filled with the value

          Then, a first hash, also known as the inner hash, is computed
          as follows:

             First-Hash = H(Ko XOR Ipad || (GAP Message))

          Here the GAP Message is the portion of the packet that follows
          the Associated Channel Header.

The last paragraph specifies that the hash is computed over all bytes of
the GAP Message that follow the Associated Channel Header.  This
includes the Authentication TLV, which is not a problem because "First,
the Authentication Data field is filled with the value Apad."

> Conversely the validation phase needs to clearly say what bits of the
> message are to be included in computing the hash.

The text states that "When the message is received, the receiver
computes a hash for it as described below", where "below" is Section 6.3
(we should probably s/below/Section 6.3/ here).  In other words, the
transmitter and receiver perform the same computation with the same
input (modulo the Authentication Data field, which is normalised by the
computation itself).

> Also I would change the timestamp verification step to use normative
> language, eg: "... the receiver MUST, upon successfully authenticating
> a message verify that the timestamp field corresponds... The receiver 
> MUST silently discard a GAP message that fails timestamp verification."

Well, use of the replay mitigation mechanism is not required, so I'm not
sure that adding "MUST" language is appropriate.