doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 1 MISP based Authentication Framework Notice: This document has been prepared to assist IEEE 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 Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 2 Abstract We have modified our MIS protocol (DCN:11-05/0859r0) to meet the requirements. This pre-proposal describes the frame exchanges between STA, AP and authentication servers (AS). It meets the following TGu requirements. –R3N1 –R3N3 –R3P2 –R3S1 –R3S2 –R3M1 –R3M3

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 3 System Architecture AP Authentication Servers (AS) STA AP STA Authentication Servers (AS) SSPN A SSPN B

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 4 Pre-shared Information APASSTA No pre-shared information between AP and STA Share an identifier (User-ID) and a secret key (User-key) Each STA has a different key Share an identifier (AP-ID) and a secret key (AP-key) Each AP has a different key

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 5 SSPN ID SSPN ID is the unique identifier of SSPN. SSPN ID should be assigned by a public agency like IEEE, IANA and so on.

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 6 Protocol Overview STAAPAS Authentication Request Access Request Access Authorization Authentication Success Associate Mutual Authentication Session Key Sharing Upper Layer Information (Optional) Probe Request Probe Response

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 7 Probe Request STA broadcasts a probe request with the virtual MAC address as source address. A probe request includes –SSPN IDs which the STA wish to connect

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 8 Probe Response Each AP has a list of SSPN IDs which can be connected to. When AP receives a probe request, AP searches its SSPN ID list. The AP sends a probe response to the STA. A probe response includes –Timestamp –All matched SSPN IDs –Supported Security Types

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 9 Authentication Request Message If some SSPN IDs are in the probe response, the STA selects preferred SSPN and sends an authentication request message to the AP. An authentication request message includes –Timestamp (included in the probe response) –User ID –SSPN ID –STA-AP Security Type (used between the STA and the AP) –Session Key Seed (random value) –ICV (Integrity Check Value, generated from the authentication request message itself)

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 10 Access Request Message When the AP receives the authentication request message, it checks the timestamp new enough. Then it sends an access request message to the appropriate AS. The access request message includes –Authentication Data (generated from the authentication request message) –User ID, SSPN ID, Session Key Seed and ICV (included in the authentication request message) –Authenticator (generated from the access request message itself) –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 can be used as the AP-ID

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 11 Access Authorized Message When the AS receives the access request message, it checks the integrity of the request by the authenticator and the AP-key. Then it authenticates the STA by the authentication data, ICV, User ID and the User-key. If the authentication is successful, the AS sends an access authorized message. The access authorized message includes –Session Key Delivery Data (generated from the session key seed, User- key, AP-key and ICV) –ICV (included in the access request) –Authenticator (generated from the access authorized message itself)

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 12 Authentication Success Message When the AP receives the access authorized message, it checks the integrity of the message by the authenticator and the AP-key. Then it sends the authentication success message to the STA. The authentication success message includes –ICV (generated from the session key delivering data, ICV in the access authorized message, AP-key and the authentication success message itself) –Network Information (Optional) When the STA receives the authentication message, it checks the integrity of the message by the ICV,

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 13 Authentication APASSTA Authentication Request Message Authentication Data (16byte) ICV (16byte) MD5 HMAC-MD5 (User-key) Authentication Request Message Authentication Data (16byte) Access Request Message ICV (16byte) Extract Authenticator (16byte) MD5 HMAC-MD5 (AP-key) Access Request Message Authenticator (16byte) Authentication Data (16byte) ICV (16byte) Authenticator (16byte) ICV (16byte) Extract HMAC-MD5 (AP-key) HMAC-MD5 (User-key) Compare Probe Response Probe Response Seed User ID Check Timestamp Transmit Timestamp SSPN ID Check SSPN ID AP ID STA-AP security type: HMAC-MD5/AES-CBC-128bit, AP-AS security type : HMAC-MD5

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 14 Authentication (Cont.) APASSTA Authentication Success Message Authentication Data (16byte) ICV (16byte) MD5 HMAC-MD5 Authenticator (16byte) Access Request Message Seed (16byte) Session Key (16byte) ICV (16byte) Extract HMAC-MD5 (User-key) Extract HMAC-MD5 (AP-key) Hashed ICV (16byte) Session Key DD (16byte) XOR Access Approval Message Authenticator (16byte) HMAC-MD5 (AP-key) Access Approval Message Authenticator (16byte) Compare Extract HMAC-MD5 (AP-key) ICV (16byte) Hashed ICV (16byte) Extract HMAC-MD5 (AP-key) Session Key DD (16byte) Session Key (16byte) Extract XOR Authentication Success Message Authentication Data (16byte) ICV (16byte) MD5 HMAC-MD5 ICV (16byte) Seed (16byte) Session Key (16byte) HMAC-MD5 (User-key) Compare Extract Network Info (Optional) Transmit

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 15 Data Message Format (HMAC-MD5/AES-CBC-128bit) IVh Payload Padding (variable length) ICV Encrypted Portion 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 IEEE Header Expansion of the IEEE header will be needed.

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

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

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 18 Multiple SSPN support Base Router (BR) AS SSPN: A AS SSPN: B Access Request for SSPN B Access Request for SSPN A Access Reply Access Reply Base Router (BR) AS Domain: foo AS Domain: bar Access Request for Domain bar and foo Access Reply Access Reply Access Request for Domain foo (a) By BR configuration(b) By AS proxy

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 19 Power Consumption Consideration (R3M1) The STA must send at least 1 probe request in each channel. It means the power consumption of the STA is higher than passive scan. The STA sends only 1 frame for authentication and session key exchange. It means the power consumption is lower than authentication method like EAP.

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 20 Security Consideration (R3M3) Eavesdropping –Protected by cipher Fake AP –Protected by mutual authentication Session Hijack (R3P2) –Protected by authentication of all frames

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 21 Requirements R3N1 –Solved by probe request and probe response R3N3 –This framework allows authentication with multiple SSPNs R3P2 –Solved by authentication of every frame R3S1 –Described R3S2 –Described R3M1 –Described R3M3 –Described

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 22 Future Work Designing the extended IEEE header Designing the formats of the messages Adapting the proposal to the requirements

doc.: IEEE /1093r0 Submission November 2005 Hitoshi MORIOKA, ROOT Inc.Slide 23 Questions and Comments?