802.1 af discussion First two slides are my picture of ae requirements - these may need some refining Next slide is my interpretation of KSP implementation.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0165r1 SubmissionPäivi Ruuska, NokiaSlide 1 Implementation aspects of a coexistence system Notice: This document has been.
Advertisements

Discussion of KaY Key Exchange and Management Interface to SecY
802.1AF - directions define requirements to find and create connections in terms of Discovery - Authentication - Enable 1.Discover of what can be done.
EAP STATE Machine Proposal
Call Server LIS VPC ESGW SR Manhattan PSAP LO=Wall St Route=Manhattan PSAP The Location Object (LO) is provided in the call setup information to the Call.
External User Security Model (EUSM) for SNMPv3 draft-kaushik-snmp-external-usm-00.txt November, 2004.
EAP Channel Bindings Charles Clancy Katrin Hoeper IETF 76 Hiroshima, Japan November 08-13, 2009.
Secure Network Bootstrapping Infrastructure May 15, 2014.
H. 323 Chapter 4.
Grid Computing, B. Wilkinson, 20045a.1 Security Continued.
1 Lecture 17: SSL/TLS history, architecture basic handshake session initiation/resumption key computation negotiating cipher suites application: SET.
Cryptography and Network Security
SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
7-1 Chapter 7 – Web Security Use your mentality Wake up to reality —From the song, "I've Got You under My Skin“ by Cole Porter.
1 Semester 2 Module 4 Learning about Other Devices Yuda college of business James Chen
Public Key Infrastructure (PKI) Providing secure communications and authentication over an open network.
1 © NOKIA MitM.PPT/ 6/2/2015 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM) The Insecurity of Tunnelled Authentication Protocols N. ASOKAN, VALTTERI NIEMI,
Apr 2, 2002Mårten Trolin1 Previous lecture On the assignment Certificates and key management –Obtaining a certificate –Verifying a certificate –Certificate.
1 © NOKIA MitM.PPT/ 6/2/2015 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM) The Insecurity of Tunnelled Authentication Protocols N. ASOKAN, VALTTERI NIEMI,
Cryptography and Network Security Chapter 17
A Study of Mobile IP Kunal Ganguly Wichita State University CS843 – Distributed Computing.
Chapter 5 Secure LAN Switching.  MAC Address Flooding Causing CAM Overflow and Subsequent DOS and Traffic Analysis Attacks.
EEC 688/788 Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
CCNA Exploration Semester 3 Modified by Profs. Ward and Cappellino
Chapter 8 Web Security.
Session Policy Framework using EAP draft-mccann-session-policy-framework-using-eap-00.doc IETF 76 – Hiroshima Stephen McCann, Mike Montemurro.
THE OSI MODEL KUDIRAT FAWEHINMI COSC 541.
 It defines the format of the frame to be exchanged between devices.  It defines how two devices can negotiate the establishment of the link and the.
Network Security1 – Chapter 5 (B) – Using IEEE 802.1x Purpose: (a) port authentication (b) access control An IEEE standard
Wireless and Security CSCI 5857: Encoding and Encryption.
Doc.: IEEE /0104r0 Submission July 2010 Alex Reznik, et. al. (InterDigital)Slide 1 Channel Selection Support in TVWS Date: Authors:
Network Security – Part 2 (Continued) Lecture Notes for May 8, 2006 V.T. Raja, Ph.D., Oregon State University.
Ad Hoc Networks Curtis Bolser Miguel Turner Kiel Murray.
BY MOHAMMED ALQAHTANI (802.11) Security. What is ? IEEE is a set of standards carrying out WLAN computer communication in frequency bands.
Distributed systems – Part 2  Bluetooth 4 Anila Mjeda.
1 Section 10.9 Internet Security Association and Key Management Protocol ISAKMP.
Introduction to Secure Sockets Layer (SSL) Protocol Based on:
Shambhu Upadhyaya Security –Upper Layer Authentication Shambhu Upadhyaya Wireless Network Security CSE 566 (Lecture 10)
Cryptography and Network Security (CS435) Part Fourteen (Web Security)
Web Security : Secure Socket Layer Secure Electronic Transaction.
PRESENTED BY P. PRAVEEN Roll No: 1009 – 11 – NETWORK SECURITY M.C.A III Year II Sem.
Authentication Mechanism for Port Control Protocol (PCP) draft-wasserman-pcp-authentication-01.txt Margaret Wasserman Sam Hartman Painless Security Dacheng.
1 Security Protocols in the Internet Source: Chapter 31 Data Communications & Networking Forouzan Third Edition.
Wireless LAN Security. Security Basics Three basic tools – Hash function. SHA-1, SHA-2, MD5… – Block Cipher. AES, RC4,… – Public key / Private key. RSA.
CP-a Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS Keith Drage.
Chapter 4 Using Encryption in Cryptographic Protocols & Practices.
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Doc: IEEE xxx Submission March 2015 Jeongseok Yu et al., Chung-Ang University Project: IEEE P Working Group for Wireless Personal.
IETF 57 PANA WG PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt) Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin.
Wireless Network Security CSIS 5857: Encoding and Encryption.
An Introduction to Mobile IPv4
Channel Binding Support for EAP Methods Charles Clancy, Katrin Hoeper.
IPSec is a suite of protocols defined by the Internet Engineering Task Force (IETF) to provide security services at the network layer. standard protocol.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—1-1 BGP Overview Establishing BGP Sessions.
Doc.: IEEE /0098r0 Submission July 2010 Alex Reznik, et. al. (InterDigital)Slide Security Procedures Notice: This document has been.
IP Security (IPSec) Matt Hermanson. What is IPSec? It is an extension to the Internet Protocol (IP) suite that creates an encrypted and secure conversation.
Port Based Network Access Control
Doc.: IEEE /2952r2 Submission Dec 2007 L.Chu Etc.Slide 1 Simplified DLS Action Frame Transmission in 11Z Date: Authors:
Richard EAP-WAI Authentication Protocol Stockholm, IETF 75th draft-richard-emu-wai-00.
Open issues with PANA Protocol
PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt)
Cryptography and Network Security
IPSec VPN Chapter 13 of Malik.
Net 323: NETWORK Protocols
– Chapter 5 (B) – Using IEEE 802.1x
Cryptography and Network Security
Charles Clancy Katrin Hoeper IETF 73 Minneapolis, USA 17 November 2008
Agenda retrospective - B. Aboba Lunch
Presentation transcript:

802.1 af discussion First two slides are my picture of ae requirements - these may need some refining Next slide is my interpretation of KSP implementation of CA then discovery with and without preshare CAK Remaining slides talk about af requirements and issues –Requirements for discovery A proposal for “device” authorization –Issues with Race Conditions (and a security proposal) whether EAP and RADIUS are appropriate This is meant to be a discussion support, not a specification The discussion might be best broken into a)initialization - slide 1- 13, and b) AS/backend issues slide (overlap provides a segway)

A B D C CA abcd SC A SC B CA = Secure Connection Association SC i = Secure Channel from Station (I) to all stations on CA SA ij = Security Association Station (i) to Station (j) SAK ij = Secure Association Key instance (i) for Station (j) SC C SC D

KaY i = Key Agreement Entity - one or more at each Station SecY i = Security Entity - one (or more?) at each Station Announcement = Procedure by which KaY announces its presence and desire to join a CA Discovery = Procedure by which KaY discovers other KaYs participating in or attempting to join a CA A B D C CA abcd SecY A Internal DB SA AB - [SAK B ] SA AC [SAK C ] SA AD [SAK D ] SAK A

A B D C CA KSP implementation of CA (my intrepretation) CA defined by (has) common CA Key - CAK and Key Generating Key - KGK All Stations generate the same SAK from the common KGK (and other info descrubed in Mick’s dicument) to protect transmit by all stations connected to the CA

A B D C CA CAK KGK KaY-A SAK n. Connecting to CA requires setting CAK and KGK -- could be hand configured or done with some initialization protocol KaY-A connects to CA

A B D C CA CAK=null KGK=null KaY-A request connection to CA Respond to request on behalf of CA establish dialog with KaY-A Establishing CAK, KGK for station attempting to join CA

A B D C CA Connection dialog between A, asking for CAK and KGK for CA and D which is already in CA and which can give the CAK and KGK to A if it is satisfied with the conversation Note: D is acting “for” CA. If it authoriizes A then A is authorized to join CA ?- what protection supports the connection between A and CA

Functions for a KaY Discover other KaY in appropriate CA IF Connecting - Authorize with CA through other KaYs –Create SA ij with (each?) KaY In KSP protoocl document only one SA is needed Get/Generate CAK and KGK Create SAK for itself and share with each authorized KaY using the SA for that KaY in KSP all KaYs in the CA use the same SAK Update SAK periodically use existing SAK to select the next (see KSP doc)

Discovery- Generic These are assumptions for “generic” KaY- (note: KSP simplifies these as shown on next slide) –Each Kay Periodically announces presence If KaY hears announcement it determines if it knows the announcing KaY –If it sees a new KaY (to it) then it establishes an authorization dialog with it and attempts to create a SA If a KaY attempts to join a CA it announces its presence and all existing KaYs attempt to create and SA with it If two KaYs attempt to join a CA, each announces its presence. It is possible that two (or more) KaYs may try to authorize each other. The authorization dialog must be able to detect and negotiate requests to a single dialog.

Discovery- KSP-CA These are assumptions for KSP style KaY- KSP simplifies generic requirements –Each Kay Periodically announces presence using CAK to protect / provide integrity If KaY hears announcement from another KaY knowing the CA –It checks the Key Number and updates SAK if necessary »see KSP document for details –If a KaY attempts to join a CA but does not know the CAK, the proper procedure does not yet seem defined. Possible approach is –Announce its presence to all KaYs currently joined to CA –One of connected CAs responds and authorizes the supplicant KaY –Supplicant and respondent have authorization dialog –If respondent is satisfied it gives the Supplicant the CAK and KGK

Authorization description of KSP seems to be functionally very similar to key exchange for 11i As with 11i, KSP does not define protocol for getting the common key (KGK in KSP) that lets stations know each other –KSG needs CAK and KGK, 11i needs Master Key –neither describes a specific authorization protocol –11i does define use of 1.X and EAP as protocol for authorization –1.X defines controlled/uncontrolled port as way of controlling data while in authorization mode –nothing defined for KSG

CA Authorization dialog initializationl This protocol that allows a KaY to identify itself and get CAK and KGK –not needed if CAK/KGK is hand configured in KaY –needed to allow KaY to request admission to CA and get CA and KGK from CA Getting CAK requires a conversation that does not use the CAK (of course) –some ability for DOS attacks during any unprotected part of this conversation

Announcement (requirements) A KaY attempting to join a CA announces itself to the CA –The announcement is on a Connectivity Association which allows stations to talk Announcement includes a System and port id (? I think this is right) Announcement (may?) include a CA identifier – to describe the CA it wants to join Announcement is open to DOS since no SA exists Announcement initiates Authorization Dialog(s)

Announcement (initialization proposal) To limit the DOS possibilities of sending unknown Announcements it is proposed to *allow* KaY to use provate asymetric key to “sign” Announcement Announcer sends public key with announcement signed by private Key Receiver verifies the signature using the included public key –, creates symmetric key for authorization dialog – signs reply (including symmetric key) with public key, Symetric key is not used to protect Authorization dialog –this avoids DOS attacks that disrupt the conversation –authorization is of a KaY known to have received the symetric key. If authorization dialog succeeds CAK/KGK can be sent to the proposer [comparing this to Johv Viega’s description of embedding credentials in hardware, this seems an alternative way of binding a hardare id to followon authentication on channel protected by the credential]

Authorization (and Authentication) dialog requirements Two KaYs attempting to create a SA between themselves will have an “authorization” dialog between themselves –if included the initialization dialog is part of this The authorization dialog will be done using some protocol between stations. –EAP has been used in 1.X but seems to have some problems here Each station may use a backend Authorization Server to support all or part of the dialog Authorization Dialog will often include authentication dialog

Authorization dialog race conditions KaY may be set to support a single authentication or require dialog in both directions –I.e. the CA may want to authenticate and authorize the applicant and the applicant may want to authenticate and authorize the CA If single dialog is required to do mutual authentication, and it is possible that two KaY simultaneously initiate an applicant dialog, one will send a special response that indicates that it is terminating the method –One KaY will then act as the “applicant” and the other as the “CA” in further dialogs

Authorization entities KaY i KaY j AS Connectivity Association (e.g. Ethernet) IP connection CA backend KaYi helper Note that SA to support attaching KaY is not the same used if the KaY is acting for the CA

Possible Authorization Sessions KaY i KaY j AS i Possible Dialogs Kay-KaY - create “provisional” SA using assigned or created PK - use pSA to have initial conversation Either or both KaYs may decide to use a backend AS to get information requested by the other KaY Either or both KaYs may request a backend to have a conversation with the other KaY (or its backend) Each KaY will (presumably) control whether conversation is done by KaY or by a particular backend Note KaYi authenticates that it is talking to the right CA, while KaYj is authorizing KaYi to join the CA

Authorization Dialog(s) KaY i KaY j AS KaY to Jay AS to AS Dialog between KaYs may include initial (device) authentication and creation of authorization dialog key EAP Dialog between ASs is typically an EAP method

Examining RADIUS and EAP as KaY/AS communication KaY i KaY j AS Radius Req Radius Resp EAP Request EAP RequestRadius Req EAP Request This is non-standard and is not possible with existing standards examining the possibility

Other Radius/EAP Issues in dual AS architecture RADIUS typically carries assertions from AS to NAS, based on results of EAP method –This could work with KaYs in dual AS mode, allowing each AS to send assertions to its KaY as a result of EAP method Protected Mode EAP methods may use “TLV”s within EAP method to signal from an AS to “peer” talking to NAS –TLV to peer would go to remote AS and information in TLV sent via RADIUS Response to the KaY

Required RADIUS/ EAP Changes (if used) KaYs use common group key (CAK/KGK) to support a “provisional” SA to protect data during the Initialization/Authorization step when using a back end the uncontrolled port on KaY routes to AS IP is used on uncontrolled ports to talk betwen KaYs and let KaYs forward to AS for CA if appropriate –each KaY configured to route to the same CA-AS AS and KaY have a preestablished Security Association Conversation might use WS protocol- problem is talking IP when from a level 2 port that is not yet attached to the net –Seems worth working out a mechanism

Getting the CAK/KGK backend requirements KaYs use initial key to support a “provisional” SA to protect data during the Initialization/Authorization step uncontrolled port on KaY routes to AS IP is used on uncontrolled ports to talk betwen KaYs and let KaYs forward to AS if appropriate –each KaYs may routes to a different AS, AS and KaY have a preestablished Security Association Conversation might use WS protool or EAP/IP (PANA) –Seems plausible alternative to RADIUS/EAP