doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Out of Order Receipt with Security] Date Submitted: [March 17, 2005] Source: [Rene Struik] Company [Certicom Research] Address [5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada] Voice:[ ], FAX: [ ], Re: [Comment #1044 of comment database on b, Draft #1 (see b) ] Abstract:[This document details a suggested remedy to Comment #1044] Purpose:[This document is submitted for improvements to the b draft specification.] Notice:This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 2 Out-of-Order Receipt with Security (Comment #1044) Rene Struik (Certicom Research)

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 3 Comment #1044 Clause 7.6, pp : Out-of-order frame receipt. Replay protection requires in-order frame receipt. In particular, this implies that protected frames that are received out-of- order yield a security processing failure at the destination address(es). This might hamper re-use of the same keying material across different layers and might also impact robustness within the MAC layer itself. Suggested remedy: keep track of a small window of last received frame counter values, rather than just the last received value. This allows modest out-of-order receipt without jeopardizing replay protection. The detailed text will be presented in an updated IEEE 802 document (04/539r3).

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 4 Details (1) Source: ADestination: B (4) Check freshness: N A  N 0 A {N A  {used frame counters}} Case 1 (in-order receipt of frame N) Case 2 (out-of-order receipt of frame N-5) NN-2N-1N-3N-6N -5N -4N -7N -8N+1 NN-2N-1N-3N-6N -5N -4N -7N -8N+1N+2 NN-2N-1N-3N-6N -5N -4N -7N -8N+1 NN-2N-1N-3N-6N -5N -4N -7N -8N+1

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 5 Details (2) Source: ADestination: B (4) Check freshness: N A  N 0 A {N A  {used frame counters}} Case 1 (in-order receipt of frame N) NN-2N-1N-3N-6N -5N -4N -7N -8N+1 NN-2N-1N-3N-6N -5N -4N -7N -8N+1N+2 Storage of external frame counter: -Store value N -Store 8-bit array b indicating which values in {N-8, N-7, …, N-1} have been received Update procedure: -Update N to N+1 -Shift-left b; set right-most value, corresponding to counter N, to TRUE Note: update of N to N+k induces k shift-lefts of b (filling to the right with 0s (or FALSE))

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 6 Details (3) Source: ADestination: B (4) Check freshness: N A  N 0 A {N A  {used frame counters}} Case 2 (out-of-order receipt of frame N-5) NN-2N-1N-3N-6N -5N -4N -7N -8N+1 NN-2N-1N-3N-6N -5N -4N -7N -8N+1 Storage of external frame counter: -Store value N -Store 8-bit array b indicating which values in {N-8, N-7, …, N-1} have been received Update procedure: -Do not update N -Set value b corresponding to N-5 to TRUE

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 7 Backup slides … … see also IEEE doc 04/245r2 (Slides 4-6)

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 8 MAC Security (1) Data key repository Data key repository data transfer AB Wrapped data Encryptor/ decryptor Encryptor/ decryptor data Data key Key info Key info Data key Security objectives Confidentiality (Encryption: ON/OFF) Data authenticity (Integrity: No/Low/Medium/High {i.e., 0, 32, 64, 128-bit}) Weak freshness (Relative ordering in time: Enabled/disabled {via FrameCounter}) Security non-objectives Strong freshness (Absolute ordering in time: not provided) Required info Algorithm Id: specifies the particular crypto primitive used Key Id: prevents use of improper data keys Sequence number: prevents undetected reordering (or replay) of message frames

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 9 MAC Security (2) Variations (1)A  B: : [x] SEC k, NA {k= f(A,B)} {unicast message} (2)A  G: : [x] SEC k, NA {k= f(A,G)}{multicast with multicast key} (3)A  G: Id G’ : [x] SEC k, NA {k=k G’, G  G’}{multicast with key of bigger group} Sender A: (1)Determine adequate security level: SEC  SEC 0 (A,G, x) (2)Determine key Key to be used for A  G (3)Determine frame counter N A (4)Perform crypto operations using (k, N A ) and protection level SEC (5)Update info Recipient B (B  G): (1) Check adequacy of purported security level: SEC  SEC 0 (A,G, x) (2) Retrieve key Key that was purportedly used (3) Retrieve frame counter N A that was purportedly used (4) Check freshness: N A  N 0 A {N A  {used nonces}} (5) Determine long address AddressA of sending device (6) Perform crypto operations using (k, N A ) and protection level SEC (7) Update info

doc.: IEEE Submission March 17, 2005 Poor & Struik / Ember & CerticomSlide 10 MAC Security (3) Adequate security level SEC  SEC 0 (A,G, x) Frame/Command Type Ordinary data Beacon Acknowledgement Command Associate Command Disassociate Special data SEC 0 ENC-MIC-64 MIC-64 None MIC-64 None