Get documents about "Company Security Proposal
Description
Company Security Proposal document sample
Document Sample
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Draft 1 security change proposal]
Date Submitted: [11 May, 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: [Response to the call for proposal of IEEE 802.15.4b, Security enhancements]
Abstract: [Discussion for several potential enhancements for current IEEE 802.15.4 MAC]
Purpose: [For the discussion at IEEE 802.15.4b Study Group]
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.
Submission Slide 1 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Draft 1 Security Change Proposal
Robert Cragie
Jennic Limited
Submission Slide 2 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
• Also includes resolutions from TG4b ad-
hoc, 2-3 May 2005.
Submission Slide 3 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
Submission Slide 4 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
Submission Slide 5 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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 15-0082-01
Submission Slide 6 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Proposed Security Control subfield
0-2 3-5 6-7
Security Key Identifier
(reserved)
Level Length
• Unchanged fields:
– Security Level
• Removed fields:
– Minimum Security Level
– Key Source Addressing Mode
• New fields:
– Key Identifier Length
Submission Slide 7 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Source Extended Address
• There is currently no means of explicitly
specifying the source extended address
in the ASH
• However, this has not been included as
there are other ways of conveying this
information, e.g:
– Device Table set up a priori
– Using source address mode 3
• See comments #458 and #1129
Submission Slide 8 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
• See comments #145, #150, #457, #863, #944, #1080/32
and #1095/47
Submission Slide 9 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Key Source Addressing Mode
• Has been effectively replaced by the Key
Identifier Length
Submission Slide 10 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
• See comments #455, #1075/27 and #1147/99
Submission Slide 11 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
Submission Slide 12 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Explicit Key Identifier
• If Key Identifier length is not 0, the Key Identifier is used to
lookup the keying material
• A typical arrangement of keying material data could be:
– A sequence of up to 256 keys for a single default keying
material sequence looked up by 1 octet Key Identifier
– A sequence of up to 256 keys for a number of 4-octet based
keying material sequences looked up by 5-octet Key
Identifier
– A sequence of up to 256 keys for a number of 8-octet based
keying material sequences looked up by 9-octet Key
Identifier
Submission Slide 13 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
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
Submission Slide 14 Robert Cragie, Jennic Ltd.
May 2005 doc.: IEEE 802.15-05-0134-02-004b
Proposed Auxiliary Security Header
Octets: 1 4 0/1/5/9
Security
Frame Counter Key Identifier
Control
• Security Control and Frame Counter fields
swapped round (comment #1038)
• Key Sequence Number amalgamated into Key
Identifier (comments
• The Key Identifier is only present if the Security
Control subfield’s Key Identifier Length field is
not 0x00
Submission Slide 15 Robert Cragie, Jennic Ltd.
