1. <January 2002>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Security Architecture Considerations
Date Submitted: 18 January 2002
Source: John R. Barr , Motorola
Address: 1303 E. Algonquin Road, IL01/4th, Schaumburg, IL 60196
Voice: (847) , FAX: (847) ,
Re: 00000D09P __Draft_Standard.pdf
Abstract: Overview of possible security architecture implementations for P
Purpose: For consideration by Security committee to understand how security could be implemented with the MAC frame formats and MAC services provided by the MLME through the MLME- SAP.
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
<John R. Barr>, <Motorola>

2. TG3 Security Architecture Considerations
<January 2002>
doc.: IEEE <02/034r0>
<January 2002>
TG3 Security Architecture Considerations
John R. Barr, Ph.D.
Motorola
<John R. Barr>, <Motorola>
<John R. Barr>, <Motorola>

3. <January 2002>
doc.: IEEE <02/034r0>
<January 2002>
Issues
Overview of how security could be implemented with current frame formats and MLME SAPs in D09.
Cipher Suite Implications
<John R. Barr>, <Motorola>
<John R. Barr>, <Motorola>

4. Top Level Security Architecture
<January 2002>
Top Level Security Architecture
User or Service Interfaces
To Certificate Authority
Or Trusted Entities
PNC
Embedded Keys
DEV Host
DEV A
DEV B
Security
Manager
SSCS
DEV Host
DEV Host
DME
Security
Interface
SSCS
Security
Interface
SSCS
MAC/PHY
DME
DME
MAC/PHY
MAC/PHY
RF Media
Security Manager exists in devices that are PNC capable and have full security authentication capability.
Security Interface exists in devices that cannot perform security authentication and are not usually PNC capable.
P specification does not define how functions within “radio” are implemented nor how they interact. It does define the frame formats and expected behavior of the radio communicating with other radios, and the interaction of the radio with the DEV host.
Information required by a Security Manager or Security Interface in a radio to perform the expected behavior (e.g., pre-defined public and private keys) can be obtained through the DEV Host interface or be embedded in the device at point of manufacture. It is outside the scope of P to define how these security parameters are handled outside of the radio interface.
The DME or a combination of the DME, Security Manager, SSCS, or MAC implementation must implement the algorithms necessary to respond to or generate the MAC frames necessary to perform authentication.
<John R. Barr>, <Motorola>

5. 802.15.3 Security Frame Functions
<January 2002>
Security Frame Functions
Authentication (DEV  PNC)
DEVPublicKeyObject  PNC  AuthenticationInfo  DEV
DEVPublicKeyObject  PNC  Failure  DEV
Challenge (DEV  DEV)
PublicKeyChallenge  DEV  PublicKeyProof  DEV
Request Key (DEV  PNC)
KeyPurpose  PNC  KeyPurpose,EncryptedKey  DEV
KeyPurpose  PNC  Failure  DEV
Distribute Key (PNC  DEV)
KeyPurpose,EncryptedKey  DEV
Deauthenticate (PNC  DEV)
<John R. Barr>, <Motorola>

6. Public Key Authentication Loop
<January 2002>
Public Key Authentication Loop
PNC device obtains group authentication keys (public and private) from certificate authority or other trusted party. (Embedded or entered)
DEV obtains DEV keys (public and private) and group authentication public key from CA or other trusted party.
DEV associates and verifies that the cipher suite OID in the beacon matches what it can handle.
Authentication: (success)
DEV sends DEVPublicKey to PNC.
PNC sends challenge to DEV encoded with DEVPublicKey
DEV decodes challenge and sends back to PNC encoded with group authentication public key.
PNC decodes challenge response and sends back AuthenticationInfo encoded with DEVPublicKey if challenge okay.
PNC MAC adds DEV to authenticated DEV list when Authentication response sent with ResultCode set to 1.
<John R. Barr>, <Motorola>

7. <January 2002>
Key Distribution
PNC has set of keys defined by cipher suite that authenticated DEVs may require for encrypted secure transfers. (Acquired from interface, embedded or generated from other keys.)
PNC provides these keys to authenticated devices for use:
PNC encrypts DEK using DEVPublicKey and sends to DEV
DEV receives Distribute Key frame and uses its PrivateKey to decrypt the DEK EncryptedKeyObject.
(DEV unpacks necessary keying information from the KeyObject and associates this KeyObject with the current Key number in the piconet syncronization parameters.)
All data frames sent by DEV are encrypted with KeyObject.
All data frames received by DEV are decrypted with KeyObject.
DEV monitors key number to determine when to expect or request a new DEK. (There does not seem to be a viable way of ensuring that all DEVs have current keys so data flows well. What happened to the the key is changing countdown?)
<John R. Barr>, <Motorola>

8. Cipher Suite Implications
<January 2002>
Cipher Suite Implications
OID in beacon identifies a unique cipher suite implementation.
This needs to be clarified as to how an OID defines what is needed.
Cipher suite implementation details include:
Key information used
Message exchange charts for authentication, key distribution, etc.
State diagrams used in PNC and DEV for each action
Approved methods for distributing or generating keys
Recommendations/requirements for regular key changes
Implementation may embed state machines and key manipulation engine anywhere in radio as long as external (over the air) operations remain same.
DEV Host interface also highly implementation dependent based on whether the DEV is highly embedded.
<John R. Barr>, <Motorola>

9. <January 2002>
Goals
Establish model for implementation of cipher suites using available frame formats and command interfaces.
Add detail to MAC specification where required to handle reasonable range of cipher suite possibilities (Public Key primary).
Define how cipher suites should be specified in appendix to the specification.
Select mandatory cipher suite implementation for baseline security model. This may not be required in the standard (PICs).
<John R. Barr>, <Motorola>