1. March 2005
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Draft 1 security change proposal]
Date Submitted: [15 March, 2005]
Source: [Robert Cragie] Company [Jennic Ltd.]
Address [Furnival Street, Sheffield, S1 4QT, UK]
Voice:[ ], FAX: [ ],
Re: [Response to the call for proposal of IEEE b, Security enhancements]
Abstract: [Discussion for several potential enhancements for current IEEE MAC]
Purpose: [For the discussion at IEEE b Study Group]
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
Robert Cragie, Jennic Ltd.

2. Draft 1 Security Change Proposal
<month year>
doc.: IEEE <doc#>
March 2005
Draft 1 Security Change Proposal
Robert Cragie
Jennic Limited
Robert Cragie, Jennic Ltd.
<author>, <company>

3. March 2005
Introduction
There are limitations in the changed security proposals in TG4b draft 1
This proposal is an attempt to resolve some of the problems based on discussions between the security subgroup members
Robert Cragie, Jennic Ltd.

4. Auxiliary Security Header (ASH)
March 2005
Auxiliary Security Header (ASH)
Consists of
Frame Counter subfield
Security Control subfield
Key Identification subfield (optional)
Key Identification subfield only present if Security Control subfield’s key source addressing mode is 0x01 to 0x03
Robert Cragie, Jennic Ltd.

5. Key Identification (KI) subfield
March 2005
Key Identification (KI) subfield
Currently consists of:
Key Source Address (0/4/8 octets)
Key Sequence Number (1 octet)
Key Source Address is limited to:
PAN ID/Short address pair
Extended address
Robert Cragie, Jennic Ltd.

6. Source Extended Address
March 2005
Source Extended Address
There is currently no means of explicitly specifying the source extended address in the ASH
Adding this could eliminate device table at remote end if freshness checking is made optional
Robert Cragie, Jennic Ltd.

7. KI subfield’s Key Source Address
March 2005
KI subfield’s Key Source Address
At the moment, it is currently based on implicit rules and addresses
Key Sequence number is an explicit extra but for lookup purposes is really just an appendix. It is no longer part of the nonce
Would be more flexible if it were just a variable length number used for lookup
This is more in line with
Robert Cragie, Jennic Ltd.

8. Proposed Security Control subfield
<month year>
doc.: IEEE <doc#>
March 2005
Proposed Security Control subfield
Unchanged fields:
Security Level
Removed fields:
Minimum Security Level
Key Source Addressing Mode
New fields:
Explicit Source Extended Address
Key Identifier Length
Robert Cragie, Jennic Ltd.
<author>, <company>

9. Minimum Security Level
March 2005
Minimum Security Level
Contains the minimum security level for the frame type from macSecurityLevelTableOut
Removed as it is arguable how useful it is; it is not used within the MAC and passed up to the higher layer only
There was some case where it may have been useful for association but this is often done unsecured as it is part of link establishment
macSecurityLevelTableOut can also be removed
If minimum security level cannot be removed, will need an additional octet in the ASH to carry Key Identifier length
Robert Cragie, Jennic Ltd.

10. Key Source Addressing Mode
March 2005
Key Source Addressing Mode
Has been effectively replaced by the Key Identifier Length
Robert Cragie, Jennic Ltd.

11. Explicit Source Extended Address
March 2005
Explicit Source Extended Address
Boolean field
False:
There is no source extended address explicitly specified in the ASH
True:
The source extended address is explicitly specified in the ASH. Adding the ability to explicitly specify source extended address in the ASH means that short addressing can be used for source address in MHR and device table is not necessarily required at remote end (assuming freshness checking becomes optional).
Explicit Source Extended Address is always used for the nonce at recipient
Robert Cragie, Jennic Ltd.

12. March 2005
Freshness checking
If there is a device table entry for the originator of the frame, freshness checking is done, as there will be a corresponding saved frame counter
If there is no device table entry, no freshness checking will be done and it will be assumed that all keying material can be obtained from the frame and key lookup
Robert Cragie, Jennic Ltd.

13. Key Identifier Length Enumerated field:
March 2005
Key Identifier Length
Enumerated field:
0x00: The Key Identifier is 0 octets long; the Key Identifier is implicit
0x01: The Key Identifier is 1 octet long
0x02: The Key Identifier is 5 octets long
0x03: The Key Identifier is 9 octets long
The Key Sequence Number (now a higher level concept) has been amalgamated into the Key Identifier
Generalise the Key Identifier to be just a number, not necessarily an address
Robert Cragie, Jennic Ltd.

14. Implicit Key Identifier
March 2005
Implicit Key Identifier
If Key Identifier length is 0, the Key Identifier is determined as follows:
Non-group addressed PDUs:
Source address is implicitly used as the Key Identifier at originator and destination address is used as the Key Identifier at recipient. This is because it is a link key, and keying material is a function of both source and destination address.
Group-addressed PDUs:
Destination address is implicitly used for as the Key Identifier at both originator and recipient. This is because it is a group/network key and keying material is a function of an identifier only; in this case it happens to be the destination address
Robert Cragie, Jennic Ltd.

15. March 2005
Source of ASH data
The source of the ASH data could either come from primitive parameters or ‘current’ PIB values
Draft 1 favours passing parameters in the primitives, e.g. in MCPS-DATA.request, KeyIdAddrMode and KeyIdAddress are passed. The advantages of this is that they are specified on a per-frame basis and could still be derived from the next higher layer’s ‘current’ information base
Explicit Source Extended address would also need to be indicated somehow. The originator may need to know capabilities of recipient to determine this
Robert Cragie, Jennic Ltd.

16. Proposed Auxiliary Security Header
<month year>
doc.: IEEE <doc#>
March 2005
Proposed Auxiliary Security Header
Unchanged fields:
Frame Counter
Security Control
New fields:
Source Extended Address (optional)
Key Sequence Number amalgamated into Key Identifier
Robert Cragie, Jennic Ltd.
<author>, <company>

17. Proposed Auxiliary Security Header (2)
March 2005
Proposed Auxiliary Security Header (2)
The Source Extended Address is only present if the Security Control subfield’s Explicit Source Extended address field is asserted
The Key Identifier is only present if the Security Control subfield’s Key Identifier Length field is not 0x00.
Robert Cragie, Jennic Ltd.