1. 27 Febraury 2002
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Security Sub-committee Status Report
Date Submitted: 27 Feb, 2002
Source: Bob Huang, Dan Bailey, Gregg Rasor, Rene Struik, Matthew Wellborne
Company: Sony, NTRU, Motorola, Certicom, XtremeSpectrum
Address One Sony Drive TA3-12, Park Ridge, NJ 07656
Voice: , FAX: ,
Re: P
Abstract: Reports the agreements that security sub-committee reached during the February 2002 ad hoc meeting in Schaumburg, IL. These agreements were reach considering the three security proposals presented on 25 February 2002.
Purpose: For information, guidance and endorsement by prior to considering the Security Suite proposals and complete standards texts at the March plenary meeting of
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
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

2. 27 Febraury 2002
Backgound
Ad hoc security sub-committee met with the goal providing the St. Louis Plenary session with information that compares and contrasts the Security Suite proposals
Identify areas of agreement
Identify areas with different approach
Identify impact of different approaches
The security sub-committee received guidance from the larger group: security goals at slide 4
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

3. Backgound (cont.) Overviews of three security suite proposals
27 Febraury 2002
Backgound (cont.)
Overviews of three security suite proposals
Were presented at the ad hoc meeting
Provided the base material for sub-committee work
The proposals
02106r0P802-15_TG3-Overview-of-NTRU-Security-Suite.ppt
02107r0P802-15_TG3-Protocols-in-NTRU-Security-Suite.ppt
02108r0P802-15_TG3-Performance-and-Security-of-NTRU-Security-Suite.ppt
02111r0P802-15_TG3_WPAN_Security_Framework_Proposal.doc
02112r0P802-15_TG3_Summary_of_WPAN_Security_Proposal.ppt
02114r0P802-15_TG3-MAC-Distributed-Security-Proposal.ppt
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

4. Security Goals Map similarities of all three proposals
27 Febraury 2002
Security Goals
Map similarities of all three proposals
Establish key components:
Use cases
Trust Model
Threat models
Public key for authentication
Entity authentication
Symmetric key for data protection
Symmetric key update
Integrity for data protection
Protection of commands
Non-goals: limiting the scope
Limit the number of options for the whole group to consider
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

5. Use Cases Will pull them from Schaumburg presentations and insert here
27 Febraury 2002
Use Cases
Will pull them from Schaumburg presentations and insert here
02106r0P802-15_TG3-Overview-of-NTRU-Security-Suite.ppt
02114r0P802-15_TG3-MAC-Distributed-Security-Proposal.ppt
Others may be added (in rev to this doc)
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

6. Trust Model There is some trusted third party required Topology
27 Febraury 2002
Trust Model
There is some trusted third party required
Disagree on what the form/extent of this is, but a single message framework has be agreed to
Two forms:
Digital certificates
User control mechanisms
Topology
Central and distributed SM models can implement each other
Peer-to-peer security is implemented by all proposals
By parameterizing the number of keys that a device will support, both approaches can be supported by the MAC
DEV trusts DME to maintain access control list
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

7. 27 Febraury 2002
Trust Model
Two forms: - Digital certificates - User control mechanisms
Key Characteristics
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

8. 27 Febraury 2002
Threat Models
Agree on protections required against external threats (outside the piconet)
Pull common points from presentations
The things we most care about are:
Identity-based attacks
Third-party passive attacks
Third-party active attacks
One other point: Potential threat from “fly-on-the-wall” inside the piconet (first party)- Rene will provide concise description of attacks
Another point: Potential threat non-expiring authentications (first party)- Rene will provide concise description of attacks
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

9. Public key for authentication
27 Febraury 2002
Public key for authentication
Need to create an authentic channel using Public Key based techniques
Mutual authentication is agreed
Need an algorithm
Three proposed: RSA, ECC, NTRUencrypt
Agree that minimum level of security should be specified
Need a protocol, agree on goals:
To establish the identity (challenge) of the other party (DEV)
To validate the public key (binding) of the other party (DEV)
The user approves of their communication
A payload protection seed shared with only the other party
Different protocols proposed to meet these goals for each algorithm
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

10. Entity authentication
27 Febraury 2002
Entity authentication
Potential threat due to non-expiring authentications (first party)
Note - Rene will provide concise description of attacks
Need to assure that an entity is still alive
Two approaches
Provide explicit security mechanism
Rely on other secure commands
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

11. Symmetric key for data protection
27 Febraury 2002
Symmetric key for data protection
Agree that we need to use symmetric key for data encryption/decryption
Specific symmetric algorithms proposed:
Two-key 3-DES, AES
Mode of operation needs to be specified in each proposal
Has implications on out-of-order packets
We will try to support out-of-order packets
Supporting out-of-order packets has implications on level of security provided
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

12. 27 Febraury 2002
Symmetric key update
Need to provide mechanism (protocol) to update shared keys
Security policy dictates when required
Two approaches (largely the same*)
Without key confirmation
With key confirmation
* handled by proposals
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

13. Integrity for data protection
27 Febraury 2002
Integrity for data protection
We need to provide authenticity and integrity on data traffic
Protect against traffic substitution/injection
Protects against replay attacks
Has implications on out-of-order packets
We will try to support out-of-order packets by specifying the freshness granularity
Two modes proposed (largely the same*):
Encrypt-then-MAC and MAC-then-encrypt
Specific symmetric algorithms proposed:
Two-key 3-DES, SHA-1, et.seq. HMAC
* handled by proposals
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

14. Protection of commands
27 Febraury 2002
Protection of commands
We need to provide authenticity on DEV-PNC or PNC-DEV commands
Protect against command substitution/injection
Protects against replay attacks
We need to provide authenticity on DEV-DEV commands
Same algorithms as data protection, but use different keys
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum

15. Non-goals: limiting the scope
27 Febraury 2002
Non-goals: limiting the scope
Out of scope
Implementation details: Key exposure
Access control list management
Handled by DME (Possible informative text)
On both SM side and DEV side
DRM (higher layer security)
Registration of certificates
Non-cryptographic means of establishing Identity-Public key binding
B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne
Sony, NTRU, Motorola, Certicom, XtremeSpectrum