[dtn-security] BSP and key management

"Peter Lovell" <peter.lovell@sparta.com> Tue, 30 October 2007 18:02 UTC

Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by maillists.intel-research.net (8.13.8/8.13.7) with ESMTP id l9UI27bg010305; Tue, 30 Oct 2007 11:02:08 -0700
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l9UI27Lr009760; Tue, 30 Oct 2007 13:02:07 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l9UI27Fa005380; Tue, 30 Oct 2007 13:02:07 -0500
Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 14:02:06 -0400
From: "Peter Lovell" <peter.lovell@sparta.com>
To: "dtn interest" <dtn-interest@mailman.dtnrg.org>, "dtn security" <dtn-security@mailman.dtnrg.org>
Date: Tue, 30 Oct 2007 14:02:02 -0400
Message-Id: <20071030180202.1187477270@127.0.0.1>
X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-OriginalArrivalTime: 30 Oct 2007 18:02:06.0908 (UTC) FILETIME=[FBE46FC0:01C81B1E]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 30 Oct 2007 13:02:07 -0500 (CDT)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id l9UI27bg010305
Subject: [dtn-security] BSP and key management
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2007 18:02:12 -0000

The first open issue relates to how we handle key management.

Various of us have different ideas of exactly what it means -- what's in
and what's not. And each of these has a number of component parts.

One obvious component is some kind of information-store or database
where keys or key-material are saved. There are also the processes for
interacting with local users of the key storage, forming what might be
called a "key service". Another is the interaction mechanism for a key-
service at one location and a remote key-service at another.

My goal is for this thread to decide which things should go into BSP
specification and which should more properly be in the new KM spec
initiated by Stephen 
<http://www.ietf.org/internet-drafts/draft-farrell-dtnrg-km-00.txt> 
and then reach closure on at least the BSP portions.

>From the BSP standpoint, I see two main items:-
1. what minimum capability is required in support of the mandatory
ciphersuites
2. what does key material look like in a bundle

The term "key material" used for a bundle is expansive and encompasses
all the keys and related "stuff" such as certificates, IVs, signatures,
key references or identifiers, etc etc.

The other requirements and characteristics seem to be better placed in
the KM spec, things like:-
1. key-wrap using symmetric and assymetric keys
    (algorithms, procedures etc)
2. rules for storage (protection) and usage of key material
3. key exchange and/or negotiation protocol between nodes
    (BSP itself never negotiates keys)


Thanks.....Peter

p.s. we only look at KEKs here, not traffic keys