doc.: ieee 802.11-05/1093r0 submission november 2005 hitoshi morioka, root inc.slide 1 misp based...
Post on 18-Jan-2016
219 Views
Preview:
TRANSCRIPT
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 <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>.
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 hmorioka@root-hq.com
Hiroshi MANO ROOT Inc. 8F TOC2 Bldg. 7-21-11 Nishi-Gotanda, Shinagawa-ku, Tokyo 141-0031 JAPAN
+81-3-5719-7631 hmano@root-hq.com
Authors:
November 2005
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
Slide 13
doc.: IEEE 802.11-05/1093r0
Submission
Authentication
AP ASSTA
AuthenticationRequestMessage
AuthenticationData (16byte)
ICV (16byte)
MD5
HMAC-MD5(User-key)
AuthenticationRequestMessage
AuthenticationData (16byte)
AccessRequestMessage
ICV (16byte)
Extract
Authenticator (16byte)
MD5
HMAC-MD5(AP-key)
AccessRequestMessage
Authenticator (16byte)
AuthenticationData (16byte)
ICV (16byte)
Authenticator (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
Hitoshi MORIOKA, ROOT Inc.
Slide 14
doc.: IEEE 802.11-05/1093r0
Submission
Authentication (Cont.)
AP ASSTA
AuthenticationSuccessMessage
AuthenticationData (16byte)
ICV (16byte)
MD5
HMAC-MD5
Authenticator (16byte)
AccessRequestMessage
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
Authenticator (16byte)
HMAC-MD5(AP-key)
AccessApprovalMessage
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
AuthenticationSuccessMessage
AuthenticationData (16byte)
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
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
Hitoshi MORIOKA, ROOT Inc.
Slide 23
doc.: IEEE 802.11-05/1093r0
Submission
Questions and Comments?
top related