doc.: ieee 802.11-05/1093r0 submission november 2005 hitoshi morioka, root inc.slide 1 misp based...

November 2005

Hitoshi MORIOKA, ROOT Inc.

Slide 1

doc.: IEEE 802.11-05/1093r0

Submission

MISP based Authentication Framework

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:// ieee802.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 <[email protected]> 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 <[email protected]>.

Date: 2005-11-07

Name Company Address Phone email Hitoshi MORIOKA ROOT Inc. 2-1-22-307 Momochihama,

Sawara-ku, Fukuoka 814-0001 JAPAN

+81-92-832-3391 [email protected]

Hiroshi MANO ROOT Inc. 8F TOC2 Bldg. 7-21-11 Nishi-Gotanda, Shinagawa-ku, Tokyo 141-0031 JAPAN

+81-3-5719-7631 [email protected]

Authors:

November 2005


Slide 2

doc.: IEEE 802.11-05/1093r0

Submission

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

November 2005


Slide 3

doc.: IEEE 802.11-05/1093r0

Submission

System Architecture

AP AP

AuthenticationServers (AS)

STA

AP AP

STA

AuthenticationServers (AS)

SSPN ASSPN B

November 2005


Slide 4

doc.: IEEE 802.11-05/1093r0

Submission

Pre-shared Information

AP ASSTA

• 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

November 2005


Slide 5

doc.: IEEE 802.11-05/1093r0

Submission

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.

November 2005


Slide 6

doc.: IEEE 802.11-05/1093r0

Submission

Protocol Overview

STA AP AS

Authentication RequestAccess Request

Access AuthorizationAuthentication Success

Associate

• Mutual Authentication• Session Key Sharing• Upper Layer Information (Optional)

Probe Request

Probe Response

November 2005


Slide 7

doc.: IEEE 802.11-05/1093r0

Submission

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

November 2005


Slide 8

doc.: IEEE 802.11-05/1093r0

Submission

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

November 2005


Slide 9

doc.: IEEE 802.11-05/1093r0

Submission

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)

November 2005


Slide 10

doc.: IEEE 802.11-05/1093r0

Submission

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

November 2005


Slide 11

doc.: IEEE 802.11-05/1093r0

Submission

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)

November 2005


Slide 12

doc.: IEEE 802.11-05/1093r0

Submission

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,

November 2005


Slide 13

doc.: IEEE 802.11-05/1093r0

Submission

Authentication

AP ASSTA

AuthenticationRequestMessage

AuthenticationData (16byte)

ICV (16byte)

MD5

HMAC-MD5(User-key)

AuthenticationRequestMessage


AccessRequestMessage

ICV (16byte)

Extract

Authenticator (16byte)

MD5

HMAC-MD5(AP-key)




ICV (16byte)


ICV (16byte)

Extract

Extract

HMAC-MD5(AP-key)

HMAC-MD5(User-key)

Compare

Compare

ProbeResponse

ProbeResponse

Seed

User IDCheck Timestamp

TransmitTransmit

Transmit

Timestamp

SSPN ID

Check SSPN ID

AP ID

STA-AP security type: HMAC-MD5/AES-CBC-128bit,AP-AS security type : HMAC-MD5

November 2005


Slide 14

doc.: IEEE 802.11-05/1093r0

Submission

Authentication (Cont.)

AP ASSTA

AuthenticationSuccessMessage


ICV (16byte)

MD5

HMAC-MD5



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

AccessApprovalMessage


HMAC-MD5(AP-key)

AccessApprovalMessage


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

AuthenticationSuccessMessage


ICV (16byte)

MD5

HMAC-MD5

ICV (16byte)

Seed (16byte)

Session Key (16byte)

HMAC-MD5(User-key)

Compare

Extract

Network Info(Optional)

Transmit

Transmit

November 2005


Slide 15

doc.: IEEE 802.11-05/1093r0

Submission

Data Message Format(HMAC-MD5/AES-CBC-128bit)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

IVh

Payload

Padding (variable length)

ICV

EncryptedPortion

• 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

IEEE802.11 Header

Expansion of the IEEE802.11header will be needed.

November 2005


Slide 16

doc.: IEEE 802.11-05/1093r0

Submission

Encryption, Decryption and Message Authentication(AES-CBC-128bit)

ReceiverSender

DataMessage

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 IEEE802.11 header and the IVh.

IVh

IVl

ICV

DataMessage

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

November 2005


Slide 17

doc.: IEEE 802.11-05/1093r0

Submission

Session Key Updating

Time

Key A

Key B

Authentication

• The session key is identified by the flag in the extended IEEE802.11 header.

• The session key updating interval should be discussed.

November 2005


Slide 18

doc.: IEEE 802.11-05/1093r0

Submission

Multiple SSPN support

Base Router(BR)

ASSSPN: A

ASSSPN: B

AccessRequest forSSPN B

AccessRequest forSSPN A

AccessReply

AccessReply

Base Router(BR)

ASDomain: foo

ASDomain: bar

AccessRequest forDomain barand foo

AccessReply

AccessReply

AccessRequest forDomain foo

(a) By BR configuration (b) By AS proxy

November 2005


Slide 19

doc.: IEEE 802.11-05/1093r0

Submission

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.

November 2005


Slide 20

doc.: IEEE 802.11-05/1093r0

Submission

Security Consideration (R3M3)

• Eavesdropping– Protected by cipher

• Fake AP– Protected by mutual authentication

• Session Hijack (R3P2)– Protected by authentication of all frames

November 2005


Slide 21

doc.: IEEE 802.11-05/1093r0

Submission

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

November 2005


Slide 22

doc.: IEEE 802.11-05/1093r0

Submission

Future Work

• Designing the extended IEEE802.11 header

• Designing the formats of the messages

• Adapting the proposal to the requirements

November 2005


Slide 23

doc.: IEEE 802.11-05/1093r0

Submission

Questions and Comments?

doc.: ieee 802.11-05/1093r0 submission november 2005 hitoshi morioka, root inc.slide 1 misp based...

Documents