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

From: "Tsao, Tzeta" <[email-masked]>
Date: Wed, 2 Nov 2011 16:22:07 -0400

Hi Rene, WG,

We are updating the AMIKEY draft to include a description on how AMIKEY
may be used with RPL. As we are not able to attend IETF82, but would
like very much to hear feedback from this WG, I have appended the text
in the following.  Your comment is most welcome.

Thanks,

Tzeta

------------------------------------------------------------------------
---------------

Key Assignment for the RPL Join Process

The process of a node joining a secured RPL instance is described in
Sec. 10.2 of the RPL specification. Where the DODAG operates in
"authenticated mode", as indicated by the "A" bit being set in the DODAG
Configuration option of the DIO messages, a joining node is required to
access a key server to obtain the current key for securing RPL messages.
AMIKEY is intended to support the requirements of the key management
protocol that allows RPL nodes to be able to obtain (and receive) the
dynamic DODAG security key (see Sec. 3.2.3 of the RPL specification).
For AMIKEY, the security of the key management protocol exchanges
between the nodes and the key server may be based on a pre-shared key
(PSK), public key (PKE) or Diffie-Hellman (DH) method as described in
the AMIKEY draft, Sec. 3.

Fig. 1 illustrates how AMIKEY may be employed to obtain the DODAG
security key. The figure depicts how the joining node uses AMIKEY to
request the DODAG key when a pre-shared key is used for securing the key
management exchange with the key server.

Joining Node                     RPL Router                  Key Server

      |                              |                            |

      |   1. RPL: Secure DIS (KI=0)  |                            |

      |----------------------------->|                            |

      |                              |                            |

      |   2. RPL: Secure DIO (KI=0,"A"bit set)                    |

      |<-----------------------------|                            |

      |                              |                            |

      |                                                           |

      |   3. AMIKEY: Q_MESSAGE (HDR, T, IDq, V)                   |

      |---------------------------------------------------------->|

      |   4. AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC)   |

      |<----------------------------------------------------------|

      |                                                           |

      |

      |   5. RPL: Secure DIS (KI=n)  |

      |----------------------------->|        

      |                              |       

      |   6. RPL: Secure DIO (KI=n)  |      

      |<-----------------------------|      

      |                              |

       Fig. 1: Key Assignment with AMIKEY in the RPL Join Process

1. A joining node broadcasts a RPL Secure DIS message to request DIO
information for joining the DODAG. The DIS message is secured using the
pre-installed key (see RPL, Sec. 3.2.3). The secure DIS message security
header includes the Key Index, KI=0, that references the pre-installed
key used to secure the message.

2. An existing DODAG RPL node responds with a secure DIO message that is
similarly secured with the pre-installed key, even where that key
differs from the DODAG RPL security key being used by nodes that have
joined the DODAG (see RPL, Sec. 10.2). This initial DIS/DIO exchange
allows the joining node to operate as a leaf node and forward data
traffic into the network without being part of the secure routing
exchange. 

3. Based on the A-bit being set within the Secure DIO message, the
joining node uses its leaf node network access to initiate the key
request to the key server to request the current DODAG security key; the
joining node does this by sending an AMIKEY key request (Q_MESSAGE) to
the key server (see AMIKEY, Sec. 3). In the example in Fig. 1 the
Q_MESSAGE is secured based on the pre-shared key maintained between the
joining node and the key server. The verification field (V)
authenticates the message sent by the requesting node (see AMIKEY, Sec.
4.2.4).

4. The key server responds to the request by assigning the current DODAG
key within the I_MESSAGE (see AMIKEY, Sec. 3.1). Like the Q_MESSAGE, the
I_MESSAGE is secured based on the pre-shared key maintained between the
joining node and the key server. The T field included in the I_MESSAGE
is the same as that sent by the key requesting node in the Q_MESSAGE.
This field in the form of a timestamp or counter allows for replay
protection (and timeliness verification if network-wide time is
supported in the DODAG). The KEMAC information element includes the
DODAG key material assigned by the key server encrypted using the
pre-shared key maintained between the joining node and the key server.

5. The assigned DODAG key (given by Key Index=n in the message security
header) is used to secure the subsequent secure DIS message.

6. Once the secure DIS message is authenticated by the receiver a secure
DIO message (with KI=n) is returned. That message provides current DODAG
routing information and allows the joining node to be a full RPL
participant of the secure DODAG. 

The particular information elements of the AMIKEY Q_MESSAGE include:

   HDR     Header (common AMIKEY header)

   T       Timestamp/counter

   IDq     ID of the requestor (joining node)

   V       Message verification

The particular information elements of the AMIKEY I_MESSAGE include:

   HDR     Header

   T       Timestamp/counter

   RAND    a (pseudo-)random bit-string used for generating the DODAG
security key (using AMIKEY, the RPL DODAG key is generated from the key
assigned by the key server)

   IDi     ID of the assignment initiator (key server)  

   SP      Security Policy that defines the policy information of the
secure RPL protocol for which the key assignment is being made

   KEMAC   Key data transport payload that includes the assigned key
generating key from which the RPL DODAG security key is derived

Note: In conjunction with RPL, AMIKEY can also be applied to support
proactive key assignment/update by the key server using an I_MESSAGE and
R_MESSAGE exchange as discussed in AMIKEY, Section 3.   

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rene Struik
Sent: Wednesday, October 19, 2011 4:11 PM
To: Alexander, Roger
Cc: [email-masked]
Subject: Re: [Roll] notes re
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)

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: 

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

>>[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
applications that would not require a nonce-based mechanism and replay
protection, this seems a fair assumption (and holds for RoLL-based
cryptographic protection).

>>[RA] Agreed.

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.

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

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?

>>[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:
-Section 5.2, first para: this seems to suggest a mandatory timestamp.

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

Not sure what the granularity is with MIKey (important, since not to be
reused) and how this time stamp would be managed.

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

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

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

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

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

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

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? 

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

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.

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

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

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

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

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

Additional note:
-Section 3.2, forelast para: wouldn't this impact freshness and
aliveness properties?

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

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

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

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

>>[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
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.

>>[RA] Noted.

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

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

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

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

-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
rather than provide a number.

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

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

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

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

>>[RA] Yes CCM can be mandated.

-- 
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: "Alexander, Roger" <[email-masked]>
Date: Wed, 9 Nov 2011 18:20:14 -0500

Hi Rene, WG,

As a further follow-up, the following text provides an overview of the
use of AMIKEY for DODAG key update during the operation of a secured RPL
network.

Comments are welcome.

Thanks,

Roger

Key Update for RPL Authenticated Mode

The RPL security key for a DODAG operating in authenticated mode may be
updated one or more times during the lifetime of the DODAG. With AMIKEY,
such updates are initiated by the key server and pushed to individual
RPL nodes. 

Fig. 2 illustrates how AMIKEY is employed for the key update. The
scenario assumes a pre-shared key (PSK) for securing the key management
exchange between the RPL nodes and the key server. Public key encryption
(PKE) or Diffie-Hellman (DH) methods may also be used as described in
the AMIKEY draft, Section 3. 

RPL Node i                   RPL Node j                      Key Server

    |                            |                                 |

    | 1. Secure DIO              |                                 |

    |    (KI=n, "A"bit set)      |                                 |

    |--------------------------->|                                 |

    |                            |                                 |

    | 2. Secure DAO (KI=n)       |                                 |

    |<---------------------------|                                 |

    |                            |                                 |

    | 3. Secure DAO ACK (KI=n)   |                                 |

    |--------------------------->|                                 |

    ~                            ~                                 |

    ~                            ~                                 |

    |                                                              |

    |      4a. AMIKEY: I_MESSAGE (HDR,T,RAND,IDi,{SP},KEMAC)       |

    |<=============================================================|

    |                                                              |

    |      5a. AMIKEY: R_MESSAGE (HDR,T,IDr V)                     |

    |=============================================================>|

    |                                                              |

    |                            | 4b. AMIKEY: I_MESSAGE           |

    |                            |     (HDR,T,RAND,IDi,{SP},KEMAC) |

    |                            |<================================|

    |                            |     5b. AMIKEY: R_MESSAGE       |

    |                            |         (HDR,T,IDr V)           |

    |                            |================================>|

    ~                            ~

    ~                            ~

    |                            |

    | 6. Secure DIO              |

    |    (KI=n+1,"A"bit set)     |

    |--------------------------->|        

    |                            |

    | 7. Secure DAO (KI=n+1)     |      

    |<---------------------------|      

    |                            |

    | 8. Secure DAO ACK (KI=n+1) |

    |--------------------------->|        

    |                            |       

        Fig. 2: Key Update during RPL Operation Using AMIKEY

1. An operating RPL node (Node i) transmits a Secure DIO message
providing information on its DODAG routing connectivity. The DIO message
is secured using the current DODAG security key indicated by the
inclusion of the Key Index, KI=n, within the message security header.

2. In response to the DIO message the RPL routing peer (Node j) sends a
Secure DAO message to establish/maintain its routing connectivity. The
DAO message is secured with the current DODAG security key indicated by
the inclusion of KI=n within the message security header. 

3. The RPL node receiving the DAO message may acknowledge receipt of the
message by sending a Secure DAO ACK message, also secured by the current
DODAG key.

4. The key server can choose at any time to update the current DODAG key
by making a new key assignment to each network node. The new key is
encrypted within the KEMAC information element of the I_MESSAGE (see
AMIKEY, Sec. 3.1). In this example the I_MESSAGE is secured based on the
pre-shared key maintained between each node and the key server. The T
field included in the I_MESSAGE, in the form of a timestamp or counter
allows for replay protection (and timeliness verification if
network-wide time is supported).

5. The key assignment is acknowledged by the receiving node through the
sending of the R_MESSAGE (see AMIKEY, Sec. 3). The requirement for the
sending of the 

R_MESSAGE is specified through the setting of the V-bit flag in the
I_MESSAGE Header (HDR). For replay protection and timeliness
verification on the part of the key server, the T field included in the
R_MESSAGE, is copied and repeated from the I_MESSAGE. The verification
field (V) authenticates the message sent by the responding node using
the node-key server pre-shared secret.

6. The updated DODAG key, indicated by the Key Index=n+1 in the message
security header, is used to secure the subsequent transmitted Secure DIO
messages.

7. Following the key update the Secure DAO messages also use the newly
assigned key (indicated by KI=n+1 in the message security header). 

8. Any Secure DAO ACK messages are similarly protected using the newly
assigned key.

   HDR     Header

   T       Timestamp/counter

   RAND    a (pseudo-)random bit-string used for generating the DODAG
security key (using AMIKEY, the RPL DODAG key is generated from the key
assigned by the key server).

The particular information elements of the AMIKEY R_MESSAGE include:

   T       Timestamp/counter

   IDr     ID of the responder (RPL node)

   V       Message verification

Note: In an ad hoc network there is the potential for nodes that have
received a DODAG key update to initiate routing exchanges with nodes
that have not yet received the update. This situation will be detected
by the mis-match between the node's maintained DODAG key index and that
of its corresponding peer. Where a received RPL message is secured by a
key different from that maintained by the recipient node it will not be
possible to verify the authenticity or validity of the message. To avoid
potential denial of service attacks from forged or purported Secure RPL
messages, a RPL node should silently discard such messages if it has not
received an updated key. One consequence is the potential for broken RPL
associations when the key update is not sufficiently synchronized across
the DODAG. A key activation time can be used to limit the potential for
such routing disruptions during the key update. The Key Activation time
in the form of a UTC clock time or future count can be specified through
the AMIKEY Key Validity information element (see MIKEY Key data
sub-payload, Section 6.13). 

A node recovering from reset and receiving Secure DIO messages with a
key index different from the one currently maintained can revert its
status to a non-routing (leaf) node. The node can then initiate an
AMIKEY key request to the key server to obtain the current DODAG key.

From: Tsao, Tzeta 
Sent: Wednesday, November 02, 2011 4:22 PM
To: Rene Struik; Alexander, Roger; [email-masked]
Cc: Adrian Farrel
Subject: RE: [Roll] notes re
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)

Hi Rene, WG,

Thanks,

Tzeta

 

      |                              |                            |

      |   1. Secure DIS (KI=0)       |                            |

      |                              |                            |

      |   2. Secure DIO (KI=0,"A"bit set)                         |

      |                              |                            |

      |                                                           |

      |==========================================================>|

      |<==========================================================|

      |                                                           |

      |

      |   5. Secure DIS (KI=n)       |

      |                              |       

      |   6. Secure DIO (KI=n)       |      

      |                              |

 

   T       Timestamp/counter

   V       Message verification

   HDR     Header

   T       Timestamp/counter

 

 

Hi Roger:

Best regards,

Rene

Hi Rene,

Thanks again.

Best regards,

Roger

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

[resend]

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

Subject: 

Date: 

From: 

To: 

CC: 

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

Dear Roger, Tzeta:

 
While AMIKey could have

 
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

 

 

 

 

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

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