Subject: [Roll] notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)

From: Rene Struik <[email-masked]>
Date: Thu, 13 Oct 2011 17:48:16 -0400

Dear Roger, Tzeta:

Please find below some notes on your AMIKey draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).

I made the assumption that cryptographic protection is based on a
nonce-based cryptographic mode of operation and that replay protection
would be provided (thus, necessitating each receiving device to keep
some nonce state on sending devices). While AMIKey could have
applications that would not require a nonce-based mechanism and replay
protection, this seems a fair assumption (and holds for RoLL-based
cryptographic protection).

As suggested previously, some of my notes have more to do with MIKey
(RFC 3830), so it seems, than with AMIKey. However, some have to do with
implicit assumptions on what basic functionality devices have on board.

Please feel free to discuss.

Best regards, Rene

==

1) Notion of time
Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that
one assumes devices have a notion of time, e.g., to be used to detect
replays/duplicates, and correlate messages with the corresponding
acknowledgement. With RoLL, this notion of time is not a given.
Moreover, this begs the question as to what to do if time notions
between devices are out-of-synch. Does the MIKey specification cater to
this?

Additional note:
-Section 5.2, first para: this seems to suggest a mandatory timestamp.
Not sure what the granularity is with MIKey (important, since not to be
reused) and how this time stamp would be managed.
-Section 6.14, 2nd para: here, key validity periods are specified (KV),
thus requiring a sufficiently accurate shared notion of time (for, if
not, any time check may be unreliable or futile).

2) Key dependencies
It seems that MIKey defines a deterministic mapping between key
encryption keys (TGK) and session keys (TEK). As a result, inadvertent
key exposure of the TGK key will expose all derived keys as well. This
may be undesirable, e.g., if TGK is shared amongst many devices and one
of those devices gets compromised. If session keys would be generated at
random and transported over a secure per-device-pair channel instead,
the impact of compromise of a single node seems more limited. Moreover,
it seems to be preferable to have a logical separation between keys
(e.g., in the event of ownership transfer of a single node or
replacement of a malfunctioning single node).

Additional note:
-From Section 2 (AMIKey overview, para below Fig. 2) it is unclear
whether the TEK is used directly as cryptographic key with, e.g., RoLL,
or whether one derives additional keying material from this.
-Section 6.16 (Key Index payload): this may benefit from some more
explanation.

3) Key identification
With RoLL, the pair (key source identifier, key index) indicates both
the originator of the key ("key source id") and an index ("key index")
of keys issued by this key originator. This does not necessarily imply,
though, that keys are correlated, as is suggested in Section 1.4. (It
seems that KeySourceId identifies a TGK, while KeyIndex identifies a
parameter so as to allow computation of TEK=f(TGK,#)). If this
interpretation is correct, this leads to key dependencies that may be
undesirable, e.g., in the event of key compromise.

4) Challenge response protocol
I am somewhat concerned about some of the message flows with MIKey
(e.g., Section 3, 3rd para, Fig. 3), since a key request could arise,
e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that
one does not have the proper key; for nonces, that one has lost this
value). With MIKey PSK flows, this would result (in the context of RPL)
that one cannot adequately secure the first message Q_MESSAGE, thereby
aborting the protocol. Simply put, what does one do if keys are lost or
if nonces are out of synch? Moreover, the message flows do not seem to
provide for timeliness (in other words: how does entity I know that the
request by entity R is "fresh")?

In out-of-synch scenarios, it seems better to employ a proper
challenge/response protocol (unilateral entity authentication), where
the key requestor sends a random challenge to the key assignment
initiator and where the response messsage includes a protected version
of the requested key and incorporates this random value. This results in
implicit key authentication (only the requestor can recover the key
[assuming both entities have a shared key]) and provides logical binding
between message flows without dependency on nonces.

NOTE RS: with RoLL, this may cause some trouble, since this suggests
mixing of unsecured and secured traffic in the network (which, vaguely,
seems to be forbidden using the "security mode"). Since with RoLL, the
security mode and the security level seems to be unduly tied together,
this may result in the security mode toggling between unsecured and
secured once such a C/R protocol would get implemented.

5) Timeliness/ logical binding in protocol flows
It is not entirely clear how the MIKey protocol provides for logical
binding between protocol flows. As already mentioned, this may be a
problem with the protocol flows in Fig. 3 (key request), but also with
subsequent detailed protocol flows (such as with Fig. 5, using the PSK
method).

Additional note:
-Section 3.1, 2nd last para: doesn't this impact the resulting properties?

6) Public key usage:
The MIKEY protocol seems to use the same public key both for signing and
for encryption. It is unclear in abstracto whether this poses problems,
but common practice is to separate public keys for different
cryptographic purposes. If this practice is heeded to, this requires the
use of two public keys per device (including management hereof).

Additional note:
-Section 3.2, forelast para: wouldn't this impact freshness and
aliveness properties?
-Section 3.2 vs. 3.3: What is the rationale for making public key
encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3)
optional? To me, it seems that use of public key techniques may
significantly simplify configuration management (since this now depends
on juggling publicly available information, rather than handling of
secret keying material). Of those techniques, DH-based protocols seem to
be best suited for highly constrained networks, where energy cost and
implementation footprint come at a premium. Moreover, these may also be
more resistant to side channel attacks (not trivial, esp. for devices
that can be expected to be low-cost, consumer-style devices that may not
be able to rely on tamper-evidencing techniques). This suggests that
public-key based techniques, rather than symmetric-key based techniques
(with proper eye for detail, of course) should be mandatory to implement.

7) Hash function
The suggested "hash function" (Section 4.1.2 - use of CMAC) may be
somewhat unfortunate, since it is invertible if one has access to the
key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based
hashes, such as AES-MMO, as ZigBee SE1.x used). This may have
implications in the event of key compromise.

8) Key management fit
[as already noted by others] Overarching question may be whether key
management functionality best fits with RoLL, CoRE, etc. Of course, this
a perennial question. Nevertheless, some of the functionality described
seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e),
since RoLL may not know about application layers, etc.

9) Other notes
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.
-Section 4.1.2: not sure what the AES-CMAC alignment remark is about.
BTW - this seems to suggest one can mix usage of CMAC with that of CCM
with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para
of Section 6.2). In my opinion, this may be highly dangerous. As case in
point, with the development of 802.15.4-2003, the same mixing was
suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I
can send you my presentation at the time [Nov 2002]).
-Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With
RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover,
the structure of the nonce matters, since it is aimed at preventing
nonce reuse by a single sender/amongst different senders sharing the
same key.
-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
rather than provide a number.
-Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather
than a 48-bit address). Not sure how the reference to RFC 4291 comes
into play here.
-Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why
not use CCM instead (it provides various combinations of encryption and
authentication, including authentication-only).

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

---

From: Rene Struik <[email-masked]>
Date: Fri, 14 Oct 2011 09:46:47 -0400

[resend]

-------- Original Message --------
Subject: 	notes re AMiKey draft
(draft-alexander-roll-amikey-lln-key-mgmt-02)
Date: 	Thu, 13 Oct 2011 17:48:16 -0400
From: 	Rene Struik <[email-masked]>
To: 	Alexander, Roger <[email-masked]>, Tsao,
Tzeta <[email-masked]>
CC: 	[email-masked]

Dear Roger, Tzeta:

Best regards, Rene

==

1) Notion of time

Additional note:

2) Key dependencies

Additional note:

3) Key identification

Additional note:

6) Public key usage:

Additional note:

7) Hash function

8) Key management fit

9) Other notes

---

From: "Alexander, Roger" <[email-masked]>
Date: Fri, 14 Oct 2011 16:13:23 -0400

Hi Rene,

Thank you very much for the detailed review and comments. Please see
responses below.

AMIKEY is of course a separate key management application intended to
provide the out-of-band key management specification called for to
support RPL 'Authenticated' mode security (see RPL, Section 3.2.3). It
is thus intended to support the long-term updating/re-keying of the
group key used to provide routing security among RPL peers. 

Thanks again.

Best regards,

Roger

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rene Struik
Sent: Friday, October 14, 2011 9:47 AM
To: [email-masked]
Subject: [Roll] notes re AMiKey
draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

[resend]

-------- Original Message -------- 

Subject: 

notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date: 

Thu, 13 Oct 2011 17:48:16 -0400

From: 

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

To: 

Alexander, Roger <[email-masked]>
<mailto:[email-masked]> , Tsao, Tzeta
<[email-masked]>
<mailto:[email-masked]> 

CC: 

[email-masked]

Dear Roger, Tzeta:

I made the assumption that cryptographic protection is based on a
nonce-based cryptographic mode of operation and that replay protection
would be provided (thus, necessitating each receiving device to keep
some nonce state on sending devices). 

>>[RA] Correct. MIKEY does discuss the state information required (see
Section 5.4). The required state maintenance is of course simplified
where system-wide time is available though a Counter can also be used
and is part of the specification. Note that in the specific case of RPL
key management, state information is required only between the RPL node
and the key server entity.

While AMIKey could have

>>[RA] Agreed.

>>[RA] Understood but useful to clarify since it is the base for AMIKEY.

Best regards, Rene
 
==
 
1) Notion of time

>>[RA] Yes for MIKEY there is a notion of system time but an optional
Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY
(See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter
is to be made mandatory, while Timestamp is optional (consistent with
RPL). 

See Section 5.4 of RFC3830 for a good discussion of the issue regarding
the tradeoff of state maintenance (replay cache) versus degree of time
synchronization to be maintained. 

Additional note:

>>[RA] This should read "Timestamp [payload]" where as specified in
RFC3830 the Timestamp payload can be a Timestamp or Counter value.

>>[RA] The granularity as given for NTP (32-bit fractional second).
Devices would increment to their degree of supported system time
synchronization.

>>[RA] Only applicable where system time is supported. The validity
period can be defined by an Interval (Valid From and Valid To) that can
be referenced to the Timestamp of the key assignment message. The
granularity in the triggering of key updates will depend on the system
time accuracy supported.    

2) Key dependencies

>>[RA] Yes there is a deterministic mapping between the TEK generating
key (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs
only applies where required for simultaneous assignment or update of
related keys, as applicable for example in the multimedia domain for
voice video, etc. For RPL the RPL routing group key (TEK) would be the
only key derived from the assigned TGK. 

Additional note:

>>[RA] The TEK is the security key that will be assigned (derived from
the TGK) by the RPL Key Server for use in securing the routing exchanges
between the RPL peers. Some further clarifications can be made to ensure
that this is better understood. As in other sections, the intent will be
to use RPL-specific examples throughout while maintaining the protocol's
more general application. 

3) Key identification

>>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section
10.1, RPL uses a shared group key assigned by a network Key Server
(where pre-shared keys or public keys may be used to secure the key
management communications with the key server). The Key Index associated
with the assigned RPL group key allows RPL nodes to ensure
synchronization to a common shared key. RPL's group key can be changed
by the key server at any time and nodes can request the current key when
out of sync with a routing peer (that is, when having a lower Key index
key). The Key Source ID would refer to the RPL key server entity, again
to ensure synchronization among RPL routing peers as to the entity from
which the group key was obtained. Since the security of RPL routing
exchanges is based on the shared group key it is vulnerable to
compromise of a single group member and hence the need for key updates.
With a single TGK/TEK assigned there is no difference in the level of
vulnerability between the single assigned group TGK or the derived group
TEK.  

if nonces are out of synch? 

>>[RA] Keep in mind that the key being requested, the RPL group key that
the node may have determined to be out of synch with its routing peers
is different from the key being used to secure and authenticate the RPL
node client (Q) to the key server (I). If the node is using a PSK for
authenticating exchanges to the key server and that key is out of synch,
the device needs to be re-provisioned/reconfigured (with Error
indication of inability to access key server, for ex.).

Moreover, the message flows do not seem to provide for timeliness (in
other words: how does entity I know that the request by entity R is
"fresh")?

>>[RA] Timeliness is supported only where the time-based Timestamp is
used. In the case of Q_MESSAGE the Timestamp payload is included in the
message set according to the time of origination of the message. When
the message is received at the server (I), it can be accepted provided
it is within the allowable time window when (including allowance for
degree to system time synchronization). In the returned I_MESSAGE the
same Timestamp value is included which again must be received at Q
within an allowable roundtrip time window (again subject to allowances
for degree of system time synchronization). 

>>[RA] The Q_MESSAGE is indeed protected and so the Requestor's
Timestamp value provides the equivalent of the random value. The logical
binding is therefore supported in the defined mechanism. Let us discuss
to ensure I fully understand the concern.

>>[RA] Keep in mind that the communications with the key server in RPL
is distinct from the communications with routing peers. The key server
using PSK or PKE methods with each node is able to assign the routing
security group key. In the RPL 'Authenticated' mode a node has a key
that only allows a leaf join (no routing). That leaf join then allows
key management exchanges with the key server to obtain the current
routing group key. Until that group key is obtained the node cannot
operate as a routing peer.

>>[RA] See above discussion.

Additional note:
-Section 3.1, 2nd last para: doesn't this impact the resulting
properties?

>>[RA] This determines when a key assignment confirmation is required
for a server-initiated key push.

6) Public key usage:

>>[RA] Noted. A recommendation that could be made for devices/networks
that support additional processing resource capabilities.

Additional note:

>>[RA] Timeliness checks can be supported when the time-based Timestamp
payload is used (see discussion above).

(with proper eye for detail, of course) should be mandatory to
implement.

>>[RA] I think it would be more consistent with RPL to make PSK
mandatory and both PKE and DH methods optional. This comment was also
made by another reviewer. The intent of AMIKEY is to provide a
reasonable lowest-common denominator with the ability to ratchet up the
security level based on application environment.

7) Hash function

>>[RA] Agreed. A trade-off made to permit lowest common denominator (all
AES implementation) devices. SHAx of course remains an option that is
available for devices/networks that can support the additional
capability.

8) Key management fit

>>[RA] As described in the Section 2, the key management entity
logically exists independent of the device protocol layers. The KM
entity can thus select the particular protocol for which key management
is being performed. As previously discussed, the objective is to be able
to handle key management for one or more layers with a single protocol
given the constraints of a LLN-type device. 

9) Other notes

>>[RA] Noted.

>>[RA] I think this was just loose wording intended to convey
replacement. CCM can be mandated. I would still be interested in your
reference paper. 

>>[RA] Understood. The intent was to re-use the "IV" information element
given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp
(time-based or Counter from the originator) it was guaranteed to be
non-repeating. This should be cleaned up to avoid potential confusion.  

>>[RA] No this should be a number. This number will match the number of
subsequent occurrences of "CS ID map info" elements in the message.

>>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as
the IEEE EUI 64-bit MAC where it can be derived from the IP address of
packet carrying the key exchange message (the IPv6 address being
auto-configured from the MAC address in conformance with RFC4291).

>>[RA] Yes CCM can be mandated.

---

From: Rene Struik <[email-masked]>
Date: Wed, 19 Oct 2011 16:11:12 -0400

Hi Roger:

Thanks for your feedback.

What would really help here is to showcase a specific instantiation of
AMIKey that exemplifies how it can address the key management aspects
that have been labelled out of scope with rpl-19. This could then also
serve as taking away [resp. identifying] thoughts that interoperability
may be sacrificed once one wishes to switch on security.

Another benefit of this exercise is that it maeks the AMIKey draft
somewhat more concrete for the ROLL WG membership. (It has been written
more abstractly than just to serve rpl, which is great, but may also
deter some of the audience.)

I can imagine this exercise to assume device counters, rather than a
notion of time (since, with rpl, this was argued to be "unrealistic" at
the time [around June 2010], but perhaps this needs revisiting]). This
would allow identifying whether this indeed addresses key management
aspects that were out of scope with rpl so far.

All - it would be invaluable to have some insight as to whether
implementations based on rpl-19 actually use its security provisions and
gain some insight into problems/bottlenecks/interop issues, and
the-like. So far, not too much information on this has been brought to
the foreground, but it would be invaluable to have some.
So, please do not be shy and share your experiences and perspectives here.

Best regards,

Rene

On 14/10/2011 4:13 PM, Alexander, Roger wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Rene Struik
> *Sent:* Friday, October 14, 2011 9:47 AM
> *To:* [email-masked]
> *Subject:* [Roll] notes re AMiKey
> *Subject: *
> *Date: *
> *From: *
> *To: *
> <mailto:[email-masked]>, Tsao, Tzeta
> <[email-masked]> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
>  
>
> Dear Roger, Tzeta:
>  
> and is part of the specification. Note that in the specific case of
> RPL key management, state information is required only between the RPL
> node and the key server entity.
>
>  
>  
> While AMIKey could have
> Counter is also defined. The NTP-based Timestamp is mandatory for
> MIKEY (See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the
> Counter is to be made mandatory, while Timestamp is optional
> (consistent with RPL).
>
> See Section 5.4 of RFC3830 for a good discussion of the issue
> regarding the tradeoff of state maintenance (replay cache) versus
> degree of time synchronization to be maintained.
>
>  
> Additional note:
> period can be defined by an Interval (Valid From and Valid To) that
> can be referenced to the Timestamp of the key assignment message. The
> key (TGK) and the TEK. However, the use of a TGK to derive multiple
> TEKs only applies where required for simultaneous assignment or update
> of related keys, as applicable for example in the multimedia domain
> for voice video, etc. For RPL the RPL routing group key (TEK) would be
> the only key derived from the assigned TGK.
>
>  
>  
> Additional note:
> the TGK) by the RPL Key Server for use in securing the routing
> exchanges between the RPL peers. Some further clarifications can be
> made to ensure that this is better understood. As in other sections,
> the intent will be to use RPL-specific examples throughout while
> maintaining the protocol's more general application.
>
>  
>  
> 3) Key identification
> management communications with the key server). The Key Index
> associated with the assigned RPL group key allows RPL nodes to ensure
> by the key server at any time and nodes can request the current key
> when out of sync with a routing peer (that is, when having a lower Key
> index key). The Key Source ID would refer to the RPL key server
> entity, again to ensure synchronization among RPL routing peers as to
> the entity from which the group key was obtained. Since the security
> of RPL routing exchanges is based on the shared group key it is
> vulnerable to compromise of a single group member and hence the need
> for key updates. With a single TGK/TEK assigned there is no difference
> in the level of vulnerability between the single assigned group TGK or
> the derived group TEK. 
>
>  
>  
> >>[RA] Keep in mind that the key being requested, the RPL group key
> that the node may have determined to be out of synch with its routing
> peers is different from the key being used to secure and authenticate
> the RPL node client (Q) to the key server (I). If the node is using a
> PSK for authenticating exchanges to the key server and that key is out
> of synch, the device needs to be re-provisioned/reconfigured (with
> Error indication of inability to access key server, for ex.).
>
>  
>
>  
>
> Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")?
>
> used. In the case of Q_MESSAGE the Timestamp payload is included in
> the message set according to the time of origination of the message.
> When the message is received at the server (I), it can be accepted
> provided it is within the allowable time window when (including
> allowance for degree to system time synchronization). In the returned
> I_MESSAGE the same Timestamp value is included which again must be
> received at Q within an allowable roundtrip time window (again subject
> to allowances for degree of system time synchronization).
>
>  
>  
> Timestamp value provides the equivalent of the random value. The
> logical binding is therefore supported in the defined mechanism. Let
> us discuss to ensure I fully understand the concern.
>
>  
>  
> >>[RA] Keep in mind that the communications with the key server in RPL is distinct from the communications with routing peers. The key server using PSK or PKE methods with each node is able to assign the routing security group key. In the RPL 'Authenticated' mode a node has a key that only allows a leaf join (no routing). That leaf join then allows key management exchanges with the key server to obtain the current routing group key. Until that group key is obtained the node cannot operate as a routing peer.
>  
>  
> >>[RA] Timeliness checks can be supported when the time-based
> Timestamp payload is used (see discussion above).
>
>  
>  
> reasonable lowest-common denominator with the ability to ratchet up
> the security level based on application environment.
>
>  
>  
> 7) Hash function
> >>[RA] Agreed. A trade-off made to permit lowest common denominator
> (all AES implementation) devices. SHAx of course remains an option
> that is available for devices/networks that can support the additional
> capability.
>
>  
>  
> 8) Key management fit
> entity can thus select the particular protocol for which key
> management is being performed. As previously discussed, the objective
> is to be able to handle key management for one or more layers with a
> single protocol given the constraints of a LLN-type device.
>
>  
>  
> 9) Other notes
> >>[RA] Understood. The intent was to re-use the "IV" information
> element given in RFC 3830 as a Nonce. Since that "IV" included the
> Timestamp (time-based or Counter from the originator) it was
> guaranteed to be non-repeating. This should be cleaned up to avoid
> potential confusion. 
>
>  
>
>  
> >>[RA] No this should be a number. This number will match the number
> of subsequent occurrences of "CS ID map info" elements in the message.
>
>  
> email: [email-masked] <mailto:[email-masked]>
> Skype: rstruik
> cell: +1 (647) 867-5658

---

From: Don Sturek <[email-masked]>
Date: Wed, 19 Oct 2011 14:20:13 -0700

Hi Rene,

Currently, in ZigBee IP, we do not use the RPL security provisions and don't
plan to in our initial deployments.  We are using PANA to provision IEEE
802.15.4 link layer keys (with the ability to update the keys when required)
then are using TLS security at the application layer.

Don

From:  Rene Struik <[email-masked]>
Date:  Wed, 19 Oct 2011 16:11:12 -0400
To:  "Alexander, Roger" <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [Roll] notes re AMiKey
draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

 Hi Roger:

 What would really help here is to showcase a specific instantiation of
AMIKey that exemplifies how it can address the key management aspects that
have been labelled out of scope with rpl-19. This could then also serve as
taking away [resp. identifying] thoughts that interoperability may be
sacrificed once one wishes to switch on security.
 
 Another benefit of this exercise is that it maeks the AMIKey draft somewhat
more concrete for the ROLL WG membership. (It has been written more
abstractly than just to serve rpl, which is great, but may also deter some
of the audience.)
 
 I can imagine this exercise to assume device counters, rather than a notion
of time (since, with rpl, this was argued to be "unrealistic" at the time
[around June 2010], but perhaps this needs revisiting]). This would allow
identifying whether this indeed addresses key management aspects that were
out of scope with rpl so far.
 
 All - it would be invaluable to have some insight as to whether
implementations based on rpl-19 actually use its security provisions and
gain some insight into problems/bottlenecks/interop issues, and the-like. So
far, not too much information on this has been brought to the foreground,
but it would be invaluable to have some.
 So, please do not be shy and share your experiences and perspectives here.
 
 Best regards,
 
 Rene

 On 14/10/2011 4:13 PM, Alexander, Roger wrote:
>     
>  
> 
> Hi Rene,
>  
>  
>  
> Thank you very much for the detailed review and comments. Please see responses
> below.
>  
>  
>  
> AMIKEY is of course a separate key management application intended to provide
> the out-of-band key management specification called for to support RPL
> ŒAuthenticated¹ mode security (see RPL, Section 3.2.3). It is thus intended to
> support the long-term updating/re-keying of the group key used to provide
> routing security among RPL peers.
>  
>  
>  
> Thanks again.
>  
>  
>  
> Best regards,
>  
>  
>  
> Roger
>  
>  
>  
>  
>  
>  
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rene
> Struik
>   From:    Rene Struik <[email-masked]> <mailto:[email-masked]>
>   To:    Alexander, Roger <[email-masked]>
>>> Section 5.4). The required state maintenance is of course simplified where
>>> system-wide time is available though a Counter can also be used and is part
>>> of the specification. Note that in the specific case of RPL key management,
>>> state information is required only between the RPL node and the key server
>>> entity.
>  
>  
>  
>  
>  
> While AMIKey could have
>  
>>> Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY (See
>>> Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is to be
>>> made mandatory, while Timestamp is optional (consistent with RPL).
>  
> See Section 5.4 of RFC3830 for a good discussion of the issue regarding the
> tradeoff of state maintenance (replay cache) versus degree of time
>>> >>[RA] This should read "Timestamp [payload]" where as specified in RFC3830
>>> the Timestamp payload can be a Timestamp or Counter value.
>  
>  
>  
>>> >>[RA] The granularity as given for NTP (32-bit fractional second). Devices
>>> would increment to their degree of supported system time synchronization.
>  
>  
>  
>>> >>[RA] Only applicable where system time is supported. The validity period
>>> can be defined by an Interval (Valid From and Valid To) that can be
>>> referenced to the Timestamp of the key assignment message. The granularity
>>> in the triggering of key updates will depend on the system time accuracy
>>> supported.    
>  
>  
>  
>  
>  
> 2) Key dependencies
>  
>>> >>[RA] Yes there is a deterministic mapping between the TEK generating key
>>> (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs only
>>> applies where required for simultaneous assignment or update of related
>>> keys, as applicable for example in the multimedia domain for voice video,
>>> etc. For RPL the RPL routing group key (TEK) would be the only key derived
>>> from the assigned TGK.
>  
>  
>  
>  
>  
> Additional note:
>  
>>> >>[RA] The TEK is the security key that will be assigned (derived from the
>>> TGK) by the RPL Key Server for use in securing the routing exchanges between
>>> the RPL peers. Some further clarifications can be made to ensure that this
>>> is better understood. As in other sections, the intent will be to use
>>> RPL-specific examples throughout while maintaining the protocol¹s more
>>> general application.
>  
>  
>  
>  
>  
> 3) Key identification
>  
>>> >>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section 10.1,
>>> RPL uses a shared group key assigned by a network Key Server (where
>>> pre-shared keys or public keys may be used to secure the key management
>>> communications with the key server). The Key Index associated with the
>>> assigned RPL group key allows RPL nodes to ensure synchronization to a
>>> common shared key. RPL's group key can be changed by the key server at any
>>> time and nodes can request the current key when out of sync with a routing
>>> peer (that is, when having a lower Key index key). The Key Source ID would
>>> refer to the RPL key server entity, again to ensure synchronization among
>>> RPL routing peers as to the entity from which the group key was obtained.
>>> Since the security of RPL routing exchanges is based on the shared group key
>>> it is vulnerable to compromise of a single group member and hence the need
>>> for key updates. With a single TGK/TEK assigned there is no difference in
>>> the level of vulnerability between the single assigned group TGK or the
>>> derived group TEK.
>  
>  
>  
>  
>  
>>> >>[RA] Keep in mind that the key being requested, the RPL group key that the
>>> node may have determined to be out of synch with its routing peers is
>>> different from the key being used to secure and authenticate the RPL node
>>> client (Q) to the key server (I). If the node is using a PSK for
>>> authenticating exchanges to the key server and that key is out of synch, the
>>> device needs to be re-provisioned/reconfigured (with Error indication of
>>> inability to access key server, for ex.).
>  
>  
>  
>  
>  
> Moreover, the message flows do not seem to provide for timeliness (in other
> words: how does entity I know that the request by entity R is "fresh")?
>  
>>> >>[RA] Timeliness is supported only where the time-based Timestamp is used.
>>> In the case of Q_MESSAGE the Timestamp payload is included in the message
>>> set according to the time of origination of the message. When the message is
>>> received at the server (I), it can be accepted provided it is within the
>>> allowable time window when (including allowance for degree to system time
>>> synchronization). In the returned I_MESSAGE the same Timestamp value is
>>> included which again must be received at Q within an allowable roundtrip
>>> time window (again subject to allowances for degree of system time
>>> synchronization).
>  
>  
>  
>  
>  
>>> >>[RA] The Q_MESSAGE is indeed protected and so the Requestor's Timestamp
>>> value provides the equivalent of the random value. The logical binding is
>>> therefore supported in the defined mechanism. Let us discuss to ensure I
>>> fully understand the concern.
>  
>  
>  
>  
>  
>>> >>[RA] Keep in mind that the communications with the key server in RPL is
>>> distinct from the communications with routing peers. The key server using
>>> PSK or PKE methods with each node is able to assign the routing security
>>> group key. In the RPL 'Authenticated' mode a node has a key that only allows
>>> a leaf join (no routing). That leaf join then allows key management
>>> exchanges with the key server to obtain the current routing group key. Until
>>> that group key is obtained the node cannot operate as a routing peer.
>  
>  
>  
>  
>  
>>> >>[RA] This determines when a key assignment confirmation is required for a
>>> server-initiated key push.
>  
>  
>  
>  
>  
> 6) Public key usage:
>  
>>> >>[RA] Noted. A recommendation that could be made for devices/networks that
>>> support additional processing resource capabilities.
>  
>  
>  
>  
>  
> Additional note:
>  
>>> >>[RA] I think it would be more consistent with RPL to make PSK mandatory
>>> and both PKE and DH methods optional. This comment was also made by another
>>> reviewer. The intent of AMIKEY is to provide a reasonable lowest-common
>>> denominator with the ability to ratchet up the security level based on
>>> application environment.
>  
>  
>  
>  
>  
> 7) Hash function
>  
>>> >>[RA] Agreed. A trade-off made to permit lowest common denominator (all AES
>>> implementation) devices. SHAx of course remains an option that is available
>>> for devices/networks that can support the additional capability.
>  
>  
>  
>  
>  
> 8) Key management fit
>  
>>> >>[RA] As described in the Section 2, the key management entity logically
>>> exists independent of the device protocol layers. The KM entity can thus
>>> select the particular protocol for which key management is being performed.
>>> As previously discussed, the objective is to be able to handle key
>>> management for one or more layers with a single protocol given the
>>> constraints of a LLN-type device.
>  
>  
>  
>  
>  
> 9) Other notes
>  
>>> >>[RA] I think this was just loose wording intended to convey replacement.
>>> CCM can be mandated. I would still be interested in your reference paper.
>  
>  
>  
>  
>  
>>> >>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as the
>>> IEEE EUI 64-bit MAC where it can be derived from the IP address of packet
>>> carrying the key exchange message (the IPv6 address being auto-configured
>>> from the MAC address in conformance with RFC4291).
>  
>  
>  
>  
>  
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2011 18:09:52 -0400

>>>>> "Rene" == Rene Struik <[email-masked]> writes:
    Rene> All - it would be invaluable to have some insight as to
    Rene> whether implementations based on rpl-19 actually use its
    Rene> security provisions and gain some insight into
    Rene> problems/bottlenecks/interop issues, and the-like. So far, not

It's too soon to hear much, I think.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.