Overall
-------
Pretty good draft.  You need to improve readability (see editorial
comments below) and address some technical issues.  Usability is the
most critical issue, and could be tested (something Jukka could
potentially do).  As I mentioned already, I think the idea has promise
when combined with a password-authenticated key agreement, and would
make a good confernce submission.
	
Technical
---------

Section 4
- page 7
  You claim that "the possibility of the attacker being present at the
  time of key establishment is miniscule for commercial devices".
  This is true if you can mandate that the devices have 100% reliable
  persistante storage and will never forget their keys.  If there is a
  possibility of key loss, you have to allow "re pairing".  Once re
  pairing is allowed on demand, the claim does not hold anymore.  See
  Wool et al's paper on Bluetooth pairing from 2005.

  Why are there two encryptions in each of messages 3 and 4?  

Section 5
- page 7
  - why are the labels D1 and D2 included in the encryption?  It is
    good practice to explicitly include identity labels.  But since
    you use only an encryption algorithm, known plaintext can
    potentially be modified.  But that doesn't seem to lead to any
    advantage to the attacker.
  - "active" attacks are somewhat easier in this case: attacker can
    meet D3, pretend to be D1 and make D3 fall back to using the old
    k_13 by claiming that he didn't receive any key update message yet.

Section 6
- page 8
  What happens if there is a collision in the LOW_BITS?
  i.e., D2 finds ADDR_1' which matches in the LOW_BITS with ADDR_1
  in the last step, D1 will fall back to using k but D2 will use k'?

  -> Needs a way for D1 to tell D2 to fall back to using the old key

  "protection against active attacks .. is limited": seems like a
  passive attacker has as much information as an active attacker in
  this case? What advantage does an active attacker have? (

[Section 7: as discussed already:
- what is the advantage of this scheme compared to a simpler scheme
   consisting of an initial handshake, monitoring timeslots
   independently, and a final key confirmation (with support for
   resolving ambiguities by trying some alternatives for the session
   key).
]
 
Editorial
---------

Section 2
- page 2
  s/criteria/criterion
- page 3
  "... respectively": it is not clear what "respectively" means here.
  Do you mean that 22.8nW/bit was for 3.3V and 9nW/bit for 1.5V.
  If so, restate clearly.

  What does "One example (Dual - V_i memory)" mean?
  What is "Dual - V_i memory"? What is it an example of?

Section 3
- pages 4-5
  Describe the disadvantages of the schemes in 3.1 and 3.2 (just as
  for 3.3)
- page 6
  The last paragraph is not clear.  What do you mean by "end-to-end
  keying" in this context.  Why does it waste memory? What is "overlay
  amplification"? 

Section 4 (and later)
- Clearly identify what is your own contribution and what is
  attributed to others.  E.g., reading Sections 4 and 5, it is not
  clear whether they are your ideas (if so, say so) or someone elses
  (if so, provide reference).

Section 5
- page 7
  last but one line: should be "if k_23 was safe, then k'_12 will .."?