Subject: Re: [core] HIP identities and puzzle

From: René Hummen <[email-masked]>
Date: Tue, 02 Nov 2010 19:16:56 +0100

Hello Rene,

please see my comments below.

On 29.10.2010, at 17:14, Tobias Heer wrote:
> 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.

As Tobias mentioned, I'm currently working on a draft about a certificate-based namespace for HIP. However, as I just started it recently, it might well take until after Beijing.

>> 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'm not an author of the DEX draft myself, but I already discussed with Robert about the protocol and I'm very interested in the topic. That said, these are my thoughts and findings on HIP and DEX.

HIP and DEX both have - as Tobias pointed out before - a 4 way handshake. The initial packet (I1) triggers the handshake and does not contain any cryptographic mechanisms. I'll now go through the packet exchange of both protocols focusing on the remaining packets R1, I2 and R2 and describe the respective cryptographic portions. Note that Rx (i.e. R1 and R2) denotes a packet sent by the responder, whereas Ix (i.e. I1 and I2) represents a packet sent by the initiator. 

HIP:
------

	Initiator								Responder

			I1
			------------------------------------>

										Create eph. DH key pair: x, g^x

                  	R1: ID_R, g^x,  SIGN(ID_R, R1)
			<------------------------------------

VER_SIG(ID_R, R1)
Create eph. DH key pair: y, g^y
DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input
Derive shared secret from DH KEYMAT: s

			I2: ID_I, g^y, HMAC(s, I2), SIGN(ID_I, I2)
                	------------------------------------>

										VER_SIG(ID_I, I2)
										DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input
										Derive shared secret from DH KEYMAT: s
										HMAC(s, I2)

			R2: HMAC(s, R2), SIGN(ID_R, R2)
			<------------------------------------

HMAC(s, R2)
VER_SIG(ID_R, R2)

* The HMAC-based Key Derivation Function (HKDF) is defined in RFC5869.

ID_x represent the public key of the respective host. SIGN and VER_SIG use the private key as first parameter and the message as second input. Their cost of depend on the signature algorithm in use. HIP supports RSA, DSA and ECDSA. Likewise, HIP supports both classical DH and ECDH.

DEX:
-------

	Initiator								Responder

			I1
			------------------------------------>

										Existing static DH key pair: x, [ID_R =] g^x

			R1: ID_R
			<------------------------------------

Existing static DH key pair: y, [ID_I =] g^y
DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input
Derive master key from DH: k
Draw random secret: s_I

			I2: ID_I, ECR(k, s_I), CMAC(k, I2)
			------------------------------------>

										DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input
										Derive master key from DH: k
										Verify CMAC(k, I2)
										s_I = DCR(k, s_I)
										Draw random secret: s_R
										Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I | s_R as input

			R2: PK, ECR(k, s_R), CMAC(k, R2)
			<------------------------------------

Verify CMAC(k, R2)
s_I = DCR(k, s_I)
Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I | s_R as input

* Section 6.3 of draft-moskowitz-hip-rg-dex-02 explains how key material generation works in detail.
** The pair-wise key is used in DEX for the payload protection protocol. 

ECR and DCR denote encryption and decryption functions (preferably AES in the CoRE scenario) with the symmetric key as first input and the plain-text as second input parameter. Furthermore, the DEX draft does not provide signing functionality at the moment. However, I believe that this can still be changed according to the needs of the community.

I have left out performance optimizations and DoS protection mechanisms in my descriptions (e.g. R1 pre-creation and puzzle) for the sake of clarity. I hope that this description provides the kind of information you are looking for. Note that PK-based authentication and DH key derivation are two separate mechanisms with HIP and are not integrated in a similar way as for HMQV.

Please let me know, if you need more specific information on one of the mechanisms or the packet exchange I talked about above.

BR,
René

>> 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
> 
> 
> 
>> 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
>>>>>>> 
>>>>>>> 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?
>>>>>> 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
>>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> email: [email-masked]
>> Skype: rstruik
>> cell: +1 (647) 867-5658
>> USA Google voice: +1 (415) 690-7363
>> 
> 
> 
> 
> 
> -- 
> 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
> 
> 
> 
> 
> 
> 
> 

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 7 Nov 2010 18:51:42 +0200

Sorry about the late response.

I'm still not 100% sure I understand the question/issue, but let me say the
following and see if it helps.

PAA is located on a node that acts as NAS (Network Access Server). If there
are nodes with different trust anchors that need to be authenticated, NAS
would be in charge of contacting the individual trust anchors for each
authentication procedure. For example, NAS could be using RADIUS for talking
with those trust anchors. PANA has nothing to do with that part. Please see
RFC 5193 to see how these protocols come together to form a generic
architecture.

If the NAS can act as the trust anchor (because it holds the credential
database, or using public key certificates [and does not care about OCSP/CRL
??]), then it can be offline. But, again, this has nothing to do with PANA.
PANA gets EAP packets back and forth between the joining node and NAS. How
NAS performs authentication (whether by itself, or offloads to a AAA server)
is invisible to PANA.

.

I didn't understand the issue about "move from one mothership to the next"
at all to comment on it.

Regards,

Alper

 

 

From: Rene Struik [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 12:30 AM
To: Alper Yegin
Cc: 'core'
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02

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

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

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?

---

From: Robert Cragie <[email-masked]>
Date: Sun, 07 Nov 2010 20:44:24 +0000

Hi Alper,

With regard to the 'mothership', what Rene is referring to is exactly 
the reason for introducing the PRE element in the ZigBee IP/6lowpan 
scenario where the authenticator/PAA is not in direct contact with a 
peer/PaC.

<----- PANA ----><---- AAA ---->
|-----|   |-----|        |-----|
| Pac |---| PAA |---//---| TrA |
|-----|   |-----|        |-----|
             AP            Backend server
             NAS

The onlink case is shown as above, where, for example, the NAS would be 
a 802.11 access point. However, in the ZigBee IP/6lowpan case, it could 
be more complex:

<---------- PANA ---------><---- AAA ---->
|-----|   |-----|   |-----|        |-----|
| Pac |---| PRE |---| PAA |---//---| TrA |
|-----|   |-----|   |-----|        |-----|
6LR/H       6LR       6LBR Backend server
                       NAS
So the introduction of the relay element (PRE) allows for this 
separation. Does that cover your point, Rene?

With regard to Rene's other point, I think you have that covered and I 
have shown that above as the AAA protocol between authenticator and 
backend server.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 07/11/2010 4:51 PM, Alper Yegin wrote:
> I'm still not 100% sure I understand the question/issue, but let me 
> say the following and see if it helps.
>
> PAA is located on a node that acts as NAS (Network Access Server). If 
> there are nodes with different trust anchors that need to be 
> authenticated, NAS would be in charge of contacting the individual 
> trust anchors for each authentication procedure. For example, NAS 
> could be using RADIUS for talking with those trust anchors. PANA has 
> nothing to do with that part. Please see RFC 5193 to see how these 
> protocols come together to form a generic architecture.
>
> If the NAS can act as the trust anchor (because it holds the 
> credential database, or using public key certificates [and does not 
> care about OCSP/CRL ??]), then it can be offline. But, again, this has 
> nothing to do with PANA. PANA gets EAP packets back and forth between 
> the joining node and NAS. How NAS performs authentication (whether by 
> itself, or offloads to a AAA server) is invisible to PANA.
>
> ...
>
> I didn't understand the issue about "move from one mothership to the 
> next" at all to comment on it.
>
> Regards,
>
> Alper
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* Friday, October 29, 2010 12:30 AM
> *To:* Alper Yegin
> *Cc:* 'core'
> *Subject:* Re: [core] concerns re draft-oflynn-core-bootstrapping-02
>
> 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
>
> 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).
>
>
> (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):
>
> 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).
>
> 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
>
> (c) key confirmation; (d) mutual entity authentication; (e) forward 
> secrecy; (f) {perhaps} some more esoteric properties (key compromise 
> device identifiers (i.e., ****no** entanglement of concepts from 
> different disciplines).
>
>
> It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
> 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
> 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
>     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
> 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
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Rene Struik <[email-masked]>
Date: Wed, 10 Nov 2010 09:08:43 -0500

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:
>>> 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]
>> Skype: rstruik
>> cell: +1 (647) 867-5658
> email:[email-masked]
> Skype: rstruik
> cell: +1 (647) 867-5658

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Nov 2010 17:53:29 -0800 (PST)

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:
>
>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.
>
>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.
>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.
>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.
>entirely unclear. Moreover entanglement of name space and crypto     space is 
>still an issue. Most questions posed over the last month     resulted in 
>efficiencies, disentanglement as work-of-progress     items for next version of 
>HI/HIP-DEX. In my mind, this indicates     immaturity and (for now) 
>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.
>
>>guidance intodesign, so as to have as very       minimal benchmark whether all 
>>mind. To me, it seems       to have merit to discuss the whole spectrum and end 
>>up with       cryptographic building blocks, security protocols, and security       
>>(since, in my mind, this pushes into a particular direction,       and notalways        
>>cryptographically generated addresses (802.1-like) would fit       in.Similarly,        
>>e.g., PANA does not seem to work in heterogeneous trustenvironments,        
>>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
>>
>>key confirmation; (d) mutual entity       authentication; (e) forward secrecy; 
>>(f) {perhaps} some more       esoteric properties (key compromise impersonation 
>>resilience,       etc.). 
>>
>>
>>>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); 
>>>
>>>outputting its node id and public key (e.g., during chip testing -- this would 
>>>
>>>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" 
>>>
>>>public-key crypto constructs. However, from a user's perspective, the only thing 
>>>that
>>>It would help to have a succinct mathematical description of the protocol you 
>>>suggest (stripped from formatting issues) and describe claimed cryptographic
>>>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
>>>
>>>
>>>the HIP protocol itself, so that this is easy to understand, and could provide 
>>>what properties it has, that would be of great help!
>>>(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) 
>>>{perhaps} some more esoteric properties (key compromise 
>>>
>>>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 
>>>
>>>> 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 
 
Does the "*no* entanglement of concepts from different disciplines" also mean 
that a concept like the id/loc split should be used to avoid 

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!
>>>should include (a) key establishment; (b) implicit key authentication; (c) key 
>>>confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) 
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] Skype: rstruik cell: +1 (647) 867-5658 USA Google 
voice: +1 (415) 690-7363
>
>
>-- 
>email: [email-masked] Skype: rstruik cell: +1 (647) 867-5658 USA Google 
>voice: +1 (415) 690-7363

-- 
email: [email-masked] Skype: rstruik cell: +1 (647) 867-5658 USA Google 
voice: +1 (415) 690-7363

---

From: Robert Cragie <[email-masked]>
Date: Thu, 11 Nov 2010 03:25:26 +0000

Hi Rene,

Comments inline, bracketed by <RCC></RCC>

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 10/11/2010 2:08 PM, Rene Struik wrote:
> 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 
> 1) Detailed analysis of deployment scenarios is still missing (since 
> no changes to Appendix A - examples).
<RCC>We discussed this yesterday. Whilst it may be beneficial to have an 
extensive list of use cases, in practice it would take a very long time 
to document use cases for all the possible systems CoAP could be used 
in. The aim in the document is to develop a generic bootstrapping 
architecture which should apply to the majority of use cases based on 
applying to a more limited set.</RCC>
> 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.
<RCC>Was this list posted to the reflector? I can only see one e-mail 
from you on 29th September and that doesn't comprise a list</RCC>
> 3) Consideration for security policies and trust management aspects is 
<RCC>That's rather vague - please elaborate</RCC>
> 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 
> 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.
<RCC>Firstly, various means ">1". Secondly, it is not clear that theses 
identities need to be bound to each other or the context in which they 
are used. This does need clarifiying</RCC>
> move from one to the next while maintaining part of its state.
<RCC>I don't think that is the intention of the text. There is 
separation of administrative domains from access networks here. 
Resource-constrained single interface devices are unlikely to be part of 
more than one network at a time but they may move between networks. 
However these devices may be registered in more than one administrative 
domain whilst part of a network.</RCC>
> 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.
<RCC>What is the basis for your claim regarding online connectivity (no 
reference given)? With regard to initial authentication, all models I am 
aware of assume an authentication server somewhere in the network, 
whether local or further afield. This may not be a fixed static node 
forever but something has to provide this function.</RCC>
> 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.
<RCC>The first paragraph tells you what PANA accomplishes - it is an EAP 
transport (lower layer) over UDP. I am not sure there is much more to be 
said there. I agree with you regarding references to C12.22; these seem 
unnecessary seeing as the standard is not freely available either (i.e. 
costs money). Again, please elaborate what you mean regarding the 
abstract concepts of 'security framework', 'design philosphy', 'security 
policy' and 'trust management framework' in this context.</RCC>
> 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.
<RCC>I too have reservations about HIP especially in view of perfectly 
acceptable and widely-used protocol alternatives. Neverthless, if the 
concerns can be addressed, I think the HIP authors should be given the 
opportunity to do so.</RCC>
> 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.
<RCC>I agree they need be placed into context along with the rest of the 
security. Perhaps this is what you mean by security framework.</RCC>
>> 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.
>>
>> 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, 
>> 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).
>>
>> "separation of concern" and no entanglement of concepts from 
>> different disciplines in the document.
>>
>> 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).
>>
>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Nov 2010 13:02:46 +0900

(2010/11/10 23:08), Rene Struik wrote:

(snip)

> policy and trust management framework is.

W.r.t, C12.22, the protocol is referred as an example protocol that is
used by resource-constrained devices and does not have a dynamic
keying mechanism.  To bootstrap such a protocol, out-of-band protocol
is needed to dynamically generate keys used by the protocol.  If there
is an IETF protocol that is used by resource-constrained devices and
does not have a dynamic keying mechanism, we can replace reference to
C12.22 with such an IETF protocol.

Yoshihiro Ohba