ibops protocol version 1.0 - oasis | advancing open ... · web viewfirst of all, the ibops...

Identity Based Open Exchange Protocol Specification (IBOPS) 1.0

Working Draft 02

31 October 2015

Technical Committee:OASIS Identity Based Attestation and Open Exchange Protocol Specification (IBOPS) TC

Chairs:Scott Streit ([email protected]), Villanova UniversityAbbie Barbir ([email protected]), Bank of America

Editor:Kalim Sheikh ([email protected]), Hoyos Labs Corp.Andrew Hughes ([email protected])David Turner (xxx@xxx)

Additional artifacts:This prose specification is one component of a Work Product that also includes: XML schemas: (list file names or directory name) Other parts (list titles and/or file names)

Related work:This specification replaces or supersedes: Specifications replaced by this specification (hyperlink, if available)This specification is related to: Related specifications (hyperlink, if available)

Declared XML namespaces: list namespaces declared within this specification

Abstract:Summary of the technical purpose of the document.

Status:This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:Initial publication URI:http://docs.oasis-open.org/ibops/ibops-protocol/v1.0/csd01/ibops-protocol-v1.0-csd01.docPermanent “Latest version” URI:http://docs.oasis-open.org/ibops/ibops-protocol/v1.0/ibops-protocol-v1.0.doc(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2015. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as

ibops-protocol-v1.0-wd01 Working Draft 01 31 October 2014Standards Track Draft Copyright © OASIS Open 2014. All Rights Reserved. of 19

https://www.oasis-open.org/policies-guidelines/ipr

https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft

https://www.oasis-open.org/policies-guidelines/tc-process#dWorkingDraft

http://www.hoyoslabs.com/

http://www.bankofamerica.com/

mailto:[email protected]

http://www.villanova.edu/

mailto:[email protected]

https://www.oasis-open.org/committees/ibops/

needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Table of Contents1 Introduction......................................................................................................................................... 4

1.1 IBOPS............................................................................................................................................... 41.2 Terminology....................................................................................................................................... 41.3 Normative References....................................................................................................................... 51.4 Non-Normative References...............................................................................................................5

2 Overview............................................................................................................................................. 62.1 Identity............................................................................................................................................... 62.2 Authentication and Assurance...........................................................................................................62.3 Goals................................................................................................................................................. 72.4 Non-goals.......................................................................................................................................... 7

3 IBOPS................................................................................................................................................. 83.1 Overview........................................................................................................................................... 8

3.1.1 Model......................................................................................................................................... 83.1.2 Stages........................................................................................................................................ 8

3.2 User Enrollment................................................................................................................................. 83.3 Certificate management.................................................................................................................... 83.4 Device registration............................................................................................................................. 83.5 Authentication.................................................................................................................................... 9

3.5.1 Overview.................................................................................................................................... 93.5.2 Client Software Authentication.................................................................................................103.5.3 Post-enrolment device/user authentication..............................................................................10

3.6 Authenticated Session Management...............................................................................................113.7 Authorization and Access Control...................................................................................................11

4 Best practices and Security Considerations......................................................................................134.1 Intrusion Detection........................................................................................................................... 13

4.1.1 Overview.................................................................................................................................. 134.1.2 Replay Prevention.................................................................................................................... 13

4.2 Standards, Audit, and Quality Control.............................................................................................134.2.1 Standards................................................................................................................................. 134.2.2 Audit Capabilities.....................................................................................................................13

4.3 Data Protection................................................................................................................................ 144.3.1 Network Transmissions............................................................................................................144.3.2 Data Protection Strategy..........................................................................................................144.3.3 Client-side data........................................................................................................................144.3.4 Server-side data.......................................................................................................................154.3.5 IBOPS Server Data..................................................................................................................15

5 # Conformance.................................................................................................................................. 16Appendix A. Acknowledgments............................................................................................................17Appendix B. Implementation Example.................................................................................................18

B.1 Subsidiary section........................................................................................................................... 18B.1.1 Sub-subsidiary section.............................................................................................................18

Appendix C. Revision History...............................................................................................................19


1 Introduction1.1 IBOPSIBOPS defines an authentication mechanism that uses a registered device with a biometric reader to enable a user to authenticate in a different context, such as accessing a service on another device. It can be used as a stand-alone authentication mechanism or combined with other authentication factors.

1.2 TerminologyThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].[EDITOR’S NOTE: This is an incomplete list from X.1252. I don’t think we should include them because there are so many. A normative reference to X.1252 should be sufficient]6.7 assurance: See authentication assurance and identity assurance.6.8 assurance level: A level of confidence in the binding between an entity and the presentedidentity information.6.9 attribute: Information bound to an entity that specifies a characteristic of the entity.6.12 (entity) authentication: A process used to achieve sufficient confidence in the bindingbetween the entity and the presented identity.NOTE – Use of the term authentication in an identity management (IdM) context is taken to mean entityauthentication.6.14 authorization [ITU-T Y.2720], and [ITU-T X.800]: The granting of rights and, based onthese rights, the granting of access.6.20 context: An environment with defined boundary conditions in which entities exist andinteract.6.21 credential: A set of data presented as evidence of a claimed identity and/or entitlements.6.22 delegation: An action that assigns authority, responsibility, or a function to another entity.6.23 digital identity: A digital representation of the information known about a specificindividual, group or organization.6.24 enrolment: The process of inauguration of an entity into a context.NOTE 1 – Enrolment may include verification of the entity's identity and establishment of a contextualidentity.NOTE 2 – Also, enrolment is a pre-requisite to registration. In many cases, the latter is used to describe bothprocesses.6.25 entity: Something that has separate and distinct existence and that can be identified incontext.NOTE – An entity can be a physical person, an animal, a juridical person, an organization, an active orpassive thing, a device, a software application, a service, etc., or a group of these entities. In the context oftelecommunications, examples of entities include access points, subscribers, users, network elements,networks, software applications, services and devices, interfaces, etc.6.26 entity authentication: A process to achieve sufficient confidence in the binding betweenthe entity and the presented identity.NOTE – Use of the term authentication in an identity management (IdM) context is taken to mean entityauthentication.6.28 identification: The process of recognizing an entity by contextual characteristics.6.29 identifier: One or more attributes used to identify an entity within a context.


4 Rec. ITU-T X.1252 (04/2010).

1.3 Normative References[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP

14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.[Reference] [Full reference citation]

1.4 Non-Normative References[Reference] [Full reference citation]

NOTE: The proper format for citation of technical work produced by an OASIS TC (whether Standards Track or Non-Standards Track) is:

[Citation Label]Work Product title (italicized). Edited by Albert Alston, Bob Ballston, and Calvin Carlson. Approval date (DD Month YYYY). OASIS Stage Identifier and Revision Number (e.g., OASIS Committee Specification Draft 01). Principal URI (version-specific URI, e.g., with stage component: somespec-v1.0-csd01.html). Latest version: (latest version URI, without stage identifiers).For example:

[OpenDoc-1.2] Open Document Format for Office Applications (OpenDocument) Version 1.2. Edited by Patrick Durusau and Michael Brauer. 19 January 2011. OASIS Committee Specification Draft 07. http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html. Latest version: http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html.


http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html

http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html

http://www.ietf.org/rfc/rfc2119.txt

2 Overview2.1 IdentityIn the real world, the identity of a natural person is readily accepted and is based upon an extensive set of characteristics or attributes. Some of these are physical features such as height, hair colour, general appearance, mannerisms, behaviour, etc. Others, like date of birth, place of birth, home address, telephone number may also be used.In the online world, an identity is also made up of attributes. However, in this case, the identity may be limited to a single attribute or it may have many; it will depend on the context in which it appears. This applies to inanimate objects and other online services, as well as natural persons, so a user is often referred to as an entity.Identifiers and attributes can uniquely characterize an entity within a particular context. Because of this, an entity may have a number of different identities including identities that can be subsets of another identity. There also may be intersections of identities. However, for various reasons (such as for privacy concerns), intersections of identities, used for different purposes or in different contexts, may be explicitly undesirable or even excluded.

2.2 Authentication and AssuranceMost communication processes require that the communication partners have adequate assurance or trust that they are communicating with the intended partner. Therefore, at the beginning of a communication, the partners try to reach a sufficient level of assurance on the basis of available identity information about the partner, i.e., confidence in the binding between the entity and the presented identity. This process is called authentication and typically involves three or more participants:

Requester (e.g., user) - the entity whose identity is to be confirmed Identity provider (IdP) – the entity that confirms the identity of the requester Relying party (RP) – the entity that will rely on a confirmed identity

Figure 1 Typical Authentication Model

The information that can be used for identification of an entity is based on the entity's attributes. In practical terms, identification of an entity is usually based on a subset of its attributes since identification


is limited by the specific context within which the entity exists and interacts. The narrower the context and the clearer the boundary conditions, the fewer the number of attributes necessary for identification.The assurance level required should be based on a risk assessment of the transactions, services, or resource access for which the entities will be authenticated. This is achieved by using one or more authentication mechanism to reach a define level of assurance that mitigates threats based on a risk assessment [X.1254]. These mechanisms are usually classified as credential-based or transactional and fit one of the following categories [REF?]:

Who you are; What you know; What you have; What you typically do; Context.

Greater levels of assurance can be achieved by combining multiple factors that don’t share the same vulnerabilities.

2.3 Goals Describe the types of threat mitigation IBOPS addresses Define the technical details necessary to implement this mechanism (e.g., protocols, messages,

etc.) Work with existing IdM solutions and protocols (e.g., OAuth, OpenID Connect, SAML) The architecture is language-agnostic, allowing client-server and server-server communication

via RESTful API’s and JSON.

2.4 Non-goals User enrollment and proofing levels Credential management Transaction session state as distinct from authentication session state Implementation specific details (e.g., credential management, strength and type of encryption,

client-side software) [more?]


3 IBOPS 3.1 Overview

3.1.1 Model

3.1.2 Stages User Enrollment Certificate Management Device Registration Authentication Authorization

3.2 User Enrollment[EDITOR’S NOTE: This text was copied directly from X.1254]The enrolment phase consists of four processes: application and initiation, identity proofing, identity verification, and record-keeping/recording. These processes may be conducted entirely by a single organization, or they may consist of a variety of relationships and capabilities provided by a number of organizations including shared or interacting components, systems and services.The required processes differ according to the rigour required by the applicable LoA. In the case of an entity enrolling under LoA1, these processes are minimal (e.g., an individual may click a "new user" button on a webpage and create a username and password). In other cases, enrolment processes may be extensive. For example, enrolment at LoA4 requires an in-person meeting between the entity and the RA, as well as extensive identity proofing.[need text about IBOPS-specific requirements]

[3.3] Certificate managementissuanceIBOPS uses certificates as part of it’s process. For each client device registered, a certificate and an associated key pair are generated and represent the pairing of a user to the device. A device cannot be registered until the certificate has been deployed to the device. A certificate and key pair must also be generated and deployed to the authentication server. The format of a certificate may vary from implementation to implementation, and the specific processes used for creation, deployment, management, and revocation are out of scope for this document.

3.3[3.4] Device registration1) User initiates registration request.2) User authentication or step-up authentication may be required.3) Device authenticates with the server using IBOPS certs4) Device generates device fingerprint5) Biometric enrollment:

a) Acquire biometric factor data through the device (for example, face, fingerprint, iris etc.).b) Generate the biometric vector (hash).c) Store biometric vector on the client for user authentication.

Depending upon implementation, the registration process may include verification of an existing identity. This can happen in several stages, and the order in which this happens depends on the specific product or solution. It is vendor dependent whether the certificate is tied to the user’s identity, meaning each


identity has one and only one certificate, or alternately may use a separate certificate per device registration and each one will be tied to the single identity.ABBIE we need to consider the interface between the biometric device reader and the client device. How can we trust this device? How can we prevent replay?

Figure 2 Device Registration

3.4[3.5] Authentication

3.4.1[3.5.1] OverviewSuccessful authentication of a user/device combination is required in order to allow access to requested resources. The IBOPS has multiple points of authentication to enable that:● Initial client software is authenticated using embedded default certificates that are shared with the server within a standard TLS session handshake.● After genesis/enrolmentdevice registration, users are authenticated using biometrics, matched locally on a mobile device.


● The pre-registered device authenticates to the server using a Client Certificateclient certificate, shared over a standard TLS session handshake. The cClient cCertificate represents a pre-registered user/device a pairing of the user identity and the device. A client certificate can't be submitted to a server until the certificate is decrypted with a password, which is obtained under a condition of a successful user authentication.● Server authentication is also enabled using server certificates shared with the client during the TLS Each of these authentication points are described in detail in the following sections.

3.4.2[3.5.2] Client Software AuthenticationWhen installed, the client application comes pre-loaded with a default X.509 certificate that allows 2-way TLS-based authentication to be immediately enforced and active throughout the genesis/enrolment registration and authentication stages. This certificate allows establishment of an TLS session with a URI dedicated to allowing the initial stages of genesis aloneregistration, with a limited number of APIs available over that URI. After genesis/user enrolmentregistration, this default certificate is replaced with the cClient cCertificate.

[3.5.3] Post-enrolment device/uUser authentication

3.4.2.1[3.5.3.1] User AuthenticationA user is authenticated by matching biometric vectors and passing liveness tests1. The user’s biometrics, single factor or multi-factor , are acquired through the device (for example, face, fingerprint, iris etc.). Biometric vector(s) are extracted from the acquired biometrics. The vector(s) are matched against saved biometric vector(s) obtained during genesis and enrolment.IBOPS performs matching on the client side. After the client-side software validates the user via their biometrics, the biometrics authentication result is sent to the server regardless of the matching result.

[3.5.3.2] In line with the IBOPS standard, all applications should include some form of liveness detection or an ability to ensure that the enrolled or authenticated user is an actual person and not an image or other representation of the user. For a face recognition system, it could be blink detection, for instance. Adjustable liveness detection levels are configurable on the Boriken server. Their adjustment affects false negative and false positive thresholds, timing, and usability. The choice of a liveness level is up to the organization using IBOPS and its particular needs.

[3.5.3.3] Device authenticationIBOPS authenticates at two levels: within the underlying TLS session and within the server itself: 1. TLS-level authentication of the client device utilizes an X.509 certificate that was generated and signed by the Boriken server during user genesis/enrolmentdevice registration, linked to a stored user/device pairing, and then provided to the client. We refer to this as the cClient cCertificate. To authenticate a device, the client software unlocks the cClient cCertificate and submits it to the server as a part of the TLS session2 handshake. In line with the TLS handshake protocol the client then allows the Client Certificate client certificate to be verified by the server via the TLS “Certificate Verify” message. The Client Certificate client certificate is unlocked (decrypted) using a password obtained after successful authentication.

1 If enabled. See Section XXX under Security considerations. 2 Because the TLS session is using a different client certificate to that used initially at genesis (which was the default certificate), the TLS session is established with a different URI endpoint.ibops-protocol-v1.0-wd01 Working Draft 01 31 October 2014Standards Track Draft Copyright © OASIS Open 2014. All Rights Reserved. of 19

David Turner, 2015-12-03,

Is this for intrusion detection.

2. After verification of the Client Certificateclient certificate, the Boriken server login module extracts the client certificate’s device identifier (the GUID), looks up the appropriate account, checks for certificate revocation, determines roles associated with that account, and establishes an authenticated and authorized session.

3.4.2.2[3.5.3.4] Server AuthenticationServer authentication is achieved using the underlying TLS session. To meet the IBOPS requirements of two-way authentication between client and server, IBOPS requires TLS or TLS using client and server X.509 certificates.The IBOPS server certificate used for TLS sessions is verified (signed) by a third party cCertificate aAuthority, in this case GoDaddy, (CA) using their private key.The client is able to verify the integrity of the IBOPS certificate by referring to the CA3rd party CA (GoDaddy)’s public key, included as a certificate in the distribution of most common browsers and operating systems. This verification is completed as part of the standard SSL/TLS session handshake.

3.5[3.6] Authenticated Session ManagementThere are important characteristics of Session Management within IBOPS. First of all, the IBOPS protocol is stateless with respect to HTTP. This means that every call to a IBOPS-compliant server must have an identifier to the account, and the server must persist the current state. Through tThis mechanism IBOPS has enables session management for the authentication process. So iBOPS is HTTP stateless but stateful within its own context.Sessions are tied to a specific user interacting with resources via the IBOPS server for a period of time. Each authorized user/device has its own unique cClient cCertificate, and that certificate contains a GUID which the server uses to identify the user. The identification of the uUser occurs by taking the GUID for the device and looking up the user for the device in the IBOPS server. Initially the IBOPS server creates an opportunity for a session. This may be done in a variety of ways, but is most commonly done with a QR Code display. This call is a sSession Oopportunity meaning that the system displaying the QR Code may, after authentication, allow the establishment of a session. Or, alternately, the sSession oOpportunity may timeout or not authenticate. In the case of successful user authentication and sSession oOpportunity, we have a sSession. In many cases, the authentication session will be distinct from, and managed separately from, the transaction session (i.e., what the user is trying to do).Within the IBOPS server a persistent session is established specific to the account referenced via the Client Certificateclient certificate. Sessions may take in any kind of data as of tag/value pairs. This may be geospatial data, variable transaction amounts, or any other data we wish to store throughout the duration of the session. In the case of geo-fencing, which is wanting to control the physical location of a session, we add in latitude and longitude. In the case of an ATM, we add withdrawal amounts to the session. At some point in time, the session completes. At session completion, all information about the session is written to a history/audit. In the case of disallowing a device, user or account, the appropriate Client Certificateclient certificates get revoked by removing the GUID from the IBOPS server. All future calls to the server will no longer result in successful communication.

[3.7] Authorization and Access ControlThe result of a successful authentication is typically used as the basis for authorizing the user to perform a transaction, or to access a resource or service. The Client Certificate is used to authenticate a user’s identity and to manage access control.The authorization may depend solely on the result of the IBOPS authentication, or in combination with other authentication factors or attributes.


David Turner, 2015-12-03,

Needs elaboration. 1. Explain the context of the action. 2. Describe the user interaction. 3. Describe what’s going on in the background.

In line with the IBOPS standard, the IBOPS server enforces a mandatory access control policy over all subjects and objects3 under its control. The mandatory access control policy guarantees all data is labelled and all users have roles.`integration for a large enterprise. Active Directory may be the role source for a given organization, but the same organization may use the IBOPSServer to dictate more refined liveness for certain other roles. In this case the combination of the Boriken server and Active Directory create the authoritative role source, available via an API call.Data is labeled with characteristics that describe access or access patterns - for example data may be labeled as “All”, allowing all access. The server maintains these sensitivity labels.A mapping between roles and sensitivity labels allows us to implement role-based adjudication. Boriken server administrators can specify and control sharing of objects with subjects and determine if a given subject may read, write or execute an object via an API within a particular session.Roles are typically hierarchical in nature. A subject can write an object only if the hierarchical classification in the subject’s security level is less than or equal to the hierarchical classification in the object’s security level and all the non-hierarchical categories in the subject’s security level are included in the non-hierarchical categories in the object’s security level. To further illustrate, the IBOPS server receives a request. The request has a certificate which links the device to the user. The user has many roles so the roles (after the hierarchy is flattened) are stored in memory in something that the Java Authentication Services. The authenticated user is called a Principal. In subsequent processing, web pages may allow access for certain roles and data may have labels that correspond to the users roles. Data adjudication compares the data labels against the roles for the Principal. So access control is both on functionality and data.

3 A subject is an individual or group of named users, devices or programs. An object may be data, processes, files, segments, devices.ibops-protocol-v1.0-wd01 Working Draft 01 31 October 2014Standards Track Draft Copyright © OASIS Open 2014. All Rights Reserved. of 19

4 Best practices and Security Considerations4.1 Intrusion Detection

4.1.1 OverviewThe IBOPS standard requires the implementation of intrusion detection capabilities. Depending on the specific implementation, these capabilities may provide active monitoring and blacklisting functionality to help address attacks, including credential spoofing via certificate impersonation, session replay, detection and prevention of account brute-forcing, session creation failures, and/or the detection of denial-of-service (distributed or single DOS) attacks. These functions should be governed by one or more intrusion detection systems which can take appropriate actions such as terminating session creation or blacklisting devices and/or IP addresses.The IBOPS standard also requires specific intrusion detection capabilities implemented within a system on both server and client sides. Client-side intrusion detection must be capable of identifying patterns of trial and error in order to blacklist itself, or if the user fails to authenticate more than a configurable consecutive times. On a typical IBOPS implementation this could be around 4. Blacklisting may be enacted for a fixed period of time or indefinitely until the device can be properly assured that it is safe and valid. The IBOPS server can query the Intrusion Detection System (IDS) whether is a device is blacklisted or not. If the device is blacklisted, all communication ceases. Depending on implementation, blacklisting may occur at the device level, the IP address level, the subnet level or beyond. A typical implementation may only blacklist on Device ID.The following outlines an intrusion detection function for IBOPS.

4.1.2 Replay PreventionOne of the largest threats to network based systems is replay. Consider the scenario of an attacker modifying target software on a device and/or stealing session information from a valid session for replay, in an attempt to gain unauthorized access to a server.Replay mitigation uses replay check values that are built into the communication to help prevent this type of attack.From the server side perspective, the server has to recognize that the replay check values are not correct when under attack so the device can be blacklisted. The replay check values are requested by the client during Genesis and are one way encrypted by the IBOPS Server. The Boriken server looks up the one way encryption to find the values used for replay mitigation. Subsequent client calls use the check values placed by the client and expected by the server. If the values are as expected, communication continues. If the replay values are not expected the IDS receives a notification. Enough notifications and the client is blacklisted.

4.2 Standards, Audit, and Quality Control

4.2.1 StandardsIBOPS is designed to meet several minimum standards, including assessment against the Trusted Computer System Evaluation Criteria (TCSEC), which is a US Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system, the Director of the Central Intelligence Directive 6/3 protection levels 3, 4, and 5 (PL3, PL4, PL5), and the standards of Multiple Independent Levels of Security (MILS).


4.2.2 Audit CapabilitiesAuditing ensures the appropriate artifacts for continued verification and validation of trusted access. All administrative actions (modification via the Admin dashboard) and authentication actions are captured and stored in a data repository. Account-specific authentication records can be audited by a user with Administrator privileges, via an administrator dashboard.

4.3 Data Protection

4.3.1 Network TransmissionsAll network transmissions are required by the BOPS standard to run over Transport Layer Security (TLS) or its predecessor Secure Sockets Layer (SSL), with server and client-side X.509 certificates enforcing two-way authentication. Boriken servers (typically Apache Tomcat) are configured to use TLSv1.2.Before a client and server can begin to exchange information protected by TLS, they must securely exchange keys and/or agree upon encryption keys and a cipher to use when encrypting data. These options are configurable and can also be negotiated on a per-session basis in line with client-side capabilities. For instance, if a client machine / application does not support TLSv1.2, then it may fallback to lower version.Exact TLS configuration depends upon the IBOPS-compliant server configuration4. Naturally, strong key generation and exchange algorithms are encouraged - similarly with encryption algorithms, in recognition of possible constraints such as compatibility or performance issues.

4.3.2 Data Protection StrategyThe general IBOPS standard philosophy is to prevent the centralized storage of sensitive data in one place. IBOPS does not create large server-side repositories of sensitive client data such as biometric images, for example.Also as a general rule, encrypted data and the key to decrypt that data should not be in the same place. For example, in an IBOPS system, sensitive data such as the user’s website credentials are stored encrypted on the mobile device, with the associated key stored in the IBOPS server repository, attached to the user’s account. This helps prevent an attacker who has gained access to the mobile from reading the credentials, and vice-versa.

4.3.3 Client-side dataSensitive data stored on the client side includes: the user’s biometric vector5 (NOT the full biometric) the encrypted p12 file containing Client Certificate client certificate and private key (optional or implementation specific) encrypted6 user authentication data for third party identity

systemsOn IOS, all of this data is stored in the IOS KeyChain. This is an encrypted container that holds passwords for multiple applications and secure services.

4 This is blank in the v4 doc5 The sensitivity of the biometric vector is debatable, as a full biometric can usually not be extracted from the vector and in the event the vector is stolen we help address replay via the intrusion detection capabilities plus presence of the Client Certificate.6 The user authentication data is stored in the same encrypted format that was returned from the Boriken server during genesis/enrolment. The data gets encrypted by the server using the Elliptic Curve Integrated Encryption Scheme (ECIES#) algorithm. The key used for this encryption (571 ECC) was generated and is stored on the server.ibops-protocol-v1.0-wd01 Working Draft 01 31 October 2014Standards Track Draft Copyright © OASIS Open 2014. All Rights Reserved. of 19

On Android the p12 is stored in the app shared preferences7:/data/data/com.your.package/shared_prefs/com.your.package_preferences.xmlThe biometric vector is stored internal to the client side application.It is important to note that except for a handful of unique situations, a full biometric data set cannot be derived from a biometric vector, and that the possession of a biometric vector alone is not sufficient in order to obtain authenticated access to the IBOPS server. Identity Assertion under the IBOPS standard relies on several stages of authentication, including biometric vector matching, liveness checking, and the submission of the Client Certificateclient certificate. Should the biometric vector be replaced/replayed, a Client Certificate client certificate must also be present and liveness must succeed in order to impersonate a user. In addition, IBOPS has replay protection mechanisms built in (see the section titled Replay Prevention).

4.3.4 Server-side data

4.3.5 IBOPS Server DataSensitive data that may be stored within the Boriken server includes: Device identifiers Geospatial locations User identifiers such as email, phone number User roles Client Certificate client certificate password data Other possible attributes sent to the BOPS server during Genesis and/or session creation.Depending on the IBOPS product or solution, session creation may add sensitive data. For example, the withdrawal of money from an ATM will add the account and amount as sensitive data.Every session that is started and completed for and on behalf of a user or devices is also stored as an audit/history. This allows administrators or other privileged users to see usage patterns and other critical audit data.

7 http://developer.android.com/reference/android/content/SharedPreferences.htmlibops-protocol-v1.0-wd01 Working Draft 01 31 October 2014Standards Track Draft Copyright © OASIS Open 2014. All Rights Reserved. of 19

http://developer.android.com/reference/android/content/SharedPreferences.html

5 # ConformanceThe last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here. [Remove # marker]


Appendix A. AcknowledgmentsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!

[Participant Name, Affiliation | Individual Member][Participant Name, Affiliation | Individual Member]


Appendix B. Implementation Exampletext

B.1 Subsidiary sectiontext

B.1.1 Sub-subsidiary sectiontext


Appendix C. Revision History

Revision Date Editor Changes Made

[Rev number] [Rev Date] [Modified By] [Summary of Changes]


ibops protocol version 1.0 - oasis | advancing open ... · web viewfirst of all, the ibops...

Documents