Ad-Hoc Group Requirements Report

1. Ad-Hoc Group Requirements Report • Group met twice - total 5 hours • Group size ranged from 6 ~ 15 • Extracted Doc245 requirements • Four presentations were received • Captured new requirements • Categorized and summarized (here) for discussion Jon Edney, Nokia

2. General Requirements(1) • Security framework must be able to prevent unauthorized access by peers • Security framework must protect wireless network traffic from eavesdropping • Security framework must protect wireless network traffic from packet forgeries • Any method must be resistant to all known active and passive attacks, including dictionary attacks, man-in-the-middle attacks, replay attacks, and interleaving attacks • TGi must add at least one method to the authentication framework that meet the security requirements of this document. Jon Edney, Nokia

3. General Requirements(2) • A flexible mechanism for adding interoperable security algorithms must be incorporated, so that the standard does not need to be revised to use new algorithms in the future. • The standard should specify one method as mandatory when security extensions are implemented. • Key exchange & Packet security negotiation should be specified separately although they might be implemented as part of a single method. • The standard shall include an informative annex with recommended practice for certain upper layer authentication methods Jon Edney, Nokia

4. General Requirements(3) • In the standard, security requirements are independent of QoS requirements. However, implementers should be aware of the potential interactions. {from original RQ} • Security framework must strongly protect keys and passwords from recovery by eavesdropper • Standards-based cryptographic algorithms must be favored over proprietary and non-standards based algorithms • The Security capabilities of the method shall meet or exceed that the required to maintain integrity against both active and passive attacks of 280 work factor and probability of successful bogus authentication (in the absence of 280 work) of at most 2-32 Jon Edney, Nokia

5. Authenticated Key Exchange Negotiation • Negotiation of authentication (and privacy algorithms) must be incorporated. • There must be a method for initiating party to advertise key exchange protocols Jon Edney, Nokia

6. Authenticated Key Exchange(1) • Security framework must allow for mutual authentication of STA (device and/or user) and network(ESS) or STA(IBSS). • Method must provide one or more session master key(s) from which other session keys required by packet security methods can be derived. • Security framework must allow key distribution or derivation of per-link or per-session keys • Session keys used should be unique to two communicating parties and need to be bound to session identity • authentication policy shall be the same for associate and re-associate operations Jon Edney, Nokia

7. Authenticated Key Exchange(2) • The same key must not be used for both peer authentication and for protecting the data on the data link. E.g.the peer authentication key must not be derived from the bulk data key or vice versa • The bulk data protections must monitor the rate of key entropy decay and take action to maintain security • The framework should support methods that allow deployment of authentication using existing RADIUS database(s) for wireless LAN, wire line LAN and remote network access. Jon Edney, Nokia

8. Packet Security Negotiation • Negotiation of authentication and privacy algorithms must be incorporated. Jon Edney, Nokia

9. Packet Security (1) • Security framework must provide authentication of the source of each packet. • The bulk data protections must provide authenticity of message payload and immutable fields • Each session should use unrelated keys for encryption • There must be a exchange of random material to be used for key derivation and a synchronization method (to coordinate sequence spaces to be used to bulk data key entropy and to initialize replay protection state). • The bulk data protections must provide replay protection Jon Edney, Nokia

10. Packet Security (2) • must be efficient in the use state that has to be maintained across different instances of the same secure channel • must prevent reflection attacks • must be designed and implemented so that a sequence number is “statistically never” reused with the same key, even across different instances of the same secure channel. • It is necessary and sufficient that the bulk data privacy algorithm provide immunity from chosen plaintext attacks but desirable for it also to provide immunity from chosen ciphertext attacks. Jon Edney, Nokia

11. Roaming • Security framework should not preclude fast and frequent roaming • must support explicit authentication on roaming Jon Edney, Nokia

12. Implementation Related • There must be a encryption method, better than WEP, meeting these requirements, which can be implemented on existing legacy hardware through software upgrade • Implementable on limited capability clients (1-2 MIPS) • must be suitable for implementation in access points and clients which have low or moderate computational resources. “Low or moderate” computational resources means a class of device for which the following example is indicative: • On initial association, a 40MIPS access point or mobile terminal with limited RAM must be able to execute the method in 5 seconds or less. • The bulk data protections must have efficient implementations in both hardware and software Jon Edney, Nokia

13. Others • Support for “Anonymity” in the sense that a STA can obtain authentication to the network based on an ephemeral identity. • Support for “Anonymity” in the sense that a 3rd party wireless STA cannot discover the user identity of a supplicant. • Method must allow STAs to be authenticated to more than one AP at a time Jon Edney, Nokia