Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Secured indirect data transaction proposal] Date Submitted: [14 November, 2005] Source: [Robert Cragie] Company [Jennic Ltd.] Address [Furnival Street, Sheffield, S1 4QT, UK] Voice:[+44 114 281 4512], FAX: [+44 114 281 2951], EMail:[rcc@jennic.com] Re: [] Abstract: [This presentation contains a proposal for secured indirect data transaction handling for IEEE 802.l5.4b] Purpose: [To provide a solution for comment #351 raised in letter ballot 31] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. Robert Cragie, Jennic Ltd.

2. Secured indirect data transaction proposal Robert Cragie Jennic Limited Robert Cragie, Jennic Ltd.

3. Introduction • Comment #351 in document 15-05-0395-01-004b highlights a problem with an unsecured data request MAC command being able to extract secured pending data from the coordinator • This proposal contains a simple solution to the problem Robert Cragie, Jennic Ltd.

4. The problem in more detail • At present, an unsecured data request MAC command can extract secured pending data from the coordinator • This is undesirable as an untrusted rogue device is able to extract secured pending data. Even if it cannot decode it, it may ‘steal’ the data from the device for which it is intended • There is currently a minimum security level definable for incoming frames. However, setting this to a higher level may prevent devices associating through the coordinator as they may not be able to extract the response Robert Cragie, Jennic Ltd.

5. Early proposals • Some early proposals based on additional tables and maintaining state of communication between a device and its coordinator • Main problem is additional storage and undesirable state maintenance Robert Cragie, Jennic Ltd.

6. Basic solution • Pair the security level of the data request MAC command with the data that it is soliciting • This would then allow trusted devices to solicit secured data only with a secured data request MAC command • It would still allow other devices to solicit unsecured data from the coordinator using an unsecured data request MAC command, e.g. during association Robert Cragie, Jennic Ltd.

7. Proposal • Add a parameter to MCPS-DATA.request • ExpectedSecurityLevel • This parameter is only relevant for indirect data and is stored alongside pending data • When the data request MAC command is received, its security level is compared with ExpectedSecurityLevel for the pending data, according to the rules in 7.6.3.3.1 in D3 • If security level is greater than or equal to ExpectedSecurityLevel then the pending data will be transmitted, otherwise the pending data remains in the transaction queue Robert Cragie, Jennic Ltd.

8. Advantages • No additional PIB tables • Minimal additional storage for each pending data frame • Security comparison rules are already used for minimum security level • Processing is consistent with minimum security level processing Robert Cragie, Jennic Ltd.

9. Disadvantages • Need an extra parameter in the MCPS-DATA.request primitive Robert Cragie, Jennic Ltd.