Subject: [core] FW: bootstrapping concerns still remain all (was Re:concerns re draft-oflynn-core-bootstrapping-02)

From: "Garcia Morchon, Oscar" <[email-masked]>
Date: Thu, 11 Nov 2010 14:43:57 +0100

Hey,

In my view, the proposed solution(s) in the existing bootstrapping draft can be a very valid solution for some use cases, but not for all of them.

The security design and the used security protocols/procedures/cryptoalgorithms depend on the target application and its needs regarding security, operation, or the available resources. In my view, we should first list a set of possible requirements/features. Once we have this list of requirements/features, we can map the proposed security solutions (e.g., some of them related to bootstrapping) to these requirements.

The advantage of doing this in this way is that anyone having a look at them can know for which purposes a solution is good and what the offered capabilities are.

I do not think that we can agree on a single solution that fits all the use cases and all the requirements.

In my view, we might have:

- different solutions for different applications if their needs are not compatible (e.g., one can assume the presence of a security manager in application A and this cannot be assumed for application B).

- or extend an existing solution to fulfill additional requirements if we consider a solution to be slightly incomplete.

I would be happy to collaborate to gather relevant requirements&features for the security design in an I-D.

Regards and have a safe trip back home,

      Oscar.

_____________________________

Oscar Garcia-Morchon

Distributed Sensor Systems

Philips Research Europe

www.research.philips.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday 11 November 2010 9:53
To: Rene Struik; core
Subject: Re: [core] bootstrapping concerns still remain all (was Re:concerns re draft-oflynn-core-bootstrapping-02)

Hi Rene,
  Currently some of the authors are attending IETF in Beijing.
We expect to discuss the points below as well as comments made during the presentation yesterday and possibly take some action. If you wish to get good results, my recommendation is to provide some text.

Regards,

Behcet

From: Rene Struik <[email-masked]>
To: core <[email-masked]>
Sent: Wed, November 10, 2010 8:08:43 AM
Subject: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02)

Dear colleagues:

I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main authors of previous versions.

Some preliminary feedback:
0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03 is in Section 5.1 only
1) Detailed analysis of deployment scenarios is still missing (since no changes to Appendix A - examples).
2) Security services to be offered still needs far more detail (I provided an initial list on September 29, 2010, after the CoAP Conf Call on desired properties and had *many* email exchanges on this in context of HIP protocol, but do not really see this reflected.
3) Consideration for security policies and trust management aspects is virtually not there.
4) It is entirely unclear whether one can rely on a globally unique (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear what the statement that one MUST support various tyypes of identities means, whether "various" could mean "1" and how one can bind the various identities, so as to allow conversion between theses and mapping this to a static globally unique id.
5) Multi-domain support: in my mind, intention should be that a device may be part of more than one network at the same time and be able to move from one to the next while maintaining part of its state.
6) Authentication/authhorization: An online connectivity to the "trust center" (a ZigBee term) is assumed. In many cases, this online connectivity is simply not there -- one of the main characteristics of sensor-style networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It seems that the centralized ZigBee model has been written-in without any explanation as to why this would cover deployment scenarios (which, by itself, reiterates importance to study deployment scenarios in detail.
7) The PANA Section does not describe what PANA accomplishes and section is littered with references to external standards (C12.22), without explanation of how things fit together, whether security framework and design philosophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security policy and trust management framework is.
8) The need for HIP is, after at least 10 email communications still entirely unclear. Moreover entanglement of name space and crypto space is still an issue. Most questions posed over the last month resulted in comments that one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items for next version of HI/HIP-DEX. In my mind, this indicates immaturity and (for now) unsuitability for standardization.
9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do not provide any motivation or allow one to grasp concepts behind things. As Cullen Jennings already articulated in his initial feedback: it is completely unclear how one would build to this.

I can provide more feedback once back from the current IEEE 802 meeting.

Best regards, Rene

On 27/10/2010 11:04 AM, Rene Struik wrote:
Dear colleagues:

I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well):

I miss a detailed analysis of deployment scenarios to be considered as guidance into design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios.

I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one  mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document.

BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments.

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT]

In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).

On 12/10/2010 12:23 PM, Rene Struik wrote:

Hi Tobias:

Thanks for your note.

Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing);

(b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would

correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/

personalization stage?

Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,

this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the

difference is in the "puzzle" element, couldn't one just add something similar to a

 well-known authenticated scheme that is already standardized with, e.g.,

NIST?

As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp

post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper

resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of

symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired"

functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that

matters is features and not what is "under the hood", as long as that is not

 cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of

draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic

properties. I would be happy to give this a look and review.

Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated

key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies

 these. If you could provide a succinct description of

the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!

> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication;

(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise

impersonation resilience, etc.).

Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to

rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small

setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would

allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different

disciplines).

Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid

entanglement of routing and naming?

On 07/10/2010 5:36 AM, Tobias Heer wrote:

To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!

> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).

Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?

--

email: [email-masked]<mailto:[email-masked]>

Skype: rstruik

cell: +1 (647) 867-5658

USA Google voice: +1 (415) 690-7363

--

email: [email-masked]<mailto:[email-masked]>

Skype: rstruik

cell: +1 (647) 867-5658

USA Google voice: +1 (415) 690-7363

--

email: [email-masked]<mailto:[email-masked]>

Skype: rstruik

cell: +1 (647) 867-5658

USA Google voice: +1 (415) 690-7363

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.