Re: [Roll] [roll] #142 (applicability-home-building): Clarification of secure key distribution

"roll issue tracker" <> Mon, 28 April 2014 19:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B70E1A6FB2 for <>; Mon, 28 Apr 2014 12:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F646QN5Mnd9m for <>; Mon, 28 Apr 2014 12:54:07 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 335B31A6FA8 for <>; Mon, 28 Apr 2014 12:54:05 -0700 (PDT)
Received: from localhost ([]:40711 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1WercT-0001t9-Fq; Mon, 28 Apr 2014 21:53:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: roll
Date: Mon, 28 Apr 2014 19:53:40 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 142
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [Roll] [roll] #142 (applicability-home-building): Clarification of secure key distribution
X-Mailman-Version: 2.1.15
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Apr 2014 19:54:09 -0000

#142: Clarification of secure key distribution

Comment (by

 Robert Cragie comment - date: 04/23/2014


 It may seem a moot point but it is not essential for the *delivery
 mechanism* to have replay protection. A key management scheme itself
 clearly has to be able to manage the lifetime of keys including deployment
 and retirement. Therefore, for example, a group key is always associated
 with a key index or sequence number, which is typically part of the
 payload of a secure key update. Therefore, if this were replayed, it would
 implicitly not work as the key index would clearly be for an old key. The
 main reason I say this is because key wrapping schemes (e.g. RFC3394)
 often do not build in replay protection and RFC3394 indeed states the
 following: "This key wrap algorithm needs to provide ample security to
 protect keys in the context of prudently designed key management

 Therefore, I would prefer to add a sentence to the same effect, just not
 to associate it with the delivery mechanism. So I would suggest something

 "Securely delivering a key means that the delivery mechanism MUST have
 data origin authentication, confidentiality and integrity protection. On
 reception of the delivered key, freshness of the delivered key MUST be


 Catherine Meadows comment  - 04/24/2014

 <CM> I am fine with all of Robert’s comments.</CM>

 Reporter:                           |       Owner:  draft-ietf-roll-      |  applicability-home-
     Type:  defect                   |
 Priority:  minor                    |      Status:  new
Component:  applicability-home-      |   Milestone:
  building                           |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <>
roll <>