Doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote Authorization Date: 2012-08-31 Authors: NameCompanyAddressPhoneemail René StruikStruik Security Consultancy Toronto ON, CanadaUSA: +1 (415) 690-7363 Toronto: +1 (647) 867-5658 Skype: rstruik rstruik.ext@gmail.com

doc.: 11-12-0794r3 Submission August 31, 2012 Scope  Security,  Higher-Layer Aspects (only piggy-back “hook”)

doc.: 11-12-0794r3 Submission August 31, 2012 Conformance with Tgai PAR & 5C Conformance QuestionResponse Does the proposal degrade the security offered by Robust Security Network Association (RSNA) already defined in 802.11? No Does the proposal change the MAC SAP interface?No Does the proposal require or introduce a change to the 802.1 architecture?No Does the proposal introduce a change in the channel access mechanism?No Does the proposal introduce a change in the PHY?No Which of the following link set-up phases is addressed by the proposal? (1) AP Discovery (2) Network Discovery (3) Link (re-)establishment / exchange of security related messages (4) Higher layer aspects, e.g. IP address assignment 3, 4

doc.: 11-12-0794r3 Submission August 31, 2012 Background The following contributions provide background: Presentations:  11-11-1408-13-00ai-Notes-on-TGai-Security-Properties  11-12-0574-00-00ai-security-and-ease-of-use-considerations-for-tgai Note: Theses presentations are included in the appendix Specification text:  11-12-0052-02-00ai-fils-authentication-with-certified-public-keys  11-12-0054-00-00ai-fils-password-based-authentication  11-12-0055-00-00ai-fils-symm-key-based-authentication Note: This proposal only refers to public-key based FILS mechanisms Updates provided now:  Details on cryptographic protocol ingredients (mostly already voted on in July session, but here shown in context) (Alignment with EAP-RP based protocol, so as to strive for unified message flows and state machines, still to follow [in updated version])

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 5 Proposal re-cap

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy) Network Joining – only Authorization by Third Party Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. e.g., subscription credentials for WiFi access e.g., IP address assignment AB CA Authentication Authorization Configuration Routing ISP Gateway Author. e.g., check identity with white list (ID A  S?) (ID B  Ŝ?) B: Query {ID A, ID B } Response {(ID A, Credentials A ), (ID B, Credentials B )} Slide 6 Does require offline CA Key provisioning easy in heterogeneous trust settings (no lock-in with, e.g., ISP) All nonlocal communications with any (secured) transport protocol frames

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 7 Mapping Key Establishment Options to 802.11 Architecture without 3 rd Party Authentication  AB Random X Random Y MAC over messages Key Establishment Key Confirmation AB Random X Random Y MAC over messages Key Establishment Key Confirmation Step 1: Alignment of protocol flows Step 2: Mapping to 802.11 Messaging AB Authentication Request Authentication Response Association Request Association Response Key Establishment Key Confirmation   AB Authentication Request Authentication Response Association Request Association Response 802.11 Beacon Key Exchange Protocols:  Public key with Certificates

doc.: 11-12-0794r3 Submission August 31, 2012 Optimized Mappings Key Establishment to 802.11 Architecture With only 3 rd Party Authorization, DHCP IP Address Assignment AB Random X, Certificate Q A Random Y, Certificate Q B MAC over messages MAC over messages & KDC Id A, Id B DHCP server Authorization (Id A ) Authorization (Id B ) DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {Id A, Id B }) IP Address Assignment STAAP Authentication Request Authentication Response Association Request Association Response AS Authorization Request DHCP server Authorization Response DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {STA,AP}) IP Address Assignment René Struik (Struik Security Consultancy) &DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) * Authorization support by third party is optional. Device roles are conceptual only; actual role to device mapping implementation-dependent. {& Authorization Response AP} { & Authorization Response Id B } IP address assignment serves as illustration only of more general configuration step (in agressive mode); may be preferred to postpone till key confirmation stage.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 9 Details on cryptographic building blocks

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 10 Authenticated Public-Key Key Agreement (1) AB Random X, KeyInfo A Random Y, KeyInfo B MAC A over messages MAC B over messages Key contributions. Each party pseudo-randomly generates a short-term (ephemeral) public key pair and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the static and ephemeral elliptic curve points it received from the other party and based on the static and ephemeral private keys it generated itself. Due to the properties of elliptic curve, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the long-term static key of the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. Note: KeyInfo that allows identification of static public keys do not need to be communicated, if pre-established between parties. This does, however, require storage of status information. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 11 Authenticated Public-Key Key Agreement (2) Initial Set-up  Publication of system-wide parameters  Publication of elliptic curve domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used  Distribution of authentic long-term public keys Q A and Q B Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Long-term private keys d A and d B private to Party A, resp. Party B, and valid during execution of protocol  Short-term private keys x and y private to Party A, resp. Party B and valid during execution of protocol  Each party shall have access to the public key Q CA used to certify the other party’s long-term key Note: (d A, Q A ), (x, X) and (d B, Q B ), (y, Y) are long-term and short-term public key pairs of A, resp. B Security Services  Key agreement between A and B on the shared key K=KeyMap(d A, x, Q B, Y )=KeyMap(d B, y, Q A, X )  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party  Esoteric properties: unknown key-share resilience, session key retrieval resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 12 Key Info Field Function of KeyInfo field Distribution of authentic long-term public keys Q A and Q B Options  Device Certificates: KeyInfo A = “Cert CA (Id A, Q A )”Example: X509v3-style, etc.  Logical separation of identifier space and public keys (same Id A can get new public key Q A )  Device configuration does not bind elements of identifier space and public keys  Assignment of identifier could precede crypto operations (e.g., transceiver chip with Id, with higher-layer crypto and binding added later on when building system)  Independent verification of authenticity binding possible, trivial key extraction  Authorization based on management of device identities  Requires CA who binds elements of identifier space and public keys  Manual “Certificates”: KeyInfo A = “(Id A, Q A )”Example: hashed public keys, etc.  Logical binding of identifier space and public keys (new public key Q A results in loss of Id A )  Device configuration binds elements of identifier space and public keys  Assignment of identifiers cannot precede crypto operations (e.g., transceiver chip can only obtain Id once higher-layer crypto added later on when building system)  Independent verification of binding possible, trivial key extraction  Authorization based on management of public-key related identities  Does not require CA for authentic binding, but no evidence on “sanity checks” key generation Both require authentic authorization operations (device provisioning, personalization, etc.)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 13 Key Computation Function of key computation Establishment of shared secret key K Option  Unauthenticated Diffie-Hellmann: “K= xY”  Cryptographic scheme standardized with NIST SP 800-56A, ANSI X9.63-2001  Computationally efficient Key Confirmation Function of key confirmation Provides evidence that party computed the right key and actively participated Option  Authentication code MAC A over fields including “Id A || Id B || X || Y || [Text A ]” with key (derived from) K  Cryptographic scheme standardized with NIST SP 800-56A, NIST SP 800-38C/D, ANSI X9.63-2001 Note: The (optional) text field [Text A ] allows piggy-backing of additional info from A to B with protocol flows (configuration info and the-like)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 14 Implicit Key Authentication Function of key authentication Verification that only party that may be capable of computing the key is indeed its perceived communicating party Options 1. KeyInfo verification  Device Certificates: KeyInfo A = “Cert CA (Id A, Q A )”  X509v3-style ECDSA certificate, with SHA-256 hash function  Cryptographic scheme standardized with FIPS Pub 180-2, FIPS Pub 186-3, ANSI X9.63-2001  Certificate scheme standardized with RFC 3280, RFC 5480  Manual “Certificates”: KeyInfo A = “(Id A, Q A )”  Same as device certificate, but now without signature field  Scheme standardized with IETF: approved draft farrell-decade-ni-10 (“Naming things with hashes”) Note: KeyInfo A can be locally stored as hashed version (e.g., using SHA-256 hash function) 2. Implicit key authentication Signature (for A)  A over fields including “Id A || X ” using A’s private key d A  Cryptographic scheme standardized with FIPS Pub 180-2, FIPS Pub 186-3, ANSI X9.63-2001

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 15 Curve Options Options  Prime curve: P-256  FIPS Pub 186-3, NIST SP 800-56a, ANSI X9.63-2001  Binary curve: K-283  FIPS Pub 18-3, NIST SP 800-56a, ANSI X9.63-2001 No point compresssion Notes:  Prime curves:  more vulnerable to crypto implementation attacks (side channel/fault attacks) and denial of service attack;  most suitable when implemented on platform with efficient integer arithmetic;  Binary curves:  less vulnerable to crypto implementation attacks (side channel/fault attacks) and denial of service attacks;  most suitable for resource-constrained, sensor-style platforms (e.g., 802.11af, low energy mode)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 16 Details on message formats, state machines, etc.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 17 (DETAILS STILL TO FOLLOW) Alignment with EAP-RP protocol, so as to exploit commonalities and strive for single state machine (which could also align with SAE protocol 802.11s)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 18 Summary

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 19 Key Establishment Options The following protocol options for key establishment are provided: Symmetric-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a) Both devices do share a secret (master) key beforehand. 12/055: fils-symm-key-based-authentication (b) Both devices do not share a secret key, but each shares a key with a mutually trusted third party. (c) Both devices do not have certificates, but each shares a key with a mutually trusted third party. Public-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a)Both devices do have (access to) a certificate of their public key, issued by a mutually trusted third party (certificate authority). 12/052: fils-authentication-with-certified-public-keys (b)Both devices do not have (access to) a certificate of their public key. (c)Both devices do have access do share a weak secret key. 12/054: fils-password-based-authentication (d)Both devices do not have (access to) a certificate of their public key, but cannot verify each others certificate. 12/052: fils-authentication-with-certified-public-keys All public-key schemes: prime curve, ECDSA-P256-SHA-256, no CRLs/OCSP, etc. (may include short-lived certs, depending on policy) Other features: built-in algorithm agility, including on curve domain parameters (this includes binary vs. prime curves) NOTE: Binary curves may be better suited; Design choices influenced need for efficiency, low hassle deployment, and IPR considerations Proposed Design Parameters NOT CAST IN STONE – MOST “REALISTIC” ASSESSMENT Others do this (e.g., 11/1488) Suggest not to do

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 20 Summary (1) 1.Proposed Schemes (a) Key agreements: ECDH with signed exponents (b) Curves: P-256; K-283 (c) Certificates: X509-style w/ECDSA; (hashed) public keys 2.Implementation with 802.11-Style Architectures Use authentication request/response and association request/response Use piggy-backing to carry configuration information 3.Considerations  Standards-compliance: NIST SP 800-56a, FIPS 180-2, FIPS 186-3, RFC 5480, NIST SP 800-38  Cryptographic scrutiny: all well-studied  Exploiting commonalities state machines, protocol flows of all proposed options  Works with “backbone” Access Point – Authentication Server approaches for authorization/ (& DHCP) 4.Room for Further Technical Improvements (a) Use optimized authenticated key agreement scheme: was: ECC: 1 offline, 1 variable; ECDSA: 1 sign, 2 verify would be: ECC: 1 offline, 1 ½ online; ECDSA: 1 verify (b) Use elliptic curve better suited for hardware/low-energy implementations: was: prime curve P-256 would be: binary curve K-283

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 21 Summary (2) 5.Room for Further Enhancements of Functionality (a) Provide optional anonymity: was: Ids of STA and AP are publicly known would be: Ids of STA and AP only become known to actors in protocol and, potentially, KDC No impact on #protocol flows, slight increase of computational cost (under the hood) (b) Auto-renewal long-term keying material: was: no facility with text in 12/052, 12/055 would be: facility to push new certificates, symmetric-key certs No impact on #protocol flows, new IE Note: could be used to implement low-hassle key management (e.g., short-lived certs, no CRLs) (c) Auto-synchronization: was: no facility with joining protocol to synch info on need-be basis would be: facility to synch data if needed No impact on #protocol flows, secure; new IE; in line with ideas presented (e.g., in 11/1169r1) Note: could be used to cross-certify if no common CA root key 6.Initial set-up requirements key agreement schemes (1) certified public-key based: devices need certificate; verifiers need root key, authorization lists (2) “manual” public-key based: verifiers need authentic installation “manual certs” of all communicating parties

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 22 Motions

doc.: 11-12-0794r3 Submission August 31, 2012 Motions - Recap from July 2012 session [all passed]) Motion 1 - Add the following text to Subsection 4.1 “Pre-established security context” of the Security Framework Document: The draft specification shall include support for a FILS authentication mechanism that does not require online involvement of a third party for authentication (of course, it may involve it for authorization and does not preclude online involvement for authentication). Motion 2 - Add the following text to Subsection 4.1 “Pre-established security context” of the Security Framework Document: The draft specification shall include support for a public-key based authenticated key agreement scheme as a mechanism for fast FILS authentication. Motion 3 - Add the following text to Subsection 4.1 “Pre-established security context” of the Security Framework Document: The draft specification shall include support for a public-key based authenticated key agreement scheme based on NIST approved schemes using ECDH and ECDSA at 128-bit cryptographic bit strength. Motion 4 - Amend the motions #1, #2, #3 previously adopted to replace “Security Framework Document” by “Specification Framework Document”.

doc.: 11-12-0794r3 Submission August 31, 2012 New Motion #1 Add the following text to Subsection 4.1 “Pre-established security context” of the Security Framework Document: The draft specification shall include support for a public-key based authenticated key agreement scheme based, where the underlying elliptic curve is one of the NIST curves with 128-bit cryptographic bit strength specified in FIPS Pub 186-3. Moved: Seconded: Y/N/A: Some more motions to make sure we capture the crypto parts properly, so that this is clear even if protocol flows, formatting will change a little bit over time... Details to follow in updated version

doc.: 11-12-0794r3 Submission August 31, 2012 New Motion #2 Include the scheme as specified in 12/052r3 Actually, still wish to align this document with EAP-RP proposals, so as to make this more cool, etc. So, this motion is just a placeholder of “things to come” for now. Moved: Seconded: Y/N/A:

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 26 Back-up Slides (from presentations 11/1408r13)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 27 Actors A B KDC CA Client  This device may move in and out of networks (that may be alien to it) and may have little network management functionality on board. Key words: nomadic, promiscuous, constrained. Access point  This device may be more tied into a relatively stable infrastructure and may have more support for network management functionality or have reliable access hereto (e.g., via a back-end system). Key words: anchor, semi-stable connectivity, access portal. Server  This device provides stable infrastructure and network management support, either intra-domain or inter domain (thereby, offering homogeneous or even heterogeneous functionality). Key words: core function, high availability, human-operator support. CA  This device vouches for trust credentials, usually in offline way. Key words: trust anchor. Initiator/responder model All peer-to-peer protocols are role-symmetrical (i.e., the role of initiator/responder roles are interchangeable). Protocols involving a third party assume communications with this third party to take place via the access point (since being the device more tied into infrastructure). Cautionary NOTE − On Limitations of Cryptography  Cryptographic techniques may provide logical assurances as to a device’s identity, where and when communications originated, whom it was intended for, whom this can be read by, etc.  Cryptographic techniques do, however, only provide mechanical assurances and can generally not substitute human authorization decision elements (unless the latter are not important, such as with random, ad-hoc networks).

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 28 Desired Protocol Properties Security-Related  Parties executing a security protocol should be explicitly aware of its security properties  Compromise of keys or devices should have limited effect on security of other devices or services  Attacks should not have a serious impact beyond the time interval/space during/in which these take place  Security protocols should minimize the impact of network outages, denial of service attacks Communication flows  Security protocols should allow to be run locally, without third party involvement, if at all possible  The number of message exchanges for a joining client device should be reduced  Message exchanges should be structured so as to allow parallel execution of protocol steps, if possible Computational cost  Security protocols should not impose an undue computational burden, esp. on joining client devices (An exception here may arise, when recovering from an event seriously impacting availability of the network.) Device capabilities  Dependency on an accurate time-keeping mechanism should be reduced  Computational/time latency trade-offs should be tweaked to benefit those of joining client, if possible  Dependency on “homogeneous trust models” should be reduced, without jeopardizing security properties  Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 29 Network Joining – Authentication vs. Authorization (1) Actors A B KDC CA Client  This device may move in and out of networks (that may be alien to it) and may have little network management functionality on board. Key words: nomadic, promiscuous, constrained. Access point  This device may be more tied into a relatively stable infrastructure and may have more support for network management functionality or have reliable access hereto (e.g., via a back-end system). Key words: anchor, semi-stable connectivity, access portal. Server  This device provides stable infrastructure and network management support, either intra-domain or inter domain (thereby, offering homogeneous or even heterogeneous functionality). Key words: core function, high availability, human-operator support. CA  This device vouches for trust credentials, usually in offline way. Key words: trust anchor. Protocols involving a third party assume communications with this third party to take place via the access point (since being the device more tied into infrastructure). Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization. Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 30 Network Joining – Authentication vs. Authorization (2) Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. ABKDC Authentication (Authentication) Authorization/ Configuration Routing ISP Gateway e.g., subscription credentials for WiFi access e.g., IP address assignment

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 31 Network Joining – With Authentication by Third Party Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. e.g., subscription credentials for WiFi access e.g., IP address assignment ABKDC Authentication Authorization/ Configuration Routing ISP Gateway Author. e.g., check identity with white list (ID A  S?) keys

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 32 Network Joining – Only Authorization by Third Party Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. e.g., subscription credentials for WiFi access e.g., IP address assignment AB CA Authentication Authorization Configuration Routing ISP Gateway Author. e.g., check identity with white list (ID A  S?) (ID B  Ŝ?)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 33 Security Definitions Key Establishment  Protocol whereby a shared secret becomes available to two or more parties for subsequent cryptographic use Key Transport  Key establishment technique where one party creates/obtains the secret and securely transfers it to other(s) Key Agreement  Key establishment technique where the shared secret is derived based on information contributed by each of the parties involved, ideally so that no party can predetermine this secret value Implicit Key Authentication  Assurance as to which specifically identified parties possibly may gain access to a specific key Key Confirmation  Assurance that second (possibly unknown) party has possession of a particular key Explicit Key Authentication  Combination of implicit key authentication and key confirmation Unilateral Key Control  Key establishment protocol whereby one party can influence the shared secret Forward Secrecy  Assurance that compromise of long-term keys does not compromise past session keys Entity Authentication  Assurance of active involvement of second explicitly identified party in protocol Mutual vs. Unilateral  Adjective indicating symmetry, resp. asymmetry, of assurances amongst parties Identity Protection  Assurance as to which specifically identified parties may gain access to identity info Certificate  Credential that vouches for authenticity of binding between a public key and other information, including the identity of the owner of the public key in question Key Possession  Assurance that a specific (possibly unknown) party has possession of a particular key Esoteric properties: Unknown Key Share Resilience, Session Key Retrieval, Key Compromise Impersonation

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 34 Key Establishment Options The following protocol options for key establishment are provided: Symmetric-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a) Both devices do share a secret (master) key beforehand. (b) Both devices do not share a secret key, but each shares a key with a mutually trusted third party. (c) Both devices do not have certificates, but each shares a key with a mutually trusted third party. Public-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a)Both devices do have (access to) a certificate of their public key, issued by a mutually trusted third party (certificate authority). (b)Both devices do not have (access to) a certificate of their public key. (c)Both devices do share a weak secret key. (d)Both devices do have (access to) a certificate of their public key, but cannot verify each other’s certificate. This taxonomy includes all “trust bootstrapping scenarios” that may result in cryptographic assurances.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 35 Peer-to-Peer, or with Involvement Third Party AB (A, B, K AB )(B, A, K AB ) AB KDC (T, A, K AT ) (A, T, K AT )(B, T, K BT ) (T, B, K BT ) Public-Key Key Agreement Symmetric-Key Key Agreement AB (A: a, Q A )(B: b, Q B ) AB KDC Cert CA (A, Q A ) Cert CA (B, Q B ) Q CA A: a, Cert CA (A, Q A ) Q CA B: b, Cert CA (B, Q B ) Q CA (CA: d, Q CA ) CA AB (A, B, {K})(B, A, {K})

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 36 Symmetric-Key Key Agreement (1) AB (A, B, K AB )(B, A, K AB ) AB KDC (T, A, K AT ) (A, T, K AT )(B, T, K BT ) (T, B, K BT ) Symmetric-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a) Both devices do share a secret (master) key beforehand. (b) Both devices do not share a secret key, but each shares a key with a mutually trusted third party. (a) Peer-to-Peer Key Establishment(b), (c) Key Establishment with Inline Third Party (a’) Peer-to-Peer, with Offline Third Party {K}{K} AB (A, B, {K})(B, A, {K}) Key pre-distribution with Blundo scheme

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 37 Symmetric-Key Key Agreement: (a) Peer-to-Peer (1) AB Random X Random Y MAC over messages Key contributions. Each party randomly generates a random bit string and communicates this random challenge to the other party. Key establishment. Each party computes the shared key based on the random challenges generated and received and based on their respective identities, and their shared pre-established key. Due to the properties of the secret key generator, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the pre-established key allegedly shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. Note: Key Info of the pre-shared keys does not need to be communicated, if pre-established between parties. This does, however, require storage of status information. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 38 Symmetric-Key Key Agreement: (a) Peer-to-Peer (1) AB Random X Random Y MAC over messages Key contributions. Each party randomly generates a random bit string and communicates this random challenge to the other party. Key establishment. Each party computes the shared key based on the random challenges generated and received and based on their respective identities, and their shared pre-established key. Due to the properties of the secret key generator, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the pre-established key allegedly shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. Note: Key Info of the pre-shared keys does not need to be communicated, if pre-established between parties. This does, however, require storage of status information. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 39 Symmetric-Key Key Agreement: (a) Peer-to-Peer (2) Initial Set-up  Publication of system-wide parameters  Publication of challenge domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used Constraints  X and Y shall be generated at random (random challenges)  K AB private to Parties A and B Security Services  Key agreement between A and B on the shared key K=h(K AB, X, Y, A, B)  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the other party (Example: ‘pushing buttons’, where human operator controls who is executing protocol. The identities are then only known implicitly, since the human operator knows the devices he wants to securely connect to one another.)  Mutual key confirmation between A and B  No perfect forward secrecy (key compromise compromises all past and future keys)  No unilateral key control by either party

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 40 Symmetric-Key Key Agreement: (a’) Peer-to-Peer (1) AB Random X Random Y MAC over messages Key contributions. Each party randomly generates a random bit string and communicates this random challenge to the other party. Key establishment. Each party computes the shared key based on the random challenges generated and received and based on their respective identities, and their pre-established key. Due to the properties of the secret key generator, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the pre-established key allegedly shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. Note: Key Info of the pre-shared keys does not need to be communicated, if pre-established between parties. This does, however, require storage of status information. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 41 Symmetric-Key Key Agreement: (a) Peer-to-Peer (2) Initial Set-up  Publication of system-wide parameters  Publication of challenge domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used Constraints  X and Y shall be generated at random (random challenges)  K AB private to Parties A and B, uniquely derived from pre-distributed keying material (Blundo scheme) Security Services  Key agreement between A and B on the shared key K=h(K AB, X, Y, A, B)  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the other party (Example: ‘pushing buttons’, where human operator controls who is executing protocol. The identities are then only known implicitly, since the human operator knows the devices he wants to securely connect to one another.)  Mutual key confirmation between A and B  No perfect forward secrecy (key compromise compromises all past and future keys)  No unilateral key control by either party

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 42 Symmetric-Key Key Agreement: (b) Inline 3 rd Party (1) Key contributions. Each party randomly generates a random bit string and communicates this random challenge to the other party. Key establishment. Each party computes the shared key based on the random challenges generated and received and based on their respective identities, and a session key distributed by the third party. Due to the properties of the secret key generator, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the pre-established key allegedly shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. AB Random X Random Y, [k] AT MAC over messages KDC Random X, Random Y Wrapped keys [k] AT,[k] BT 1 3 2 1 2

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 43 Symmetric-Key Key Agreement: (b) Inline 3 rd Party (2) Initial Set-up  Publication of system-wide parameters  Publication of challenge domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used Constraints  X and Y shall be generated at random (random challenges)  K AT private to Parties A and KDC; K BT private to Parties B and KDC  k private to Parties A, B, and KDC. Security Services  Key transport from KDC to A and B of the key k, based on key wrap using K AT, resp. K BT  Key agreement between A and B on the shared key K =h(k, X, Y, A, B)  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the other party (Example: ‘pushing buttons’, where human operator controls who is executing protocol. The identities are then only known implicitly, since the human operator knows the devices he wants to securely connect to one another.)  Mutual key confirmation between A and B  No perfect forward secrecy (key compromise compromises all past and future keys)  No unilateral key control by either party A and B, irrespective of key control by KDC

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 44 Public-Key Key Agreement: (c) with Inline 3 rd Party (1) Key contributions. Each party randomly generates a short-term (ephemeral) public key pair and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the ephemeral elliptic curve point it received from the other party and based on the ephemeral private key it generated itself. Due to the properties of elliptic curve, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the pre-established key allegedly shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. AB Random X Random Y, [ka] AT MAC over messages KDC Random X, Random Y Wrapped keys [ka] AT,[ka] BT 1 3 2 1 2

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 45 Public-Key Key Agreement: (c) with Inline 3 rd Party (2) Initial Set-up  Publication of system-wide parameters  Publication of elliptic curve domain parameters  Publication of key derivation function kdf used Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Short-term private keys x and y private to Party A, resp. Party B and valid during execution of protocol  K AT private to Parties A and KDC; K BT private to Parties B and KDC and valid during execution of protocol  ka private to Parties A, B, and KDC during execution of the protocol Note: (x, X) and (y, Y) are short-term public key pairs of A, resp. B Security Services  Key transport from KDC to A and B of the key ka, based on key wrap using K AT, resp. K BT  Key agreement between A and B on the shared key K=KeyMap(x, Y )=KeyMap(y, X ) and K s =kdf(K,ka,A,B)  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the other party (and rely on the KDC to disclose ka to A and B only)  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party, irrespective of key control by KDC  Esoteric properties: unknown key-share resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 46 Public-Key Key Agreement (1) Public-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a)Both devices do have (access to) a certificate of their public key, issued by a mutually trusted third party (certificate authority). (b)Both devices do not have (access to) a certificate of their public key. (c)Both devices do have access do share a weak secret key. (d)Both devices do have (access to) a certificate of their public key, but cannot verify each others certificate. AB (A: a, Q A )(B: b, Q B ) AB KDC Cert CA (A, Q A ) Cert CA (B, Q B ) Q CA A: a, Cert CA (A, Q A ) Q CA B: b, Cert CA (B, Q B ) Q CA (CA: d, Q CA ) CA (a), (b), (c) Peer-to-Peer Key Establishment(d) Key Establishment with Online Third Party

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 47 Public-Key Key Agreement: (a) with Certificates (1) AB Random X, Certificate Q A Random Y, Certificate Q B MAC over messages Key contributions. Each party randomly generates a short-term (ephemeral) public key pair and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the static and ephemeral elliptic curve points it received from the other party and based on the static and ephemeral private keys it generated itself. Due to the properties of elliptic curve, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the long-term static key of the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. Note: Certificate of the static public keys do not need to be communicated, if pre-established between parties. This does, however, require storage of status information. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 48 Public-Key Key Agreement: (a) with Certificates (2) Initial Set-up  Publication of system-wide parameters  Publication of elliptic curve domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used  Distribution of authentic long-term public keys Q A and Q B, using certificates Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Long-term private keys d A and d B private to Party A, resp. Party B, and valid during execution of protocol  Short-term private keys x and y private to Party A, resp. Party B and valid during execution of protocol  Each party shall have access to the public key Q CA used to certify the other party’s long-term key Note: (d A, Q A ), (x, X) and (d B, Q B ), (y, Y) are long-term and short-term public key pairs of A, resp. B Security Services  Key agreement between A and B on the shared key K=KeyMap(d A, x, Q B, Y )=KeyMap(d B, y, Q A, X )  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party  Esoteric properties: unknown key-share resilience, session key retrieval resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 49 Public-Key Key Agreement: (b) without Certificates (1) AB Random X Random Y MAC over messages Key contributions. Each party randomly generates a short-term (ephemeral) public key pair and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the ephemeral elliptic curve point it received from the other party and based on the ephemeral private key it generated itself. Due to the properties of elliptic curve, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the short-term key of the other party via non- cryptographic means, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 50 Public-Key Key Agreement: (b) without Certificates (2) Initial Set-up  Publication of system-wide parameters  Publication of elliptic curve domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Short-term private keys x and y private to Party A, resp. Party B and valid during the system’s lifetime Note: (x, X) and (y, Y) are short-term public key pairs of A, resp. B Security Services  Key agreement between A and B on the shared key K=KeyMap(x, Y )=KeyMap(y, X )  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the other party (Example: ‘pushing buttons’, where human operator controls who is executing protocol. The identities are then only known implicitly, since the human operator knows the devices he wants to securely connect to one another.)  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party  Esoteric properties: unknown key-share resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 51 Public-Key Key Agreement: (c) with Shared Password (1) AB Random X Random Y MAC over messages Key contributions. Each party randomly generates a short-term (ephemeral) public key pair using shared password to determine some of elliptic curve domain parameters and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the ephemeral elliptic curve point it received from the other party and based on the ephemeral private key it generated itself. Due to properties of elliptic curve and shared domain parameters, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the password shared with the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. 3 2 1

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 52 Public-Key Key Agreement: (c) with Shared Password (2) Initial Set-up  Publication of system-wide parameters dependent on a shared (weak) password  Publication of elliptic curve domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Short-term private keys x and y private to Party A, resp. Party B and valid during the system’s lifetime Note: (x, X) and (y, Y) are short-term public key pairs of A, resp. B Security Services  Key agreement between A and B on the shared key K=KeyMap(x, Y )=KeyMap(y, X )  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B, provided that both parties have a non-cryptographic way of establishing the identity of the party one has shared the password with (e.g., using NFC or key pad). The identities are then only known implicitly, since the human operator knows the devices he wants to securely connect to one another.)  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party  Esoteric properties: unknown key-share resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 53 Public-Key Key Agreement: (d) with Inline 3 rd Party (1) Key contributions. Each party randomly generates a short-term (ephemeral) public key pair and communicates this ephemeral public key to the other party (but not the private key). Key establishment. Each party computes the shared key based on the static and ephemeral elliptic curve points it received from the other party and based on the static and ephemeral private keys it generated itself. Due to the properties of elliptic curve, either party indeed arrives at the same shared key. Key authentication. Each party verifies the authenticity of the long-term static key of the other party, to obtain evidence that the only party that may be capable of computing the shared key is, indeed, its perceived communicating party. Key confirmation. Each party communicates a message authentication check value over the strings communicated by the other party, to prove possession of the shared key to the other party. This confirms to each party the true identity of the other party and proofs that that party successfully computed the shared key. 3 2 1 AB Random X, Certificate Q A Random Y, Certificate Q B MAC over messages KDC Certificate Q A (or Q B ) 1 3 2 1 2 Translated cert Q A (or Q B )

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 54 Public-Key Key Agreement: (d) with Inline 3 rd Party (2) Initial Set-up  Publication of system-wide parameters  Publication of elliptic curve domain parameters  Publication of keyed hash function h k used  Publication of un-keyed hash function h used  Distribution of authentic long-term public keys Q A and Q B, using certificates Constraints  X and Y shall be generated at random (ephemeral elliptic curve points)  Long-term private keys d A and d B private to Party A, resp. Party B, and valid during execution of protocol  Short-term private keys x and y private to Party A, resp. Party B and valid during execution of protocol  Each party does not need access to the public key Q CA used to certify the other party’s long-term key Note: (d A, Q A ), (x, X) and (d B, Q B ), (y, Y) are long-term and short-term public key pairs of A, resp. B Security Services  Key agreement between A and B on the shared key K=KeyMap(d A, x, Q B, Y )=KeyMap(d B, y, Q A, X )  Mutual entity authentication of A and B  Mutual implicit key authentication between A and B  Mutual key confirmation between A and B  Perfect forward secrecy  No unilateral key control by either party  Esoteric properties: unknown key-share resilience, session key retrieval resilience

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 55 Network Joining – Peer-to-Peer vs. Third-Party-Assisted Authentication, Authorization, and Configuration (with IEEE 802.11 Architecture)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 56 Network Joining – with Authentication by Third Party Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. e.g., subscription credentials for WiFi access e.g., IP address assignment ABKDC Authentication Authorization/ Configuration Routing ISP Gateway Author. e.g., check identity with white list (ID A  S?) keys Slide 56 B: Query {ID A, ID B } Response {ID A, ID B, wrapped keys A-KDC, B-KDC} All nonlocal communications with any (secured) transport protocol frames Does require online database with keys. Key provisioning difficult in heterogeneous trust settings (may only work with lock-in by, e.g., ISP and X-trust)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy) Network Joining – only Authorization by Third Party Device Enrolment Steps: Device authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3 rd -party device. Configuration/Parameterization.Access Point B distributes configuration information to Client A, such as  IP address assignment info;  Bandwidth/usage constraints;  Scheduling info (including on re- authentication policy details). This may originate from other network devices, for which it acts as proxy. Sequential Enrolment vs. Combined Steps Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. e.g., subscription credentials for WiFi access e.g., IP address assignment AB CA Authentication Authorization Configuration Routing ISP Gateway Author. e.g., check identity with white list (ID A  S?) (ID B  Ŝ?) B: Query {ID A, ID B } Response {(ID A, Credentials A ), (ID B, Credentials B )} Slide 57 Does require offline CA Key provisioning easy in heterogeneous trust settings (no lock-in with, e.g., ISP) All nonlocal communications with any (secured) transport protocol frames

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 58 Mapping Key Establishment Options to 802.11 Architecture without 3 rd Party Authentication  AB Random X Random Y MAC over messages Key Establishment Key Confirmation AB Random X Random Y MAC over messages Key Establishment Key Confirmation Step 1: Alignment of protocol flows Step 2: Mapping to 802.11 Messaging AB Authentication Request Authentication Response Association Request Association Response Key Establishment Key Confirmation   AB Authentication Request Authentication Response Association Request Association Response 802.11 Beacon Key Exchange Protocols:  Symmetric key: (a) Pre-shared key (a’) Blundo scheme  Public key: (b) No cert, MITM (c) Password

doc.: 11-12-0794r3 Submission August 31, 2012 Slide 59 Mapping Key Establishment Options to 802.11 Architecture with 3 rd Party Authentication Step 2: Mapping to 802.11 Messaging Key Exchange AB Authentication Request Authentication Response Association Request Association Response KDC Authentication Request Authentication Response 802.11 Beacon Step 1: Alignment of protocol flows Key DistributionKey Establishment Key Confirmation AB Random X Random Y, [ka] AT MAC over messages KDC Random X, Random Y Wrapped keys [ka] AT,[ka] BT Key Distribution  Protocols:  Symmetric key: (b) 3 rd Party (c) 3 rd Party  Public key: (d) Cert, diff. CA René Struik (Struik Security Consultancy)

doc.: 11-12-0794r3 Submission August 31, 2012 Optimized Mappings Key Establishment to 802.11 Architecture With only 3 rd Party Authorization, DHCP IP Address Assignment AB Random X, Id A Random Y, Id B MAC over messages MAC over messages & KDC Id A, Id B DHCP server Authorization (Id A ) Authorization (Id B ) DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {Id A, Id B }) IP Address Assignment STAAP Authentication Request Authentication Response Association Request Association Response AS Authorization Request DHCP server Authorization Response DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {STA,AP}) IP Address Assignment René Struik (Struik Security Consultancy) &DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) * Authorization support by third party is optional. Device roles are conceptual only; actual role to device mapping implementation-dependent. {& Authorization Response AP} { & Authorization Response Id B } IP address assignment serves as illustration only of more general configuration step (cf. Slide 7). NEW! Blundo scheme Erases inline third party requirement

doc.: 11-12-0794r3 Submission August 31, 2012 Optimized Mapping Key Establishment to 802.11 Architecture With 3 rd Party Authentication and DHCP IP Address Assignment AB Random X Random Y, [ka] AT MAC over messages MAC over messages & KDC Rnd X, Id A, Rnd Y, Id B Wrapped keys [ka] AT,[ka] BT DHCP server DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) (implicit Authorization {Id A, Id B }) Key Establishment Key Confirmation Key Distribution IP Address Assignment STAAP Authentication Request Authentication Response Association Request Association Response AS Authentication Request Authentication Response DHCP server DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) (implicit Authorization {STA,AP}) Key Establishment Key Confirmation Key Distribution IP Address Assignment René Struik (Struik Security Consultancy) &DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) * Authorization support by third party is optional. Device roles are conceptual only; actual role to device mapping implementation-dependent. IP address assignment serves as illustration only of more general configuration step (cf. Slide 6).

doc.: 11-12-0794r3 Submission August 31, 2012 Optimized Mappings Key Establishment to 802.11 Architecture With only 3 rd Party Authorization, DHCP IP Address Assignment AB Random X, Certificate Q A Random Y, Certificate Q B MAC over messages MAC over messages & KDC Id A, Id B DHCP server Authorization (Id A ) Authorization (Id B ) DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {Id A, Id B }) IP Address Assignment STAAP Authentication Request Authentication Response Association Request Association Response AS Authorization Request DHCP server Authorization Response DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) Key Establishment Key Confirmation (explicit Authorization {STA,AP}) IP Address Assignment René Struik (Struik Security Consultancy) &DHCP Discover, w/ Rapid Commit DHCP ACK, w/ Rapid Commit (IP) * Authorization support by third party is optional. Device roles are conceptual only; actual role to device mapping implementation-dependent. {& Authorization Response AP} { & Authorization Response Id B } IP address assignment serves as illustration only of more general configuration step (cf. Slide 7).

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 63 Key Establishment Options The following protocol options for key establishment are provided: Symmetric-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a) Both devices do share a secret (master) key beforehand. 12/055: fils-symm-key-based-authentication (b) Both devices do not share a secret key, but each shares a key with a mutually trusted third party. (c) Both devices do not have certificates, but each shares a key with a mutually trusted third party. Public-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a)Both devices do have (access to) a certificate of their public key, issued by a mutually trusted third party (certificate authority). 12/052: fils-authentication-with-certified-public-keys (b)Both devices do not have (access to) a certificate of their public key. (c)Both devices do have access do share a weak secret key. 12/054: fils-password-based-authentication (d)Both devices do not have (access to) a certificate of their public key, but cannot verify each others certificate. 12/052: fils-authentication-with-certified-public-keys All public-key schemes: prime curve, ECDSA-P256-SHA-256, no CRLs/OCSP, etc. (may include short-lived certs, depending on policy) Other features: built-in algorithm agility, including on curve domain parameters (this includes binary vs. prime curves) NOTE: Binary curves may be better suited; Design choices influenced need for efficiency, low hassle deployment, and IPR considerations Proposed Design Parameters NOT CAST IN STONE – MOST “REALISTIC” ASSESSMENT Others do this (e.g., 11/1488) Suggest not to do

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 64 Summary (1) 1.Proposed Schemes 11-12-0052-02-00ai-fils-authentication-with-certified-public-keys 11-12-0054-01-00ai-fils-password-based-authentication 11-12-0055-01-00ai-fils-symm-key-based-authentication 2.Implementation with 802.11 Architecture Use authentication request/response and association request/response Use piggy-backing to carry configuration information 3.Considerations -Standards-compliance: NIST SP 800-56a, FIPS 180-2, FIPS 186-2, RFC 5480, NIST SP 800-38C -Cryptographic scrutiny: all well-studied -Exploiting commonalities state machines, protocol flows of all proposed options -Works with “backbone” Access Point – Authentication Server approaches for authorization/ (& DHCP) 4.Room for Further Technical Improvements (a) Use optimized authenticated key agreement scheme: was: ECC: 1 offline, 1 variable; ECDSA: 1 sign, 2 verify would be: ECC: 1 offline, 1 ½ online; ECDSA: 1 verify (b) Use elliptic curve better suited for hardware/low-energy implementations: was: prime curve P-256 would be: binary curve K-283 NOTE: much better implementations than “school book” computations

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 65 Summary (2) 5.Room for Further Enhancements of Functionality (a) Provide optional anonymity: was: Ids of STA and AP are publicly known would be: Ids of STA and AP only become known to actors in protocol and, potentially, KDC No impact on #protocol flows, slight increase of computational cost (under the hood) (b) Auto-renewal long-term keying material: was: no facility with text in 12/052, 12/055 would be: facility to push new certificates, symmetric-key certs No impact on #protocol flows, new IE Note: could be used to implement low-hassle key management (e.g., short-lived certs, no CRLs) (c) Use optimized symmetric-key scheme: was: symmetric-key scheme (12/054r1) without 3 rd party, but neither with forward secrecy would be: symmetric-key scheme without 3 rd party, but with forward secrecy as well (d) Auto-synchronization: was: no facility with joining protocol to synch info on need-be basis would be: facility to synch data if needed No impact on #protocol flows, secure; new IE; in line with ideas presented (e.g., in 11/1169r1) Note: could be used to cross-certify if no common CA root key 6.Initial set-up requirements key agreement schemes (1) certified public-key based: devices need certificate; verifiers need root key (2) password-based: devices need to synch on low-entropy password and may need I/O interface for this (3) symmetric-key based: devices need shared key (mostly only available in re-join scenarios)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 66 Key Establishment Options The following protocol options for key establishment are provided: Symmetric-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a) Both devices do share a secret (master) key beforehand. (b) Both devices do not share a secret key, but each shares a key with a mutually trusted third party. (c) Both devices do not have certificates, but each shares a key with a mutually trusted third party. Public-Key Key Agreement: Two devices A and B derive a shared key (key agreement) and show that these have computed correctly (key confirmation) in each of the following scenarios: (a)Both devices do have (access to) a certificate of their public key, issued by a mutually trusted third party (certificate authority). (b)Both devices do not have (access to) a certificate of their public key. (c)Both devices do have access do share a weak secret key. (d)Both devices do not have (access to) a certificate of their public key, but cannot verify each others certificate. C/R protocol with session keys, ephemeral Diffie- Hellman (related to (c), but without 3 rd party) Bellare./Rogaway Tri-Partite Key Agreement Scheme (ACM 1995) Hugo Krawczyk’s protocol (P1363) Ephemeral Diffie-Hellman 802.11s-like Password-based key agreement Same as (a), but with cert translation All public-key schemes: prime curve, ECDSA-P256-SHA-256, no CRLs/OCSP, etc. (may include short-lived certs, depending on policy) Other features: built-in algorithm agility, including on curve domain parameters (this includes binary vs. prime curves) NOTE: Binary curves may be better suited; Design choices influenced need for efficiency, low hassle deployment, and IPR considerations “Optimum” Design Parameters NOT CAST IN STONE – BEST TECHNICAL ASSESSMENT

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 67 Security Concepts – A Short Introduction

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 68 Authenticity Evidence as to the true source of information or the true identity of entities:  Message authentication Evidence regarding the true source of information: (1)No undetectable modifications, deletions, and injections of messages by external parties (data integrity); (2) No confusion about who originated the message (source authenticity).  Entity authentication Evidence regarding the true identity of entities and on their active involvement: (1) No confusion about whom an entity is really communicating with (authenticity); (2) Proof that entity is actively participating in communications (i.e., is ‘alive’). Secrecy Prevention of external parties from learning the contents of information exchanges: (1) Logical separation of information between parties that may have access to info and those that do not. (2) No confusion about whom those privileged parties are (authenticity). Basic Security Services

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 69 Message authentication Evidence regarding the true source of information: (1) No undetectable modifications, deletions, and injections of messages by external parties (data integrity); (2) No confusion about who originated the message (source authenticity). Realizations:  Keyed hash function (or Hash Message Authentication Code (HMAC)) Mapping of arbitrary messages (of any length) to compact representative image hereof, using a secret key. (1) Data integrity, since difficult to find distinct messages with same MAC value. (2) Source authentication, since only parties that share the secret key can produce MAC-value (assuming there is no confusion about who has access to this key).  Un-keyed hash function Mapping of arbitrary messages (of any length) to compact representative image hereof (digital fingerprint, or message digest), without secret key. (1) Data integrity, since difficult to find distinct messages with same hash value. (2) Source authentication, only if message digest is communicated authentically. Cryptographic Building Blocks - Authentication (1)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 70 Entity authentication Evidence regarding the true identity of entities and on their active involvement: (1) No confusion about whom an entity is really communicating with (authenticity); (2) Proof that entity is actively participating in communications (i.e., is ‘alive’). Realizations:  Entity authentication protocol (challenge/response protocol) (1) Source authentication, since only parties that share the secret key can produce proper responses to unpredictable challenges (assuming there is no confusion about who has access to this key). (2) Aliveness, since challenge messages are unpredictable and never repeated. (Hence, replaying previously recorded protocol messages does not leak info.) Cryptographic Building Blocks - Authentication (2)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 71 Secrecy Prevention of external parties from learning the contents of information exchanges: (1) Logical separation of messages between parties that may have access to info and those that do not. (2) No confusion about whom those privileged parties are (authenticity). Realizations:  Symmetric-key cryptography Logical separation of information, since only parties that share the secret key can learn the contents hereof (assuming there is no confusion about who has access to this key). Note that the symmetric key is used both for encryption and for decryption.  Public key cryptography Logical separation of information, since only parties that have access to the private decryption key can learn the content of encrypted messages (assuming there is no confusion about who has access to this private key). Note that any party may obtain access to the public encryption key, since it does not reveal the decryption key. Cryptographic Building Blocks - Secrecy

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 72 Symmetric-key cryptography Security services based on exchange of secret and authentic keys: (1) Logical separation of messages, by exchanging secret keys between privileged parties only; (2) Authenticity of privileged parties by checking credentials of each party, by non-cryptographic means (certified mail, courier, face-to-face, etc.) Public-key cryptography Security services based on exchange of authentic public keys: (1) Logical separation of messages, by restricting access to each private key to the privileged party only (in practice, there is only 1 privileged entity); (2) Authenticity of privileged parties, by checking credentials of each party by non-cryptographic means and (if successful) by subsequently binding the public key to this party (certification of public keys). Certification is done by a so-called Trusted Third Party, who vouches for the authenticity of the binding between an entity and its public key. Cryptographic building blocks – Authenticity and Secrecy (1)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 73 Public-key cryptography (cont’d) Certification of public keys depends on appropriately checking the credentials of a party and constitutes the following: (1)Check, by cryptographic means, that the entity A that claims to have access to the public key P A, has access to the corresponding private key S A ; (2)Check, by non-cryptographic means, the claimed identity Id A of A. Certification is done by a so-called trusted third party:  Digital certificates (cryptographic binding) (1)Authenticity of binding, via signature over the pair (Id A,P A ) by trusted party; (2)Verification of authenticity of public keys by any party, by verifying signature of trusted party in the digital certificate (assuming the authentic storage of trusted party’s signature verification string on each verifying device); (3)Unrestricted transfer of certificates possible (hence, off-line certification possible).  Manual ‘certificates’(non-cryptographic: pushing button, low power mode, etc.). (1)No cryptographic verification of the authenticity of public keys possible; (2)No transfer of certificates possible (hence, on-line ‘certification’ only). Note: with manual certificates, one usually implements ACL lists with public keys Cryptographic building blocks – Authenticity and Secrecy (2)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 74 Provisioning with Public-Keys  Features and Benefits  Security and Usability − Flexibility and Ease of Use (slides from 12/574r0)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 75 Source: D. Balfanz, G. Durfee, R.E. Grinter, D.K. Smetters, P. Stewart, “Network-in-a-Box: How to Set Up a Secure Wireless Network in under a Minute,” in Proceedings of the 13 th USENIX Security Symposium, August 9-13, 2004. The “Holy Grail”: Security and Ease of Use “Computer users have been taught for years that computer security systems can’t be effective unless they are complex and difficult to use. In reality, this conventional wisdom is completely wrong.”  Lorrie Faith Cranor, Carnegie Mellon University Security technology can make trust lifecycle management intuitive and hidden from the user.

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 76 Ease of Configuration and Reconfiguration Ease of configuration:  Merging of networks  Partitioning of networks  Device portability and orphaning  Hand-over of control (remote, backup)  Synchronization and failure recovery

doc.: 11-12-0794r3 Submission Conventional wisdom: Symmetric-key cryptographic functionality, let alone public- key cryptographic functionality, are expensive to implement with sensor networks. Status anno 2008: conventional wisdom challenged for all but most mundane devices. Examples: Bluetooth v2.1, ZigBee Smart Metering, RFID e-Passport. Cost Public Key Device DeviceIdCA IdAttributeData 22 octets 8 octets 10 octets ProfileIdCtrlSerial# ManufacturerData ZigBee Smart Energy (SE1.x) Profile Certificate Structure: Low-energy hardware implementations: Smart Sensors 1 RFID 2 clock frequency2 MHz10 MHz #gates~10 kgates~100 kgates CMOS process130nm250nm Energy exp.:~ 250  J< 100  J Computationsignature verifypoint multiple (total: 48 octets) Sources: 1 Private communication 2 SAC 2008 conference Less than energy expenditure typical IEEE 802 frame! René Struik (Struik Security Consultancy)Slide 77

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 78 Deployment Scenarios vs. Security Design Diverse deployment scenarios  Home Automation RFC 5826 - Home Automation Routing Requirements in Low-Power and Lossy Networks (April 2010)  Building Automation RFC 5826 - Building Automation Routing Requirements in Low-Power and Lossy Networks (June 2010)  Urban Settings RFC 5548 - Routing Requirements for Urban Low-Power and Lossy Networks (May 3009)  Industrial Control RFC 5673 - Industrial Routing Requirements (October 2009)  Smart Grid NIST IR 7628 – Guidelines for Smart Grid Cyber Security, Vol. 1 - Strategy, Architecture, High-Level Requirements (August 2010)  Internet of Things draft-ietf-core-coap – Constrained Application Protocol (draft March 12, 2012) Actual security design Unified design that fits these diverse deployment scenarios – concise set of cryptographic and security mechanisms; – single security policy framework; – configuration parameters application-dependent. This allows for mass-scale production, while still allowing for customization (e.g., as to security services provided, granularity of assurances, used keys, device roles, etc.) This requires consideration of system perspective, taking into account the entire system and device lifecycle and ease-of-use and ease-of-deployment

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 79 key distribution AB Data key repository Data key maintenance Data key repository Data key maintenance Wrapped data key info Wrapped data key info data transfer AB Wrapped data Encryptor/ decryptor Encryptor/ decryptor data Data key Key info Key info Data key Upper layers Network and down ACL Maintenance ACL Maintenance ACL initialization ACL initialization B AAuthentication, key establishment Wrapped public key info Extracted public key info Wrapped public key info Extracted public key info Public key verification CA key initialization Certificate maintenance Public key verification CA key initialization Certificate maintenance (Link key, A, B) Security Architectural Framework: Overview

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 80 Security Architectural Framework – Design Aspects Various aspects, including  Security Policy and Trust Model  Configuration and Installation  Protocol design aspects For details, see, e.g., draft-struik-6lowapp-security-considerations-00 draft-garcia-core-security-03 Security constraints  Decentralized key management  Flexible configuration and trust model  Low impact key compromise  Automatic lifecycle management  Low communication overhead  Low implementation cost Adhoc networks  No centralized management  Promiscuous behavior  Unreliability Sensor networks  Low energy consumption  Low manufacturing cost

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 81 PHY functions Data Link functions Network functions Transport functions APP functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device Full stack device, including per-layer and shared parameters Trust binding

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 82 PHY functions Data Link functions Network functions Transport functions APP functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device Full stack device, including per-layer and shared parameters Authorizations (policy state machine)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 83 Acceptability test: Yes/No? Configuration Acceptability test based on - Device Id - Tag Name - Device Label - Open enrolment - Proximity-based techniques … Trust management via device identities Trusted module - AES, ECC, RNG - Security policy engine - Storage of keys

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 84 Deployment Scenarios 1 Scenario #1: mix-and-match of nodes from different vendors Scenario #2: addition of nodes to operational network Scenario #3: security audit Scenario #4: device repair and replacement (roaming in/out different user sites) Scenario #5: network separation (devices joining wrong network) Scenario #6: thwarting malicious attacks by (former) insiders Scenario #7: thwarting attacks by outsiders via insiders (held at ‘gunpoint’) Scenario #8: addition of subsystem (‘skid’) assembled elsewhere to operational network 1 Deployment scenarios discussed with ZigBee, ISA SP100.11a, Smart grid user community

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 85 Ease of use. Trust lifecycle management appears the same as that of an unsecured network and relies on  Proper identification of devices (e.g., reading off a label of physical module);  Proper management of device roles (e.g., adding these to, resp. removing these from a white list, e.g., via a workstation GUI). Thus, trust lifecycle management relies completely on handling of public information. Flexibility. Virtually no restrictions w.r.t. support for  Mix-and-match of devices from different vendors;  Changes to network topology (merging or partitioning of networks, device replacement or addition, addition of pre-assembled subsystem);  Changes to device roles (e.g., smooth hand-over of system manager, security manager roles, via ‘soft reboot’);  Back-up and failure recovery (since management fully relies on public information). Desired Features and Benefits (1)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 86 Minimize trust dependencies.  Reduced reliance on trustworthy personnel;  Virtually no training requirements for operational personnel;  Virtual removal of trust dependencies between different entities in value chain (whether OEM, vendor, system integrator, installer, or user).  Ease of security auditability. Support for flexible deployment and business models. Network topology changes or device role changes present a ‘clean’ logical separation between state prior to and after such an event (thus, allowing subscription-based services, outsourced management, re-contracting, etc.). Enforcement of standards compliance. Enforcement possible by only issuing a certificate to devices from vendors that passed conformance testing. No reliance on configuration tools and out-of-band configuration steps. A configuration tool may be used, but is not strictly necessary for trust enforcement. Desired Features and Benefits (2)

doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 87 Security and ease of use  No online reliance on third parties for authentication (since networks may be spotty)  Support for heterogeneous trust models (mix-and-match of multi-sourced devices)  May involve (local) third party for authorization policy enforcement only  Support for device swap in the field, topology changes, role changes  No client/server model (since relationships may be peer-to-peer)  Low configuration overhead (billions of devices must be to cheap to deploy securely)  No “prediction” of where devices may end up in the field (no “site survey”) Protocol aspects  Minimize number of protocol passes (sleepy devices, reduced channel interference)  Maximize potential to parallelize computations, etc.  Support piggy-backing (if only since it may help reducing traffic, energy expenditure) Implications for FILS (1)

Doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote.

Similar presentations

Presentation on theme: "Doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote.

Similar presentations

Presentation on theme: "Doc.: 11-12-0794r3 Submission August 31, 2012 René Struik (Struik Security Consultancy)Slide 1 Authentication with Local Authentication and Optional Remote."— Presentation transcript:

Similar presentations

About project

Feedback