November 2005 doc IEEE 802 11 051093 r

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 MISP based Authentication Framework Date: 2005 -11 -15 Authors: Notice: This document has been prepared to assist IEEE 802. 11. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http: // ieee 802. org/guides/bylaws/sb-bylaws. pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. " Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart. kerry@philips. com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee. org>. Submission 1 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Abstract • We have modified our MIS protocol (DCN: 11 -05/0859 r 0) to meet the requirements. • This pre-proposal describes the frame exchanges between STA, AP and authentication servers (AS). • It meets the following TGu requirements. – – – – R 3 N 1 R 3 N 3 R 3 P 2 R 3 S 1 R 3 S 2 R 3 M 1 R 3 M 3 • This framework can be implemented as extension of IEEE 802. 11. Submission 2 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 System Architecture Authentication Servers (AS) SSPN B AP SSPN A AP AP STA Submission AP STA 3 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Shared Information STA AP AS • Share an session key which is • Share an identifier (AP-ID) and updated periodically a secret key (AP-key) • STA is identified by MAC address • Each AP has a different key • Share an identifier (User-ID) and a secret key (User-key) • Each STA has a different key • NO pre-shared information between AP and STA • User-key is NOT disclosed to AP Submission 4 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 SSPN ID (Proposal) • ESSID is not suitable for identifying SSPN because it is not unique. • SSPN ID is the unique identifier of SSPN. • SSPN ID should be assigned by a public agency like IEEE, IANA and so on. Submission 5 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Beacon or Probe? (R 3 N 1) • If a lot of SSPNs share an AP, probe request/response will be good for scalability. • If a lot of STAs share an AP, probe request/response will NOT be good for scalability. Because they will waste the bandwidth by probe requests/responses. • If a lot of frames transferred by an AP, STAs may not be able to send probe request. • Which scalability, SSPNs or STAs, is more important? • We consider the scalability of STAs is more important. So beacon is better than probe request/response for information delivery. • AP can transmit beacons with priority. Submission 6 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Protocol Overview STA AP AS Beacons Authentication Request • Mutual Authentication • Session Key Sharing • Upper Layer Information (Optional) Authentication Success Access Request Access Authorized Associate (In case of authentication failure) Authentication Failure Submission 7 Access Denied Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Beacon (AP->STA) • Beacons are transmitted in a fixed interval. – Each beacon includes the following information. • • Timestamp Serial Number Beacon Interval SSPN IDs Supported Security Types Supported Network Layer Types Channel • Scalability – If each SSPN ID is 4 octet, one beacon can include 300 SSPN IDs. – If an AP supports more SSPNs, the AP should transmit some types of beacons which includes different SSPN IDs. Submission 8 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Authentication Request Message (STA->AP) • • STA scans channels and receives beacons. If some SSPN IDs in the beacons correspond with the SSPN IDs of the STA, the STA selects preferred SSPN and sends an authentication request message to the AP. – The authentication request message includes • • Timestamp (included in the beacon) User ID SSPN IDs STA-AP Security Type (used between the STA and the AP) Session Key Seed (random value) ICV (Integrity Check Value) – ICV is calculated by applying HMAC-MD 5 with User-key to the 16 octet authentication data. The authentication data is calculated by applying MD 5 to the authentication request message frame with ICV field as 0. The AP examines the authentication request message by the timestamp and SSPN IDs. – If the timestamp is too old or the SSPN IDs don’t correspond with the SSPN IDs of the AP, the authentication request should be silently discarded. Submission 9 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Access Request Message (AP->AS) • Then the AP sends an access request message to the appropriate AS(s) by the SSPN ID. – The access request message includes • Authentication Data – The authentication data is calculated by applying MD 5 to the authentication request message frame with ICV field as 0. • User ID, SSPN ID, Session Key Seed and ICV (included in the authentication request message) • Authenticator – The authenticator is calculated by applying HMAC-MD 5 with AP-key to the access request message frame with authenticator field as 0. • AP-AS Security Type (used between the AP and the AS) • AP-ID • • Any networks can be used for delivering access request messages. Network ID (such as an IP address) can be used as the AP-ID Submission 10 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Behavior of AS 1. The AS examines the integrity of the access request message by the authenticator. 1. The AS searches the AP-key by the AP-ID in the access request. 1. 2. 3. The AS calculate the authenticator value by applying HMAC-MD 5 with AP-key to the access request message with the authenticator field as 0. The AS compares the authenticators, calculated by AS and included in the access request. 1. 2. If the AP-ID is invalid, the access request is silently discarded. If these two authenticators are same, the access request is right and proceeds to next step. If they are different, the access request message is silently discarded. The AS authenticates the STA by the authentication data and the ICV in the access request message. 1. The AS searches the User-key by the User-ID in the access request. 1. 2. 3. The AS calculates the ICV value by applying HMAC-MD 5 with the User-key to the authentication data in the access request. The AS compares the ICVs, calculated by AS and included in the access request. 1. 2. Submission If the User-ID is invalid, the AS sends an access denied message to the AP. If these two ICVs are same, the authentication successful. If they are different, the AS sends the access denied message to the AP. 11 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Behavior of AS (Cont. ) 3. The AS calculates the session key. 1. 4. The AS calculates the session key by applying HMAC-MD 5 with User-key to the session key seed in the access request. The AS calculate the session key delivery data. 1. 2. Submission The AS calculates the hashed ICV by applying HMAC-MD 5 with AP-key to the ICV in the access request. The AS calculates the session key delivery data by applying XOR between the session key and the hashed ICV. 12 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Access Authorized Message (AS->AP) • Then the AS sends the authentication authorized message to the AP. – The access authorized message includes • Session Key Delivery Data • ICV (included in the access request) • Authenticator – The authenticator is calculated by applying HMAC-MD 5 with AP-key to the access request message frame with authenticator field as 0. • The AP examines the access authorized message. – The AP calculates the authenticator value by applying HMAC-MD 5 with AP-key to the access authorized message with the authenticator field as 0. – The AP compares these two authenticators, calculated by the AP and included in the access authorized message. • If the two authenticator are same, the AP proceeds to the next step. • If they are different, the access authorized message is silently discarded. • The AP decrypts the session key. – The AP calculates the hashed ICV by applying HMAC-MD 5 with AP-key to the ICV in the access authorized message. – The session key is calculated by applying XOR between the hashed ICV and the session key delivery data in the access authorized message. Submission 13 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Authentication Success Message • Then the AP sends the authentication success message to the STA. – The authentication success message includes • ICV – The ICV is calculated by applying HMAC-MD 5 with the session key to the authentication success message frame with the ICV field as 0. • Network Information (Optional) • The STA examines the integrity of the message by the ICV. – The STA calculates the session key by applying HMAC-MD 5 with the User-key to the session key seed which is transmitted in the authentication request message. – The ICV is calculated by applying HMAC-MD 5 with the session key, just calculated, to the authentication success message with the ICV field as 0. – The STA compares these two ICVs, calculated by the STA and included in the authentication success message. • If the two ICVs are same, the STA knows the AP is valid. • If they are different, the STA ignores the message. • • • Now the STA and the AP are authenticated each other. And the STA and the AP share the session key for encryption. The session key is never transmitted in any portion of the authentication. Submission 14 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Data Message Format (HMAC-MD 5/AES-CBC-128 bit) 0 1 2 3 0123456789012345678901 Existing IEEE 802. 11 Header IVh • IVh: Upper 8 octets of the Initialization Vector for AES-CBC • Payload: A packet data of the upper protocol • Padding: It makes the payload multiple of 16 octets ICV Encrypted Portion Payload Extension of the IEEE 802. 11 header will be needed. Padding (variable length) Submission 15 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Encryption, Decryption and Message Authentication (AES-CBC-128 bit) Sender Receiver 1. 8 octet IVh is randomly generated. IVh 1. Extract the IVh from the data message. 2. Each octet of the IVh rotate 1 bit left. It is IVl. 3. Concatenate IVh and IVl. It is IV. 4. ICV is upper 6 octet of IVh. 3. Join IVh and IVl. It is IV. 4. ICV is upper 6 octet of IVh. ICV 5. Encrypt the payload, padding and the ICV by AES-CBC. 6. Make the message by adding IEEE 802. 11 header and the IVh. Submission 5. Decrypt the data message. Transmit Data Message 16 6. Extract the ICV from the decrypted message and compare it to the ICV calculated in 4 to confirm validity. Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Session Key Updating Authentication Time Key A Key B • The session key is identified by the flag in the extended IEEE 802. 11 header. • The session key updating interval should be discussed. Submission 17 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Multiple SSPN support Access Request for SSPN A AS SSPN: A Access Request for SSPN A AS SSPN: B Access Reply AS SSPN: A Access Reply AS SSPN: B Access Reply Access Request for SSPN B AP AP (a) By BR configuration (b) By AS proxy Submission 18 Access Request for SSPN A and B Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Power Consumption Consideration (R 3 M 1) • The STA sends only 1 frame for authentication and session key exchange. It means the power consumption is lower than authentication method like EAP. • The STA don’t need to send probe request. It makes the power consumption less. Submission 19 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Security Consideration (R 3 M 3) • Eavesdropping – Protected by cipher • Fake AP – Protected by mutual authentication • Session Hijack (R 3 P 2) – Protected by authentication of all frames Submission 20 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Requirements • R 3 N 1 – Described • R 3 N 3 – This framework allows single AP to authenticate with multiple SSPNs • R 3 P 2 – Described • R 3 S 1 – Described • R 3 S 2 – Described • R 3 M 1 – Described • R 3 M 3 – Described Submission 21 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Future Work • Designing the extended IEEE 802. 11 header • Designing the formats of the messages • Adapting the proposal to other requirements Submission 22 Hitoshi MORIOKA, ROOT Inc.

November 2005 doc. : IEEE 802. 11 -05/1093 r 1 Questions and Comments? Submission 23 Hitoshi MORIOKA, ROOT Inc.