27 Febraury 2002 Project: IEEE P802.15 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:201-358-4409, FAX: 201-9306397, E-Mail:robert.huang@am.sony.com Re: P802.15.3 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 802.15.3 prior to considering the Security Suite proposals and complete standards texts at the March plenary meeting of 802.15.3. 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. B. Huang, D. Bailey, G. Rasor, R. Struik, M. Wellborne Sony, NTRU, Motorola, Certicom, XtremeSpectrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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