Hi Carsten: For an overview of security functionality provided by 802.15.4-2006, cf. Clause 5.6 of the standard (excerpted below).
FYI - With IEEE 802.15.4e, intention is to introduce some security enhancements (e.g., timeliness) and realize overhead reduction techniques (cutting down on over-the-air traffic) have been proposed -- cf., e.g., the following documents (all posted on the IEEE 802 reflector https://mentor.ieee.org/802.15/documents ): Documents related to the security and overhead reduction proposal with 802.15.4e: 15-08-0828-08-004e-security-and-efficiency-enhancements.ppt 15-08-0848-01-004e-security-and-efficiency-enhancements-overview.doc 15-08-0849-00-004e-streamlined-security-clause-802-15-4-2006.pdf 15-09-0233-04-004e-frame-control-field-discussion.xls Intention is to have a first draft of IEEE 802.15.4e ready prior to the next IEEE 802 meeting, San Francisco, CA, July 12-17, 2009. I hope this helps. Best regards, Rene [source: excerpt from IEEE 802.15.4-2006, Clause 5.6] The cryptographic mechanism in this standard is based on symmetric-key cryptography and uses keys that are provided by higher layer processes. The establishment and maintenance of these keys are outside the scope of this standard. The mechanism assumes a secure implementation of cryptographic operations and secure and authentic storage of keying material. The cryptographic mechanism provides particular combinations of the following security services: - Data confidentiality: Assurance that transmitted information is only disclosed to parties for which it is intended. - Data authenticity: Assurance of the source of transmitted information (and, hereby, that information was not modified in transit). - Replay protection: Assurance that duplicate information is detected. The actual frame protection provided can be adapted on a frame-by-frame basis and allows for varying levels of data authenticity (to minimize security overhead in transmitted frames where required) and for optional data confidentiality. When nontrivial protection is required, replay protection is always provided. Cryptographic frame protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and application-specific tradeoffs between key storage and key maintenance costs versus the cryptographic protection provided. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key-sharing group. For more detailed information on the cryptographic security mechanisms used for protected MAC frames following this standard, refer to Clause 7. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: Tuesday, June 09, 2009 2:26 PM To: Richard Kelsey Cc: [email protected] Subject: Re: [6lowpan] ND and MAC-level security On Jun 9, 2009, at 17:00, Richard Kelsey wrote: > 802.15.4 security does not provide replay protection I think a better way to say this is slightly more blunt: "802.15.4 does not provide security". 802.15.4 only provides mechanisms (such as AES/CCM) that need to be used in the right way to achieve the security objectives. Replay protection with memoryless nodes is hard, indeed. (WG chair hat:) We do need to work on security in the 6LoWPAN WG. I would like to go to Stockholm with a pretty good idea of what the steps will be. I would love to hear your, and everybody else's, input. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
