Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG)

From: Zhen Cao <[email-masked]>
Date: Fri, 1 Oct 2010 21:07:51 +0800

Excuse me to jump into the discussion. I am also interested in
HIP/Diet-HIP protocol.

In my mind, HIP offers authenticated key exchange via the use of
signatures, i.e., the DH exchange is signed and thus authenticated.
After the exchange, IPSEC ESP is established and data authentication
is achieved via the IPSEC SA.

Thanks,
Zhen

On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik <[email-masked]> wrote:
> Hi Carsten:
>
> Thanks for the minutes. I just had a quick look and somehow seemed to have
> missed during the conf call your reference to the HIP protocol. Could you
> elaborate a little bit more? To my knowledge, HIP essentially does ephemeral
> Diffie-Hellman key agreement, thus not offering authenticated key agreement.
> In my mind, authenticated key agreement is essential to trigger data
> authentication tied to a unique identifier and allow trust lifecycle
> management to be reduced to management of device identities (via use of
> certificates). See also the brief summary below.
>
> Perhaps, we should discuss this somewhat more early next week.
>
> Best regards,
>
> Rene
>
> [summary of old proposal of mine on trust lifecycle management that could be
> used with bootstrapping document]
> §1 Proposal summary
>
> The proposal encompasses an intuitive, yet secure approach to provisioning
> and configuration of sensor networks. The approach hides security details
> from the user, thus allowing ease of device and network setup and
> flexibility of trust lifecycle management, while doing away with security
> hassles that have plagued more conventional approaches.
>
>  The proposal uses public-key cryptography, a security technology that
> allows reduction of trust lifecycle management to the management of trusted
> device identities (via so-called certificates), and security policy
> enforcement techniques based on lifecycle management of device roles.
>
> From a user’s perspective, this results in a system where trusted lifecycle
> management appears to be the same as that of an unsecured network: it simply
> comes down to proper identification of devices (e.g., reading off a label of
> a physical module) and proper management of device roles (e.g., adding these
> to, resp. removing these from a white list, e.g., via a workstation GUI). No
> secret information is disclosed at any lifecycle stage of a device or a
> system, nor needs to be, since management relies completely on handling of
> public information. This greatly reduces the complexity of lifecycle
> management and, thereby, training requirements for operational personnel.
> Moreover, it virtually removes trust dependencies between different entities
> involved in the value chain, whether OEM, vendor, system integrator,
> installer, or user. Lastly, the approach has the benefit of allowing
> enforcement of standards compliance (by only issuing a certificate to
> devices from vendors that passed conformance testing).
>
>
>
> On 29/09/2010 5:36 PM, Carsten Bormann wrote:
>
> On Sep 29, 2010, at 15:33, Carsten Bormann wrote:
>
>      http://6lowapp.net/2010-09-29/
>
> ... and the minutes are now also up there.
> Please tell me if I have misrepresented anyone.
>
> At 90 minutes, this was a short and sweet meeting.  Thanks to everyone who
> participated, and in particular to Markus Becker who at very short notice
> volunteered to take notes (all errors in the massaged version are of course
> mine).
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>
> --
> email: [email-masked]
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 01 Oct 2010 09:57:52 -0400

Hi Zhen:

To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan 
slide deck), the HIP-DEX protocol only provides evidence that the 
communicating parties involved with the key agreement scheme had access 
to the long-term private key (i.e., key possession), not of their 
identity. These properties are essentially those offered by the 
ephemeral Diffie-Hellman (DH) key agreement scheme (which does not 
provide for authentication of either party involved with the protocol); 
hence, my reference hereto.

Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, Para 
6.3.3), which describes C(0,2), i.e., DH using static keys, where key 
derivation includes use of nonce provided by the initiating party. As 
such, this does not include the use of signatures. As final notes: (a) 
the C(0,2) scheme assumes that public keys are tied to identities (cf. 
Para 6.3.3, l. 1); (b) the scheme does not provide forward secrecy 
(i.e., compromise of a device may compromise past secrets established 
with that device [in my mind, an undesirable property for internet of 
things type devices, which cannot be assumed to have physical protection 
and may be placed out in the open (e.g., screwed on a garage or street 
lamp post)]).

Best regards, Rene

On 01/10/2010 9:07 AM, Zhen Cao wrote:
> On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik<[email-masked]>  wrote:
>> Hi Carsten:
>>

---

From: Zhen Cao <[email-masked]>
Date: Fri, 1 Oct 2010 22:59:12 +0800

On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik <[email-masked]> wrote:
>  Hi Zhen:
>
> To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan slide
> deck), the HIP-DEX protocol only provides evidence that the communicating
> parties involved with the key agreement scheme had access to the long-term
> private key (i.e., key possession), not of their identity. These properties
> are essentially those offered by the ephemeral Diffie-Hellman (DH) key
> agreement scheme (which does not provide for authentication of either party
> involved with the protocol); hence, my reference hereto.

I was based on draft-moskowitz-hip-rg-dex-02, section 4.1.  On page 8,
the HIP diet exchange I2 and R2 include a computed MAC, I think it is
used for authentication of either party.

The full capability HIP is able to do the authenticated key exchange,
your concern is that current Diet-HIP cannot do that? If so, we can
input this as a requirement for Diet-HIP while it is not so closed to
an RFC.

Thanks,
Zhen

> derivation includes use of nonce provided by the initiating party. As such,
> this does not include the use of signatures. As final notes: (a) the C(0,2)
> scheme assumes that public keys are tied to identities (cf. Para 6.3.3, l.
> 1); (b) the scheme does not provide forward secrecy (i.e., compromise of a
> device may compromise past secrets established with that device [in my mind,
> an undesirable property for internet of things type devices, which cannot be
> assumed to have physical protection and may be placed out in the open (e.g.,
> screwed on a garage or street lamp post)]).

I will check with the NIST document and come back soon.

---

From: Rene Struik <[email-masked]>
Date: Fri, 01 Oct 2010 12:16:31 -0400

Hi Zhen:

I have some trouble understanding the internet draft 
draft-moskowitz-hip-rg-dex-02 that you refer to, perhaps due to my 
difficulty in separating presumed cryptographic steps in the key 
agreement scheme from "puzzle element" steps presumably aimed at 
thwarting Denial of Service attacks.

 From what I do understand, though, identities are a function of the 
long-term public key (witness also Section 3.2 of 
draft-ietf-hip-rfc5201-bis-02, which forementioned HIP-DEX draft 
presumes familiarity with). If so, pragmatically, identities are public 
keys and, thereby, would change depending on key lifecycle 
considerations. In my mind, this seems a no-go to get mass-scale 
deployment from the ground.

BTW (not relevant to authentication topic) - It is not immediately clear 
whether the "puzzle" presented from responder to initiator (Puzzle is to 
compute J so that x:=CMAC_I (  Id_A || Id_B || J) has a pre-fixed 
pattern on K bit positions) does not allow for "shortcuts", thus 
allowing its solution with expenditure of far less than 2^K 
trial-and-error computing rounds. Can't one do a meet-in-the-middle type 
of attack here? Anyway, not directly relevant to the authentication 
question at hand (although perhaps adding to confusion).

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.).

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).

Rene

On 01/10/2010 10:59 AM, Zhen Cao wrote:
> On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik<[email-masked]>  wrote:
>>   Hi Zhen:
>>

---

From: Tobias Heer <[email-masked]>
Date: Thu, 07 Oct 2010 11:36:05 +0200

Hi Rene, 

From discussions with Robert in the HIP RG and from his presentations I take that DEX/Diet HIP is an initial offer from Bob in which he tries to cut down the computational cost of the crypto-primitives and implementation cost of HIP as low as possible while still maintaining its key features. From your mail and some offline discussions I take that this cut might have been too low for some people and that the use of non-cryptographic names bound via certificates might be an enabler for some scenarios. In this regard, the list of security and operational requirements in the end of your e-mail might help Bob and other authors a lot because they can test their work against such list.

I'll try to address some of your questions in line.

> Hi Zhen:

[...]
> 
> From what I do understand, though, identities are a function of the long-term public key (witness also Section 3.2 of draft-ietf-hip-rfc5201-bis-02, which forementioned HIP-DEX draft presumes familiarity with). If so, pragmatically, identities are public keys and, thereby, would change depending on key lifecycle considerations. In my mind, this seems a no-go to get mass-scale deployment from the ground.
> 
Your concerns got me thinking and I came up with something that might solve your problem (or rather the problem of HIP) here. I'll briefly try to explain the idea.

Right now we are making the concept of the Host ID (HI) and the Host Identity Tag (HIT) (the IPv6-like identity that is visible to most applications) more flexible in HIPv2[1]. This change, which originally aimed at providing improved crypto agility, can be used to create a kind of non cryptographic HITs that are bound to HIs via certificates instead of using simple hashing. Such HIs/HITs could be used in scenarios which require more sophisticated identity management while traditional HIs/HITs could be used in scenarios that can live with simpler approaches. 

Let me illustrate this with a little bit of ascii art. I'll use the following abbreviations and notations to keep the lines short:
I enumerated the mappings in HIP/DEX with m1..m3. The arrows <--mx:mapping_name-- signify the mappings. PK is a public key for a signature algorithm, PKDH is the public key for an ephemeral Diffie Hellman, PKSDH is the public key for a static Diffie Hellman exchange. SK is a symmetric session key. 

Right now we have the following mappings between HIs and the security associations that HIP and DEX set up:

For HIP we have:
HIT <--m1:Hash-- PK(HI) <--m2:Signature-- PKDH <--m3:DH_exchange--SK

AFAIK for DEX it looks like this:
HIT <--m1:truncate-- PKSDH <--m2:DH_exchange--SK

These two or three mappings in HIP/DEX make sure that the session key is related to the HIT.
If one wanted the HIT to be independent of the cryptographic keys, it would be simple to define a new kind of HIT/HI for which the mapping would look like this:

HIT <--m1:hash/truncate-- String <--m2:certificate-- PKSDH <--m3:DH_exchange-- SK

This means that the HIT is generated from an arbitrary string (e.g., node ID, vendor ID, node function or a service name - anything). This string is hashed to get it into IPv6 like form so that it can be used just as the HIT.
The actual Host ID would be a certificate (issued by a trusted third party) that binds this string to a static DH public key. The process of generating a HI could be like this. 1. Pick node string (e.g., "Node222:Temperature sensor"), 2. generate static DH public key, 3. generate certificate covering string and DH public key, 4. give DH public/private key pair and certificate to the node.
This would mean that (provided that there is a trusted third party) one could use descriptive strings in HIP in the same way that cryptographic names are used. The way that applications deal with HITs and the actual HIP handshake would stay almost the same. The only difference is that the peers use the third-party certificates to verify mapping m2.

This is just a first sketch without proper specification. However, adding such certificate-based host identities to HIP shouldn't be hard and won't break anything. René Hummen agreed to provide a draft that fleshes out this approach if CORE or HIPRG/WG deem it interesting.

> BTW (not relevant to authentication topic) - It is not immediately clear whether the "puzzle" presented from responder to initiator (Puzzle is to compute J so that x:=CMAC_I (  Id_A || Id_B || J) has a pre-fixed pattern on K bit positions) does not allow for "shortcuts", thus allowing its solution with expenditure of far less than 2^K trial-and-error computing rounds. Can't one do a meet-in-the-middle type of attack here? Anyway, not directly relevant to the authentication question at hand (although perhaps adding to confusion).

I see your point here. If cmac is particularly susceptive to a meet-on-the-middle attack one could slightly modify the puzzle so that instead of requiring a certain length of 0 bits in the beginning of the solution, a match with a random/pseudorandom string is required. The pseudorandom string should not be known to the Initiator before the connection attempt and could be connection specific or could cycle. This would make it hard to precompute the second step of the meet-in-the-middle attack because this step will be different for each puzzle.

> 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?

BR,

Tobias

[1] draft-ietf-hip-rfc5201-bis-02: http://www.ietf.org/id/draft-ietf-hip-rfc5201-bis-02.txt

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Rene Struik <[email-masked]>
Date: Tue, 12 Oct 2010 12:23:55 -0400

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:
>> >  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).
>

---

From: Rene Struik <[email-masked]>
Date: Wed, 27 Oct 2010 11:04:01 -0400

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 intodesign, 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 
notalways 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 
trustenvironments, 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]

On 12/10/2010 12:23 PM, Rene Struik wrote:
> email:[email-masked]
> Skype: rstruik
> cell: +1 (647) 867-5658

---

From: "Garcia Morchon, Oscar" <[email-masked]>
Date: Wed, 27 Oct 2010 18:24:48 +0200

Rene, all,

Rene, I agree with you that a better comparison might be required.
In my view, we might need two "tables":

-          One including a benchmark (may be including scenarios and features)

-          Another with the proposed protocols/procedures/solutions and their corresponding features.
In this way, one might compare both tables, identify advantages/disadvantages, and see which protocols/procedures/solutions are good (enough) for which scenarios.

Regards,

                Oscar.

Features to take into account

Scenario 1

Scenario 2

Scenario 3

Required features for the security handshake

Key establishment

Yes

Yes

?

Implicit key authentication

Yes

Yes

?

Key confirmation

Yes

No

?

Mutual entity authentication

Yes

Yes

?

Forward secrecy

Yes

No needed

?

Key compromise Impersonation resilience

No

No needed

?

... (to be completed)

Platform features

CPU

32-bit CPU

8-bit CPU

?

Bandwidth

Enough

low

?

Energy

Powered

Energy harvesting

?

Flash

128 KB

32 KB

?

... (to be completed)

Lifecycle and operational needs

...

...

(to be completed)

...

...

Bootstrapping

System Operation

HIP

PANA/EAP/...

DTLS

IPSec

HIP

Features

Key establishment

Yes

Implicit key authentication

...

Key confirmation

Mutual entity authentication

Forward secrecy

Key compromise Impersonation resilience

... (to be completed)

Cost

CPU

# of exchanged messages

Size of exchanged information

... (to be completed)

...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Wednesday 27 October 2010 17:04
Cc: core
Subject: [core] concerns re draft-oflynn-core-bootstrapping-02

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

Hi Tobias:

Thanks for your note.

personalization stage?

NIST?

Best regards, Rene

> 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).

--

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

Skype: rstruik

cell: +1 (647) 867-5658

--

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

Skype: rstruik

cell: +1 (647) 867-5658

________________________________
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.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 28 Oct 2010 23:48:41 +0300

Hello,

Ø  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). 

Can you please elaborate on what “mothership” node is.

Alper

 

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). 

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

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). 

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!
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.

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?

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?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2010 23:21:21 +0200

On Oct 28, 2010, at 22:48, Alper Yegin wrote:

> mothership

I think other terms are "mother-may-I", "trust center", "RADIUS server", or "Policy Decision Point".  Just guessing, though.
I think the use case of interest here is a single constrained network that simultaneously serves multiple trust domains, so being authorized by any one of them should give you access.

With that potential explanation, can you elucidate whether (and maybe how) PANA would work in this scenario?

Gruesse, Carsten

---

From: Rene Struik <[email-masked]>
Date: Thu, 28 Oct 2010 17:29:47 -0400

Hi Alper:

With "mothership" I meant to indicate a node that serves as security 
manager for a collection of nodes. There are of course different 
granularities in what the security manager role entails. In ZigBee, the 
mothership node would be "the" trust center.

I hope this helps.

Rene

On 28/10/2010 4:48 PM, Alper Yegin wrote:
>
> Hello,
>
> ØSimilarly, e.g., PANA does not seem to work in heterogeneous 
> mothership node to the next (or, e.g., if one has an authenticator, 
> how to make this work with single-hop/MAC security).
>
> Can you please elaborate on what "mothership" node is.
>
> Alper
>
> Dear colleagues:
>
> guidance intodesign, 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 
> notalways 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 
> mothership node to the next (or, e.g., if one has an authenticator, 
> how to make this work with single-hop/MAC security).
>
> 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
>
> device identifiers (i.e., ****no** entanglement of concepts from 
> different disciplines).
>
>
>     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
>     >  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
> email:[email-masked]  <mailto:[email-masked]>
> Skype: rstruik
> cell: +1 (647) 867-5658

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Oct 2010 08:20:14 +0900

OK, then let me use the term "RADIUS server" to explain.

Any EAP transport protocol such as IEEE 802.1X and PANA works with
multiple AAA domains in which a single access network may interface to
multiple RADIUS servers where each RADIUS server serves for a distinct
AAA domain.  With EAP, RADIUS routing is based on the EAP peer
identity such as "[email-masked]" and "[email-masked]" in a way that
authentication messages for EAP peer "[email-masked]"are routed to
"domainA.com" RADIUS server and authentication messages for EAP peer
"[email-masked]" are routed to "domainB.com" RADIUS server.  The EAP
peer identity is extracted from the initial EAP exchange by an EAP
pass-through authenticator that is co-located with a RADIUS client at
the border of the access network.  In a large scale RADIUS deployment,
there may be RADIUS proxies between a RADIUS client and a RADIUS
server to simplify the AAA routing task for RADIUS clients.  In PANA,
PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
and PaC (PANA Client) is the EAP peer.

Hope this helps,
Yoshihiro Ohba

---

From: Rene Struik <[email-masked]>
Date: Thu, 28 Oct 2010 23:38:20 -0400

Hi Yoshihiro:

It seems that in your example each device identifier is tied to a single 
security manager (e.g., device A and security manager S would yield 
device id [email-masked]).

This seems to imply the following:
(a) entangles the name space and device role space (since tie-ing node A 
to a node S that assumes a security manager role for A);
(b) precludes scenarios where
     (b1) a device may have multiple security managers (example: remote 
control, spare remote under the pillow, central node);
     (b2) a security manager may change over time (example: change of 
security manager, due to malfunctioning device or ownership change);
     (b3) a device may not have a security manager yet (example: device 
is initially taken out of generic box, without any imprinting happening 
yet);
     (b4) a device and security manager may not be in hierarchical 
relationship (example: simple device pairing a la Bluetooth v2.1 EDR).
As such, this seems to preclude many useful deployment scenarios for 
sensor networks.

Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT re 
the latest version of draft-oflynn-core-bootstrapping-02, in which I 
highlighted the importance of facilitating a flexible set of deployment 
scenarios.

Please let me know if I misinterpreted your EAP-style explanation 
(above, I only focus on logical device roles and not on communication 
patterns).

Best regards, Rene

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Oct 2010 16:30:33 +0900

Hello Rene,

Thank you very much for expressing your concerns in detail.

Basically there is no implications such as (a) and (b1) to (b4) in the
general framework of PANA, EAP and AAA.  Let me explain this in
details below..

(2010/10/29 12:38), Rene Struik wrote:
> Hi Yoshihiro:
> 
> It seems that in your example each device identifier is tied to a 
> single security manager (e.g., device A and security manager S would 
> yield device id [email-masked]).
> 
> (a) entangles the name space and device role space (since tie-ing node 
> A to a node S that assumes a security manager role for A);

In the case where the EAP peer identity is tied with the device in
which the EAP peer resides, you are right.  However, the EAP peer
identity is not necessarily tied with the device.  It can be also tied
with the user who uses the device.  Or when a tunneling EAP method
such as EAP-TTLS is used, it is possible to tie the EAP peer identity
for the outer EAP method with the device *and* tie the EAP peer
identity for the inner EAP method with the user.  So in general EAP
framework, there is no fixed binding is assumed between the device and
security manager.

> control, spare remote under the pillow, central node);

When PANA is used, it is possible to have multiple PANA sessions
between a PaC and a PAA, and different EAP peer identities can be used
for those PANA sessions where each EAP peer identity may be tied with
a distinct security manager.  OTOH, this kind of scenario is difficult
to be supported by IEEE 802.1X which allows only one authentication
session between a pair of 802.1X Supplicant and Authenticator.

> security manager, due to malfunctioning device or ownership change);

I think this is basically a provisioning issue.  If a deployment uses
a provisioning mechanism that allows dynamically changing the EAP peer
identity associated with a particular device, it is possible to change
a security manager over time under the EAP framework.

> (b3) a device may not have a security manager yet (example: device is 
> initially taken out of generic box, without any imprinting happening 
> yet);

Again I think this is a provisioning issue.  If a deployment uses a
provisioning mechanism that supports a standalone bootstrapping
mechanism during the provisioning phase, it is possible not to use a
security manager in the provisioning phase.

> As such, this seems to preclude many useful deployment scenarios for 

Since the EAP framework does not require to use the AAA
infrastructure, a P2P relationship can be supported by the EAP framework.

We can clarify these things in the core-bootstrapping draft if it helps.

Best Regards,
Yoshihiro Ohba

> highlighted the importance of facilitating a flexible set of 
> deployment scenarios.
> 
>>> I think other terms are "mother-may-I", "trust center", "RADIUS 
>>> server", or "Policy Decision Point". Just guessing, though.
>>> I think the use case of interest here is a single constrained 
>>> network that simultaneously serves multiple trust domains, so being 
>>> authorized by any one of them should give you access.
>>>
>>> With that potential explanation, can you elucidate whether (and 
>>> maybe how) PANA would work in this scenario?
>>>
>>> Gruesse, Carsten
>>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 29 Oct 2010 08:43:18 -0400

Hi Yoshihiro:

As already expressed, I would really favor a more fundamental approach,
where deployment scenarios, desired operational behaviors, and required
security properties are guideline to the design. Protocol soup acronyms
are nice, but they could obscure what one is really after here (at
least, that is what this does to me).

That is also what I expressed in my email 4 weeks ago (October 1, 2010),
originally in the context of HIP. Unfortunately, most of the analysis is
still missing.

Best regards, Rene
(again in the office Monday)

---

From: Rene Struik <[email-masked]>
Date: Fri, 29 Oct 2010 09:02:23 -0400

Hi Tobias:

It would help to have some more insight into claimed functionality of 
the HIP protocol. We had some correspondence on this over the last 4 
weeks, but unfortunately detail as to claimed security properties, 
distinguishing features w.r.t. other protocols, and, e.g., computational 
benefits over other approaches still seems to be partially lacking (at 
least, to me).  Moreover, I still have trouble to understand how the 
protocol could facilitate separation of device ids and cryptographic 
objects, as seems to be beneficial in deployment scenarios, such as 
large scale manufacturing of sensor nodes.

If you could elaborate and put the issues to rest, that would be great.

For the benefit of easy comprehension, I would suggest a succinct 
description (perhaps, with mathematical description of security-relevant 
portions of the protocol flows, properties, etc?).

I am sending this to the list, since Carsten Bormann is right: the group 
as a whole would benefit from technical discussions.

Best regards, Rene

On 20/10/2010 4:35 PM, Rene Struik wrote:
> Hi Tobias:
>
> If the device's public key and the CA's signature verification key are 
> similar mathematical objects (e.g., both are on the same elliptic 
> curve), then the crypto real estate to perform certificate self-tests 
> can be made to reuse that used to perform key computations with an 
> authenticated key agreement scheme that uses certs. Obviously, this 
> would require the device to have access to an authentic copy of the 
> CA's signature verification key. If the CA's public key is not 
> available, it cannot check its own cert an alternative authentic 
> channel has to be established between the device and an external party 
> who attests to the authenticity of the cert. This being said, I do not 
> know of practical scenarios where the latter limitation arises 
> (usually, one does not accept any cert for which one does not already 
> have a bootstrapped [or not] root CA key).
>
> It seems somewhat dangerous to use certs to bind arbitrary strings to 
> public keys if the semantics of that string is not well-understood or 
> can be defined at will be another process. After all, if the string is 
> StrA and semantics of one application defines this as "temperature 
> sensor A", while another application defines this as "thermometer B", 
> confusion may arise: does (StrA, PublicKey) relate to some physical 
> device A or some physical device B? Not sure how this can be avoided 
> if one does not stipulate that for any semantics one may define, the 
> mapping String --> Globally Unique Device Id is an injection. 
> Intuitively, this seems to suggest that each string contains an object 
> that is 1-1 mappable to this globally unique device id.
>
> Best regards, Rene
>
>
>
> On 20/10/2010 2:37 PM, Tobias Heer wrote:
>> Hi Rene,
>>
>> Am 20.10.2010 um 17:58 schrieb Rene Struik:
>>
>>> Hi Tobias:
>>>
>>> No worries - I am just curious to see how HIP fits in with 
>>> ubiquitous networks of smart objects, why one would care about the 
>>> protocol, and which use cases are enabled. Depending the outcome 
>>> hereof, it may be worth pointing to in IETF drafts etc.
>>>
>>> Some brief comments below (enclosed by RS>>  and<<RS).
>>>
>>> Best regards, Rene
>>>
>>> On 20/10/2010 11:31 AM, Tobias Heer wrote:
>>>> Hi Rene,
>>>>
>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the 
>>>> quick questions immediately and will come back with a more detailed 
>>>> and better specified description in a couple of days. Actually René 
>>>> Hummen might respond instead of me.
>>>>
>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik:
>>>>
>>>>> Hi Tobias, Zhen:
>>>>>
>>>>> I would be indebted if you could provide some feedback on my email 
>>>>> as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. 
>>>>> below).
>>>>>
>>>>> Best regards, Rene
>>>>>
>>>>>> 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?
>>>> a) yes it would
>>>> b) yes, the node could generate the static DH key by itself and 
>>>> acquire a certificate for this key (e.g., at deployment time)
>>>> c) I am not completely sure what you mean with "different process" 
>>>> and "return" however, I can outline the possible flexibility that 
>>>> one would have:
>>>>
>>> RS>>
>>> Setting would be where one would register a pair (Device Id, Public 
>>> key) during production, ship a database of these pairs to a CA, have 
>>> the latter generating a certificate for (Device Id, Public key) 
>>> pairs of its choosing and tie this to associated keying material 
>>> (such as policy field, validity period, and the-like). Certificates 
>>> themselves could then find a way back to a device via any other 
>>> communication channel (does not require online/inline involvement of 
>>> CA and could, e.g., by provided when personalized in a BestBuy shop, 
>>> using a BestBuy CA (note that BestBuy CA would then have to relie on 
>>> the RA used during production - the one that collected the database).
>>> <<RS
>>>> (I am taking about DEX now, not HIP BEX)
>>>>
>>>> i)   The static DH key can either be node-generated or imprinted by 
>>>> some entity (in a secure environment)
>>>> ii)  The certificate can either be imprinted when the node is 
>>>> manufactured or it can be imprinted later (again, in a secure 
>>>> environment)
>>> RS>>
>>> Not sure why imprinting of certificate (authorization of state 
>>> change aside) would need to be done in secured environment in 
>>> general, since this is public piece of information.
>>> <<RS
>> Sure, the information is public but nodes that cannot verify their 
>> own certificate (I do not assume that all nodes are able to verify 
>> digital signatures. However, I am not sure if it is useful to assume 
>> that a host supports ECDH but not ECDSA) might accept an invalid 
>> certificate and could, from that moment on, not authenticate towards 
>> a legitimate host anymore. The secure environment is not needed if a) 
>> a node can verify its own certificate or b) if the node can verify 
>> the identity of the device that imprints the certificate.
>>
>>>> iii) The certificate could be renewed at any time (provided there 
>>>> is a secure mechanism for that)
>>>> iv)  The DH public key could be renewed as well (at any time), 
>>>> however, a node would require a new certificate, authenticating the 
>>>> new DH key then
>>>>
>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the node 
>>>> instead of the static DH public key. Hence, the ephemeral DH key 
>>>> would change more often while the ECDSA public key would be in the 
>>>> certificate.
>>>>
>>> RS>>
>>> I still have some trouble understanding how identifying nodes by 
>>> their public key is going to satisfy use case scenarios where one 
>>> may have changes to the public key, different certificates, and 
>>> the-like. Please note that the objective of certificates is to 
>>> provide for a secure binding between a device's id and its private 
>>> key (via the corresponding public key), thus freeing one to just use 
>>> device ids -- after all, certificate processing would then yield the 
>>> corresponding public key(s) purportedly owned by that device.
>>> <<RS
>> The certificate would bind a string to the public key (static DH or 
>> RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP 
>> maps the string to the static public key of the peer in the BEX by 
>> using the certificate that the peer provides. A device is therefore 
>> identified by a string not a public key (as in vanilla HIP).
>>
>>>>>> 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?
>>>> I'll let René Hummen respond to this question.
>>>>
>>> RS>>
>>> Sure - looking forward to this. This would be easy to compare, once 
>>> one has succinct description of the cryptographic aspects of the 
>>> protocol (so that, e.g., one can count the number of scalar point 
>>> multiplications involved, etc.).
>>> <<RS
>>>>>> 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.)
>>>> I am still somewhat unsure about cost and capabilities of the 
>>>> targeted devices. Depending on who you talk to, people seem to 
>>>> expect sensors that are capable of ECC crypto, barely capable or 
>>>> not capable at all.
>>>> Are there minimal hardware specs for target devices?
>>>>
>>> RS>>
>>> Almost all 802.15.4-based modules have hardware support for AES-128 
>>> (in forward mode). Since the MAC layer requires error detection 
>>> using CRC-16 linear feedback shift regsiter circuits (which is a no 
>>> brainer) and since, e.g., elliptic curves over binary extension 
>>> fields can be realized using shift registers that are of order of 
>>> magnitude anything up to 256 registers, I do not see a problem for 
>>> hardware support here (once implemented in large scale environments).
>>>
>>> Source: http://2010.eccworkshop.org/
>>> Junfeng Fan<http://homes.esat.kuleuven.be/%7Ejfan/>(K.U.Leuven, 
>>> Belgium)
>>> /ECC on constrained devices/
>>> The embedded security community has been looking at the ECC ever 
>>> since it was introduced. Hardware designers are now challenged by 
>>> limited area (<15k Gates), low power budget (<100uw) and 
>>> sophisticated physical attacks. This talk will report the 
>>> state-of-the-art ECC implementations for ultra-constrained devices. 
>>> We take a passive RFID tag as our potential target. We will discuss 
>>> the known techniques to realize ECC on such kind of devices, and 
>>> what are the challenges we face now and in the near future.
>>> <<RS
>> Impressive. I'll certainly give it a closer look.
>>
>> Tobias
>>
>
>

---

From: Tobias Heer <[email-masked]>
Date: Fri, 29 Oct 2010 17:14:14 +0200

Hello Rene,

thanks for picking this up again.

First, one has to distinguish HIP and DEX (as proposed by Robert). HIP is (as defined in 5201) the base protocol and DEX would be the trimmed down variant for resource constrained scenarios. However, the DEX is certainly still WIP and can probably be bent in one or the other direction (if needed). I am not an author of the DEX and I somehow ended up mandating HIP here although CoRE is certainly not my primary field of work. Hence, I'd like to state that my intention is not to claim that HIP is the best protocol for CoRE. I simply don't know CoRE well enough to make such statement. However, I can try to answer some questions related to HIP so that CoRE WG can make a sound decision on whether HIP is something to consider or if it isn't.

Am 29.10.2010 um 15:02 schrieb Rene Struik:

> Hi Tobias:
> 
> It would help to have some more insight into claimed functionality of the HIP protocol. We had some correspondence on this over the last 4 weeks, but unfortunately detail as to claimed security properties,

I) Which specific security properties are unclear to you? Maybe we can narrow things down a bit. Otherwise I might end up repeating the whole protocol as described in RFC5201 here.

> distinguishing features w.r.t. other protocols,

II) Distinguishing features of HIP are (in my opinion):

On a conceptual level:
  a) the implementation of the locator/identifier split, 

  b) the quite flexible protocol design (emphasis on extendability - many people have successfully used HIP for quite different scenarios by extending and modifying the base protocol without breaking compatibility),

  c) the identity-focused namespace based on cryptographic identities,

  d) its integration within the stack. Upper layers just use HITs like IPv6 addresses and HIP takes care of establishing and maintaining an authenticated and encrypted channel to the other host.  

Features on a more technical level are:
  e) A 4-way handshake that includes authentication of both peers, generation of a shared secret and set-up of an encrypted payload channel. Depending on the scenario, this four-way handshake might be better than, e.g., the multi-packet flight-based exchange of DTLS that sends more packets. However, I am aware that HIP needs optimizations in the form of DEX to avoid fragmentation and DTLS could probably be modified to avoid multi-packet flights.

  f) DoS prevention: HIP implements two different mechanisms here: return routability checks and puzzles. However, depending on the scenario, these may be applicable or may be not applicable for CoRE. I'd be happy to discuss this.

All aforementioned points (a-f) are valid for HIP and DEX.
I will gladly give a more detailed explanation of these points if you wish - just tell me which requires further elaboration.

> computational benefits over other approaches

HIP uses an authenticated Diffie Hellman key exchange. In terms of public key operations, it does:

2 public key verifications at the Initiator side
1 public key verification at the Responder side
1 public key signature at the Initiator side
1 public key signature at the Responder side
1 offline public key signature at the Responder side
1 DH shared key generation at the Initiator side
1 DH shared key generation at the Responder side

This is certainly not an optimal design for tightly resource constrained devices. Hence, Robert tried to reduce the number of computations needed without changing the way HIP works.
DEX (as proposed by Robert) uses a static Diffie Hellman key exchange and amounts to:

1 DH shared key generation at the Initiator side
1 DH shared key generation at the Responder side

The actual cost of these operations depends on the chosen DH groups/ ECC curves but the set algorithms is interchangeable and can be adopted to the needs of the scenario.

The aforementioned numbers don't reflect the cost of the use of an additional third-party certificate (which I believe you would like to see in a handshake). Hence, certificate verification at the sender or receiver should be added to the cost if the scenario demands it.

I hope this gives you a rough feeling for the cryptographic cost of running HIP/DEX.

> Moreover, I still have trouble to understand how the protocol could facilitate separation of device ids and cryptographic objects, as seems to be beneficial in deployment scenarios, such as large scale manufacturing of sensor nodes.

René Hummen is currently preparing a draft on the solution that I mentioned in my previous mail. I hope he is done before or shortly after Beijing. I hope this document will answer your questions.

> If you could elaborate and put the issues to rest, that would be great.
Sure. I hope the explanations above shed some light on the open questions regarding HIP. I tried to put each argument/point to a new line to make it easy for you to indicate which you would like to discuss in more detail.

> For the benefit of easy comprehension, I would suggest a succinct description (perhaps, with mathematical description of security-relevant portions of the protocol flows, properties, etc?).
> 
I believe Rene Hummen is preparing this, too. I hope the sum of the cryptographic operations is enough for now to develop a feeling for the cost.

> I am sending this to the list, since Carsten Bormann is right: the group as a whole would benefit from technical discussions.
> 
Sure.

Best regards,

Tobias

>> If the device's public key and the CA's signature verification key are similar mathematical objects (e.g., both are on the same elliptic curve), then the crypto real estate to perform certificate self-tests can be made to reuse that used to perform key computations with an authenticated key agreement scheme that uses certs. Obviously, this would require the device to have access to an authentic copy of the CA's signature verification key. If the CA's public key is not available, it cannot check its own cert an alternative authentic channel has to be established between the device and an external party who attests to the authenticity of the cert. This being said, I do not know of practical scenarios where the latter limitation arises (usually, one does not accept any cert for which one does not already have a bootstrapped [or not] root CA key).
>> 
>> It seems somewhat dangerous to use certs to bind arbitrary strings to public keys if the semantics of that string is not well-understood or can be defined at will be another process. After all, if the string is StrA and semantics of one application defines this as "temperature sensor A", while another application defines this as "thermometer B", confusion may arise: does (StrA, PublicKey) relate to some physical device A or some physical device B? Not sure how this can be avoided if one does not stipulate that for any semantics one may define, the mapping String --> Globally Unique Device Id is an injection. Intuitively, this seems to suggest that each string contains an object that is 1-1 mappable to this globally unique device id.
>> 
>> Best regards, Rene
>> 
>> 
>> 
>>>> No worries - I am just curious to see how HIP fits in with ubiquitous networks of smart objects, why one would care about the protocol, and which use cases are enabled. Depending the outcome hereof, it may be worth pointing to in IETF drafts etc.
>>>> 
>>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the quick questions immediately and will come back with a more detailed and better specified description in a couple of days. Actually René Hummen might respond instead of me.
>>>>> 
>>>>>> I would be indebted if you could provide some feedback on my email as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. below).
>>>>>> 
>>>>>> Best regards, Rene
>>>>>> 
>>>>> b) yes, the node could generate the static DH key by itself and acquire a certificate for this key (e.g., at deployment time)
>>>>> c) I am not completely sure what you mean with "different process" and "return" however, I can outline the possible flexibility that one would have:
>>>>> 
>>>> RS>>
>>>> Setting would be where one would register a pair (Device Id, Public key) during production, ship a database of these pairs to a CA, have the latter generating a certificate for (Device Id, Public key) pairs of its choosing and tie this to associated keying material (such as policy field, validity period, and the-like). Certificates themselves could then find a way back to a device via any other communication channel (does not require online/inline involvement of CA and could, e.g., by provided when personalized in a BestBuy shop, using a BestBuy CA (note that BestBuy CA would then have to relie on the RA used during production - the one that collected the database).
>>>> <<RS
>>>>> i)   The static DH key can either be node-generated or imprinted by some entity (in a secure environment)
>>>>> ii)  The certificate can either be imprinted when the node is manufactured or it can be imprinted later (again, in a secure environment)
>>>> RS>>
>>>> Not sure why imprinting of certificate (authorization of state change aside) would need to be done in secured environment in general, since this is public piece of information.
>>>> <<RS
>>> Sure, the information is public but nodes that cannot verify their own certificate (I do not assume that all nodes are able to verify digital signatures. However, I am not sure if it is useful to assume that a host supports ECDH but not ECDSA) might accept an invalid certificate and could, from that moment on, not authenticate towards a legitimate host anymore. The secure environment is not needed if a) a node can verify its own certificate or b) if the node can verify the identity of the device that imprints the certificate.
>>> 
>>>>> iii) The certificate could be renewed at any time (provided there is a secure mechanism for that)
>>>>> iv)  The DH public key could be renewed as well (at any time), however, a node would require a new certificate, authenticating the new DH key then
>>>>> 
>>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the node instead of the static DH public key. Hence, the ephemeral DH key would change more often while the ECDSA public key would be in the certificate.
>>>>> 
>>>> RS>>
>>>> I still have some trouble understanding how identifying nodes by their public key is going to satisfy use case scenarios where one may have changes to the public key, different certificates, and the-like. Please note that the objective of certificates is to provide for a secure binding between a device's id and its private key (via the corresponding public key), thus freeing one to just use device ids -- after all, certificate processing would then yield the corresponding public key(s) purportedly owned by that device.
>>>> <<RS
>>> The certificate would bind a string to the public key (static DH or RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP maps the string to the static public key of the peer in the BEX by using the certificate that the peer provides. A device is therefore identified by a string not a public key (as in vanilla HIP).
>>> 
>>>> Sure - looking forward to this. This would be easy to compare, once one has succinct description of the cryptographic aspects of the protocol (so that, e.g., one can count the number of scalar point multiplications involved, etc.).
>>>> <<RS
>>>>> I am still somewhat unsure about cost and capabilities of the targeted devices. Depending on who you talk to, people seem to expect sensors that are capable of ECC crypto, barely capable or not capable at all.
>>>> Almost all 802.15.4-based modules have hardware support for AES-128 (in forward mode). Since the MAC layer requires error detection using CRC-16 linear feedback shift regsiter circuits (which is a no brainer) and since, e.g., elliptic curves over binary extension fields can be realized using shift registers that are of order of magnitude anything up to 256 registers, I do not see a problem for hardware support here (once implemented in large scale environments).
>>>> 
>>>> Junfeng Fan<http://homes.esat.kuleuven.be/%7Ejfan/>(K.U.Leuven, Belgium)
>>>> The embedded security community has been looking at the ECC ever since it was introduced. Hardware designers are now challenged by limited area (<15k Gates), low power budget (<100uw) and sophisticated physical attacks. This talk will report the state-of-the-art ECC implementations for ultra-constrained devices. We take a passive RFID tag as our potential target. We will discuss the known techniques to realize ECC on such kind of devices, and what are the challenges we face now and in the near future.
>>>> <<RS