SXS Confirmation Protocol (SXS-Confirm)Comodo Group Inc.philliph@comodo.com
General
CryptographyPKIPKIXJSON Confirmation Protocol (JCP) is a three party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes. Authentication of end users is one of the biggest challenges for Internet and Web security today. Despite an abundance of technology that offers authentication mechanisms that are more robust, more secure and easier to use, the default mechanism for user authentication is the use of usernames and passwords. Unlike traditional schemes, JCP is designed for implementation on a device that has at least the capabilities of a modern 'smartphone'. In particular an JCP client device must support a display, a means of accepting text input from the user and a connection to the Internet. While mobile devices offering this degree of functionality were rare in 2007, they have since become ubiquitous. It is thus now a practical proposition for a site requiring second factor authentication to support at least a part of its users using a technology that requires this level of capability. Indeed software applications that emulate traditional second factor authentication protocols on such devices have been available for some time. Second factor authentication mechanisms offer greater security over the use of passwords alone by combining a first factor (typically a password) with a biometric or proof of possession of a physical token. Traditional second factor authentication techniques have suffered from the need to distribute physical tokens and the difficulty of ensuring that a biometric authentication is presented to a trustworthy terminal. The usability of traditional second factor authentication techniques has been poor or worse. Even the simplest scheme in which the user is required to read in a 'one time use' numeric code from the authentication token device and enter it into a password field. While such operations are relatively simple they require the user to engage in a sequence of operations that bears no necessary or natural relationship to the underlying task for which the authentication is required. Nor does the act of engaging in a traditional second factor scheme offer proof of anything other than that the user was authenticated. Any correspondence between the act of authentication and the purpose for which the authentication was provided must be maintained separately. A second factor confirmation service addresses the limitations of traditional second factor authentication schemes. A confirmation service allows the user experience to be precisely matched to the action that the user is attempted. Instead of beinf asked to read a random number from one device and enter it into another, the user is asked if they really want to perform the action for which authentication is requested. A confirmation service offers better accountability for end users than a traditional authentication service. An authentication service only provides an assertion that the user was present. A confirmation service provides an assertion that the user was present and that they confirmed a specific transaction. For example, Alice has been granted access to a machine storing classified data. If an authentication service is used for access control, the authentication service log will only record the dates and times that Alice accessed the system. to find out if Alice accessed a particular file on a particular day it is necessary to consult and correlate both the authentication log of the system and the activity log for the application. If instead a confirmation service is used the confirmation log contains an authenticated record of both the authentication events and the transactions for which the authentication was requested. A confirmation service complements rather than replaces a traditional authentication scheme. Providing a highly secure and convenient means of authenticating requests that carry a high degree of risk mitigates the risk of using convenient but intrinsically low security techniques for other actions. If an attacker is to profit from breaching a an account with a financial service such as a bank or a brokerage they must find a way to move money out of the account. Thus adding bill payment recipients, initiating wire transfers and trading in low volume 'penny stocks' represent high risk activities. For example: Bank of Ethel might permit customers to use a simple username and password scheme to gain access to their account for the purpose of checking their balance or paying bills to existing reciepients but require use of the second factor confirmation device for a high risk transaction such as paying a bill. A second factor confirmation service may be combined with a machine level authentication scheme to permit a transparent form of authentication for low risk transactions. For example: Alice stores her low risk authentication credentials (e.g usernames and passwords) using a 'cloud' service. When she wishes to use those credentials an agent on her personal machine fetches credentials from the cloud service as necessary. When Alice wishes to access a site from a different machine she receives a confirmation request on her mobile device to grant access from that machine. Use of such a mechanism is clearly more satisfactory when suitable cryptographic protocols such as SAML or Kerberos are employed to limit the disclosure and hence possible compromise of the credentials. The specification of such protocols is outside the scope of this document. Although JCP is designed for use in a three party scenario, there are situations in which a two party mode may be preferred. For example: Bob is a roadwarrior who requires access to confidential documents stored on his laptop device from anywhere in the world, including locations where Internet access is not possible. To permit access in such circumstances, Bob's JCP client supports use of a tethered mode in which the mobile device is plugged into his laptop via a USB port. For example: Carol is a network manager of a large computing facility that uses JCP to authenticate and track all changes to critical resources. Since JCP is itself a network resource a bootstrap consideration arises: How can Carol confirm her network configuration requests using JCP when the network itself is down? Support for a tethered mode in which the JCP device communicates via USB or similar wired protocol allows this use case to be supported. While availability of a tethered mode is clearly essential if JCP is to be used in certain applications, support for this feature outside the scope of this version of the specification. While JCP is designed for deployment on a secondary device, deployment on the same device as the one for which confirmation is being requested is also possible and can provide security benefits. Modern Web browsers are large and complex with many features such as support for mobile code that are incompatible with a high security environment. Separating the confirmation protocol from the Web Browsing protocol permits implementation in a minimal client designed to permit detailed security analysis. Such a client might be embedded in or support means of secure interaction with a trustworthy operating system component. While this means of deployment does not provide a true second factor confirmation, it is likely to provide a sufficient degree of authentication for many transactions. JCP is a Web Service that permits a Enquirer to request that a User confirm or reject a specified action. If the user responds, the response is signed with a digital signature under a key that is unique to the user account, the client and the device. Each JCP protocol interaction takes place between a connection pair of the following parties: A party that initiates a confirmation request. The User is the person being asked to grant or refuse confirmation. A User MAY have multiple accounts with multiple Broker Services. A device that the user has bound to their broker account. A clearing house that stores and forwards requests from Initiators to Users Device and responses from Users to Initiators. The Broker is only trusted to perform routing filtering and recording of requests and responses. The Broker is not trusted with respect to the responses returned. Users are identified by means of an account identifier. The display presentation of an account identifier is the form of an RFC2822 email address identifier without the enclosing angle braces, for example: alice@example.com The account identifier is used by the User when registering the use of the confirmation service with a Broker. An JCP service MAY be Open or Closed. An Open service provider provides JCP service to the general public. A Closed service provider only provides service to a specific community. For example: An Internet Service Provider or DNS Registrar might provide an open JCP service as a part of their standard service offering to customers. An employer might operate a closed JCP service to be used for company business. SXS-Confirm is presented in JSON encoding [RFC4627] over a HTTP Session [RFC2616] using HTTP Session Continuation [I-D.hallambaker-httpsession] for message layer authentication. Implementations MUST support and SHOULD use TLS transport for confidentiality and server authentication [RFC4627]. The Session Connection Service (SXS) [I-D.hallambaker-wsconnect] is used to establish the connection between the User Device and the Broker and the Initiator and the Broker. In each case the Broker is the SXS service. The Initiator and User Device are SXS clients. SXS supports mutual and server-only authentication modes. Authentication MAY be performed using a wide range of client authentication mechanisms including PIN based, Out Of Band, PKI and none. For a Private broker, the choice of authentication mode and credential lifetime is left to individual site policy. Alice is a new employee of Example Inc which has the domain example.com. To make use of the connfirmation service, Alice must first configure her device for use. This would typically be performed once for the lifetime of the device. Her system administrator issues her with an account alice@example.com and a one time use PIN Q80370-1RA606-F04B.Alice installs an SXS-Confirm application on her device. To configure the device she supplies the data proivided by the system administrator:The application MAY allow Alice to enter additional passwords and/or capture biometric profile data to provide multi-factor authentication in cases in which this is required. The device makes an SXS service establishment request: The service verifies the request and issues a challenge to verify holdership of the PIN: Having received the challenge, the client presents proof of knowledge of the PIN:The service now completes the transaction by returning the connection credentials:Note that for the sake of brevity, only a single confirmation host is specified in these examples. A service MAY specify multiple hosts to provide for service connectivity in the case of a service outage affecting only one host.Having connected her device to the SXS-Confirm service, Alice begins work. She attempts to gain access to a restricted Web Site in the corporate Intranet. This site requires that she confirm this request using her registered User Device and that the BIOMETRIC authentication factor be used as a second factor.Alice enters her account into the site. Note that she does not supply a password to the site. The Web site initiates a request for confirmation of the access request. It begins by identifying the service from Alice's account as example.com. If the Initiator has already established a connection to this broker and it has not expired, that connection is reused. Otherwise the Initiator MUST establish a connection to the Broker. This has two steps, broker discovery and the session establishment itself. To obtain the broker for the SXSConfirm service, the SRV Service Discovery mechanism [RFC2782] and Well Known Service conventions [RFC5785] are used: Initiator clients MUST support the following service discovery mechanism: [1] Attempt to resolve an SRV record for _sxsconfirm._tcp.<host>[2] If no SRV record is found a client MAY attempt to discover the service at https://<host>/.well-known/sxsconfirm/The Initiator begins by retrieving the SRV record for example.com:The service randomly selects the host sxsconfirm1. The Web Service Endpoint for the SXSConfirm service is therefore: Having determined the service endpoint, the Initiator attempts to establish a connection. Since this is a server to server interaction, TLS Certificate based Client Authentication is used in combination with the SXS BindRequest: Having established a connection to the service, the Initiator can make its confirmation request: Broker Responds:Before she can respond to an individual message, Alice must first download her pending requests from the broker: Broker Responds:Alice can now confirm the request from the Web Server: Broker Responds:The Broker can now provide the Initiator with its response: Broker Responds:Note that since the user might take seconds, minutes, hours or even days to respond to a request, more than one mechanism for returning the User response to the Initiator is required. These mechanisms are:A broker MAY allow an Initiator to keep the initial HTTP session alive for a sufficiently long interval for the user to respond.A broker MUST support the AskStatus transaction that permits the Initiator to query the status of a pending transaction. This mechanism permits a Broker to set a minimum interval within which a status update request will be responded to and refuse queries that are too frequent.An Initiator MAY specify a URI being the Web Service Endpoint of a Web Service to which the Broker may return the user response using the AsyncStatus transaction. The UYFM transport permits low latency status reports to be made with minimal server resource use. A request Binary [1..1] Unique Message Identifier assigned by either the Initiator or broker. Note that unlike an email message identifier, the transaction identifier SHOULD change. DateTime [1..1] Time at which the transaction identifier was issued DateTime [0..1] Time at which the request was initiated if different from the Issue time. String [1..1] The account to which the request was directed. A given user MAY have multiple accounts and multiple users MAY have authority to respond to a given account. String [1..1] Text describing the request to the user. String [0..1] Format of the request text. String [0..Many] Keyword indicating that a particular multi-factor authentication technique is required. String [0..1] Title of the request message String [0..Many] Paragraph of request message text Input [0..Many] Button Entry String [0..1] Specifies a JSON tag name to be specified if the button is pressed to make the response. String [0..1] Specifies a string of text to be returned as the value of the 'Name' tag. String [0..1] Text to be displayed to the user Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors) Uses SXS with the Protocol type SXS-CONFIRM for device bindingPost a request for confirmation to a user. Request a confirmation from a specified user. Binary [0..1] If present specifies a Jose Web Signature Protected Header. Binary [1..1] A Base64 encoded binary field, the contents of which are a MessageItem structure. Binary [0..1] If present specifies a Jose Web Signature Value. URI [0..1] URI of a web service to which the service MAY post an asynchronous reply using the TransactionStatus transaction. Binary [1..1] Unique Transaction Identifier for us in subsequent StatusRequest messages. Query the status of a pending Confirmation transaction Note that the status values only report the success or failure of the transaction itself. User responses are only returned as signed content. Binary [1..1] Unique Transaction Identifier returned in ConfirmationResponse message String [1..1] Confirmation response from the user as specified by the confirmation challenge text. String [1..1] Confirmation response from the user as specified by the confirmation challenge text. Binary [1..1] [TBS]Asynchronous status update on pending transaction. The WrappedData object permits optional authetication data to be added to SXS-Confirm requests and responses. Binary [0..1] If present specifies a Jose Web Signature Protected Header. Binary [1..1] The signed data Binary [0..1] If present specifies a Jose Web Signature Value over the header and payload values. (Implementation only, remove) Superclass that all the requests inherit from Every Query Response contains the following common elements: Integer [1..1] Status return code value String [0..1] Describes the status code (ignored by processors) DateTime [0..1] DateTime [0..1] Integer [0..1] Maximum request text length in bytes Integer [1..1] Number of pending confirmation requests. Integer [0..1] Number of previously answered confirmation requests. Integer [0..1] Number of pending confirmation requests that expired before they were answered. WrappedData [1..Many] List of WrappedData objects in which the Payload field is a pending message. These MAY be returned in any order. Note that the list of messages MAY be incomplete as transactions MAY have been responded to earlier. WrappedData [0..1] A WrappedData object whose payload is the response from the user. This is a JSON object whose tags and values are determined by the request markup. String [0..1] If present, the user has indicated that the request is being refused as abusive. For example, the message text is an unsolicited commercial message. Reports the success or failure of the message While JSON markup is sufficient to send the simplest request messages, the limitations of using a data encoding format for what is essentially a document markup are apparent. Simple Request Markup Language (SRML) is a markup language for use in confirmation requests. The capabilities of the basic JSON encoding are provided by the following tags:HeadingParagraphButton specifying a value that the user can select.While SRML is loosely based on the HTML forms markup, there are important differences. The HTML markup model supports multiple document types of which forms are only one and a single document may contain multiple forms with multiple different action values. In an SRML document is a single form and the form action to be performed is impicit in the presentation of the document to the user.The MIME Content Type and schema identifier for SRML areThe schema is The capabilities of SRML are intentionally limited to the bare minimum. It should be possible to make use of SRML to display options to the user on a smartwatch or other device with a highly constrained display. The function of the confirmation service is to provide confirmation of an action that was initiated elsewhere. It is therefore inappropriate for this or any future version of SRML to offer extensive data entry or validation capabilities. SRML applications MUST NOT support any form of scripting or active code extensions to SRML content.It might prove advantageous in the future to extend the input types to include simple form elements such as checkboxes, numeric fields, text choices and possibly free form text.Consider spam control, how do users prevent unwanted requests? (EV accreditatio, filtering at Broker) People deploying JCP as a means of controlling access to networking infrastructure must consider the bootstrap issue. In particular since JCP requires Internet access the network administrator must ensure that it is possible to manage the network resources necessary to support an SXS service when that service is down. JSON Service Connect (JCX) ProtocolA DNS RR for specifying the location of services (DNS SRV)Troll TechInternet Software ConsortiumMicrosoft CorporationDefining Well-Known Uniform Resource Identifiers (URIs)The application/json Media Type for JavaScript Object Notation (JSON)Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceWorld Wide Web ConsortiumCompaq Computer CorporationWorld Wide Web ConsortiumXerox CorporationMicrosoft CorporationWorld Wide Web ConsortiumHTTP Session Management