Internet Engineering Task Force (IETF) Phillip Hallam-Baker Internet-Draft Comodo Group Inc. Intended Status: Standards Track May 9, 2014 Expires: November 10, 2014 Service Connection Service (SXS) draft-hallambaker-wsconnect-07 Abstract Service Connection Service (SXS) is a JSON/REST Web Service that may be used to establish and maintain a 'connection binding' of a device to an account held with a Web Service Provider. Multiple connection bindings may be established under the same account to support multiple devices and/or multiple users of a single device. A connection binding permits a device to securely connect to one or more services offered by the Web Service Provider with support for protocol and protocol version agilty and fault tollerance. The protocol is presented as a HTTP/JSON Web Service and uses the HTTP session continuation mechanism for authentication of transaction messages and supports negotiation of a HTTP session continuation mechanism context for the established endpoint connections. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Hallam-Baker November 10, 2014 [Page 1] Internet-Draft Service Connection Service (SXS) May 2014 described in the Simplified BSD License. Hallam-Baker November 10, 2014 [Page 2] Internet-Draft Service Connection Service (SXS) May 2014 Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Introduction and Purpose . . . . . . . . . . . . . . . . . . . 5 2.1. Establishing a Web Service Provider Account . . . . . . . 5 2.2. Establishing a Connection Binding . . . . . . . . . . . . 6 2.2.1. Anonymous. . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. PIN Code Establishement. . . . . . . . . . . . . . . 7 2.2.3. Out of Band Completion. . . . . . . . . . . . . . . 7 2.2.4. QR Code Preauthorization. . . . . . . . . . . . . . 7 3. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. PIN code establishment . . . . . . . . . . . . . . . . . 7 3.2. Unbinding . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Out of Band Completion . . . . . . . . . . . . . . . . . 13 3.3.1. Message: Message . . . . . . . . . . . . . . . . . . 13 3.3.2. Message: Response . . . . . . . . . . . . . . . . . 13 3.3.3. Message: ConnectionRequest . . . . . . . . . . . . . 14 3.3.4. Structure: Cryptographic . . . . . . . . . . . . . . 14 3.3.5. Structure: ImageLink . . . . . . . . . . . . . . . . 14 3.3.6. Structure: Connection . . . . . . . . . . . . . . . 14 4. OBPConnection . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Message: BindRequest . . . . . . . . . . . . . . . . 15 4.2. BindPIN . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Message: OpenPINRequest . . . . . . . . . . . . . . 16 4.2.2. Message: OpenPINResponse . . . . . . . . . . . . . . 17 4.3. Ticket . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Message: TicketRequest . . . . . . . . . . . . . . . 18 4.3.2. Message: TicketResponse . . . . . . . . . . . . . . 18 4.4. Unbind . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. Message: UnbindRequest . . . . . . . . . . . . . . . 18 4.4.2. Message: UnbindResponse . . . . . . . . . . . . . . 18 5. Mutual Authentication . . . . . . . . . . . . . . . . . . . . 19 5.1. PIN Authentication . . . . . . . . . . . . . . . . . . . 19 5.1.1. Example: Latin PIN Code . . . . . . . . . . . . . . 21 5.1.2. Example: Cyrillic PIN Code . . . . . . . . . . . . . 22 5.2. Out of Band Confirmation . . . . . . . . . . . . . . . . 22 6. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. JSON encoding . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. HTTP Session Layer . . . . . . . . . . . . . . . . . 24 6.1.2. TLS transport . . . . . . . . . . . . . . . . . . . 24 7. Service Identification and Discovery . . . . . . . . . . . . . 25 8. UDP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 26 8.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 28 10.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . 28 Hallam-Baker November 10, 2014 [Page 3] Internet-Draft Service Connection Service (SXS) May 2014 10.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. Stateless server . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Temporary ID . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Connection Binding ID . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Hallam-Baker November 10, 2014 [Page 4] Internet-Draft Service Connection Service (SXS) May 2014 1. Definitions 1.1. Requirements Language The 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]. 2. Introduction and Purpose Service Connection Service (SXS) is a Web Service that may be used to establish and maintain a 'connection binding' of a device to an account held with a Web Service Provider (WSP). SXS is presented in JSON encoding [RFC4627] over a HTTP Session [RFC2616] using HTTP Session Continuation [I-D.hallambaker- httpsession] for message layer authentication and TLS transport for confidentiality and server authentication [RFC4627]. A Connection Binding comprises a set of long term credentials used to authenticate interactions with the SXS service itself and a set of 'Service Connections' to specific services offered by the Web Service Provider. Each service connection in turn comprises a collection of 'Instance Connections' which describe a specific instances of the Web Service. For example Alice is a consumer and example.com a provider of a range of Web Services including anti-malware protection and management of home automation devices. Alice has 42 devices of different types that each make use of one or more of the Web Services proviced by example.com. All the devices are enrolled in the same SXS account 'alice@example.com' but each device has a unique connection binding and different devices make use of different Web Services. The centralized account provides Alice with a single point of control from which she can authorize the addition of new devices to the account or the removal of devices that are deactivated. This allows Alice to avoid the need to manage a device such as a network-enabled lightswitch through the lightswitch itself. To ensure continuity of service in case of network failure or administration work, example.com provides multiple instances of its Web Services hosted on different machines. Different users MAY be granted access to a different collection of service instances according to their needs and the service tier they are subscribed to. Hallam-Baker November 10, 2014 [Page 5] Internet-Draft Service Connection Service (SXS) May 2014 2.1. Establishing a Web Service Provider Account The means by which the Web Service Provider Account is established is outside the scope of this document. In a typical case the user would establish an account with their chosen Web Service Provider through the normal process of using a Web Browser to access the Web Service Provider's site and entering such data as the Web Service Provider requires into a HTML form. Depending on the circumstances, the data provided by the applicant may require verification before the account is created. [Default accounts for appliances that are going to be implicitly authenticated by reference to the network they are on.] 2.2. Establishing a Connection Binding A connection binding represents a long term association between a device and an account at the Web Service Provider. The association includes the establishment of an authentication context between the device and the SXS service. An authentication context consists of: A Context Identifier. An authentication algorithm. A secret key. The context identifier is an opaque string assigned by the SXS service. Following the approach introduced in Kerberos, a SXS service MAY eliminate the need to store authentication context information by encoding the authentication algorithm and encrypted secret key in the context identifier. The authentication context can ensure that future communications are secured against impersonation if and only if the original process of establishing a connection binding was secured against communication. Mutual authentication is therefore an essential requirement. The means by which the connection binding is established depend on the affordances of the device in question. Establishing a connection binding to a device with a keyboard is easily accomplished through use of a one-time PIN code. But many embedded devices do not provide a keyboard or similar affordance. The following modes of session establishement are supported: * Anonymous. * PIN Code Establishement. * Out of Band Completion. Hallam-Baker November 10, 2014 [Page 6] Internet-Draft Service Connection Service (SXS) May 2014 * QR Code Establishement. 2.2.1. Anonymous. [TBS] 2.2.2. PIN Code Establishement. To establish a connection binding for a new mobile phone, Alice logs into her SXS account manager and requests a new PIN code. She then starts the application that makes use of a SXS account and selects 'create new binding'. She is prompted for and enters her account name (alice@example.com) and PIN. The client connects to the SXS service and verifies that the TLS certificate presented is correct for example.com and has been issued in accordance with issue practices that ensure an appropriately high degree of trust (e.g. the CABForum Extended Validation requirements). 2.2.3. Out of Band Completion. To establish a connection binding for her new toaster oven, Alice plugs the appliance into her local network and enters her account name into the device. Since she has not obtained a PIN code in advance, she leaves the entry blank. To complete the process, Alice logs into her SXS account where she sees that a new device is available to add to the account. To help identify the correct device, there is a picture of the toaster oven, the model name and serial number. 2.2.4. QR Code Preauthorization. Alice decides to remodel the kitchen completely and plans to install a dozen new network enabled LED light fixtures. Using an application on the mobile phone she enabled earlier, Alice scans a QR code attached to each fixture before the devices are installed. When the fixtures are installed and powered, the connection binding is preauthorized. 3. Example Uses 3.1. PIN code establishment Alice buys a new laptop computer which she wishes to use with the malware protection service provided by example.com. Alice has an existing account 'alice' with this Web Service Provider and obtains a pin code Q80370-1RA606-F04B from the Web Service Provider Web site. Hallam-Baker November 10, 2014 [Page 7] Internet-Draft Service Connection Service (SXS) May 2014 Alice enters the values alice@example.com and Q80370-1RA606-F04B into the Web Service client she wishes to use with the Web Service Provider on the new laptop. The client obtains the SXS service for example.com using DNS SRV discovery. The client establishes a TLS connection to the service and verifies that the certificate provided has a valid certificate path, has not been revoked and meets the validation criteria of the client. Since the purpose of this particular Web Service client is to provide security, the client requires that an Extended Validation certificate be presented. Having established a TLS connection to the SXS Service, the client sends the following HTTP request: POST /.well-known/sxs-connect/ HTTP/1.1 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Host: localhost:8080 Content-Length: 368 Expect: 100-continue Connection: Keep-Alive { "OpenPINRequest": { "Encryption": ["A128CBC", "A256CBC", "A128GCM", "A256GCM"], "Authentication": ["HS256", "HS384", "HS512", "HS256T128"], "Account": "alice", "Service": ["sxs-confirm-user", "omni-query"], "Domain": "example.com", "HaveDisplay": false, "Challenge": " sKA6bc3nmz3uprQBBU2zAg"}} To prevent man in the middle attack, the client does not send the PIN code in the initial request. The PIN code is only sent after the service responds with a challenge nonce to be used to prevent replay attack. The service receives the request, determines that is meets its access control policy and selects a set of cryptographic parameters from the set proposed by the client. In this case the service prefers the use Hallam-Baker November 10, 2014 [Page 8] Internet-Draft Service Connection Service (SXS) May 2014 of AES128CBC for encryption and the HS256 Message Authentication Code for authentication. The service determines that a PIN code has been issued for the account and uses the value of that PIN to generate a response to the challenge presented by the client. A new challenge is generated to test the client knowledge of the PIN. [TBS: Is there a need for the service to be able to support multiple outstanding PIN codes for the same account? This could be supported by providing the last 2 significant characters of the PIN code to the service which could use it as an index. This would enable several hundred simultaneous outstanding requests which should be enough for most applications. Large volume applications would need to use a different scheme.] The service sends the following response to the client: HTTP/1.1 OK Success Content-Length: 501 Date: Fri, 09 May 2014 20:58:44 GMT Server: Microsoft-HTTPAPI/2.0 { "OpenPINResponse": { "Status": 200, "StatusDescription": "Success", "Challenge": " zcC-5fRyxt4jcs0EB-4K3A", "ChallengeResponse": " Q8TwekAUDzl4aPutANDKdCWV1W0pPmQRMPT-2EzbTc4", "Cryptographic": { "Secret": " oXMBBpsq_zj5i6v_7wJpzQ", "Encryption": "A128CBC", "Authentication": "HS256", "Ticket": " _IXWEJgzv8fUb301-dNfrx_3BQZlrJx14elyFkBGwN_rEV6SBu27clhVVJw6LTHB sCx950rXH2JjHut1AvS53P_hQDImq3d3xU0UmMCrU-BJc-bwMrmM-B80lJ58dMbq QwFWonJ0GRP2lHbdGh7cUA"}}} To complete the transaction, the client sends a TicketRequest message to the service containing a response to the PIN challenge sent by the service (ChallengeResponse). The TicketRequest message is authenticated using HTTP Session authentication under the shared secret specified in the OpenResponse message: Hallam-Baker November 10, 2014 [Page 9] Internet-Draft Service Connection Service (SXS) May 2014 POST /.well-known/sxs-connect/ HTTP/1.1 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Session: Value=pPU3LpOcvbuva6vEvaxVekLiRmpOv-qi9ZoTKlJjWFY; Id=_IXWEJgzv8fUb301-dNfrx_3BQZlrJx14elyFkBGwN_rEV6SBu27clhVVJw6 LTHBsCx950rXH2JjHut1AvS53P_hQDImq3d3xU0UmMCrU-BJc-bwMrmM-B80lJ5 8dMbqQwFWonJ0GRP2lHbdGh7cUA Host: localhost:8080 Content-Length: 153 Expect: 100-continue { "TicketRequest": { "Service": ["sxs-confirm-user", "omni-query"], "ChallengeResponse": " pPTHKBhgjy458yZ0sLmbwTz3X0V48sl5QFM1nDJ5nbs"}} The service checks the value of ChallengeResponse against the known PIN and if the result is correct establishes parameters for the Connection Binding for the device. In this case the server uses the Session Id parameter to encode permissions associated with the request as described in [Appendix TBS]. Accordingly the server must replace the Session Id whenever the associated permissions change. Accordingly, the server replaces the cryptographic parameters specified in the OpenResponse request for use in future SXS service requests. In this case the server returns three connections, each offering a different transport protocol option. Each connection specifies its own set of cryptographic parameters (or will when the code is written for that). The service also returns a service connection the malware protection service the client requested access to. This service connection specifies three different service instances. Each service instance has its own set of cryptographic parameters for use with HTTP session authentication. In this case the three different service instances offer different means of accessing the same service: as a JSON Web Service over HTTP, using a binary encoding over a UDP transport and tunnelling via DNS. Hallam-Baker November 10, 2014 [Page 10] Internet-Draft Service Connection Service (SXS) May 2014 HTTP/1.1 OK Success Content-Length: 1762 Date: Fri, 09 May 2014 20:58:44 GMT Server: Microsoft-HTTPAPI/2.0 { "TicketResponse": { "Status": 200, "StatusDescription": "Success", "Cryptographic": [{ "Protocol": "sxs-connect", "Secret": " Ts8WL3lUeUdbPyETll_jhA", "Encryption": "A128CBC", "Authentication": "HS256", "Ticket": " Yvq3L02noKJTBhevt4uKupP8pTSdgIJPjRYsXRZRVbHW8XVccLWimZWkCNiqGeMu o3Bld8p3-4585-akLuMgmmYk3zSxJqftGdczjIc-358"}], "Service": [{ "Service": "sxs-confirm-user", "Name": "localhost", "Port": 8080, "Priority": 100, "Weight": 100, "Transport": "HTTP", "Cryptographic": { "Secret": " kRs_k-KRuNtcVwNDlTigBw", "Encryption": "A128CBC", "Authentication": "HS256T128", "Ticket": " hXtRoSM8R6cHGRZ_o91ku8m5bV8F4C-f5UAQwpjqd5aS4GlvvATgnCTFqEMHjucf zQvtshkFfa7N4DnXMqEzk7-to-QX_FXfLfmwOaxRu9g"}}, { "Service": "omni-query", "Name": "localhost", "Port": 8080, "Priority": 100, "Weight": 100, "Transport": "HTTP", "Cryptographic": { "Secret": " Gk1UJQD33PTRHFn3ELPZWw", "Encryption": "A128CBC", "Authentication": "HS256T128", "Ticket": " J5gl0H3qNlG7OZOuK1Kg2TrH6ttodvBML736zxHpzhyAD2wt-sneJt2TesBP_sgI BxKI9NsrJZM9iluwiey8J7c8jjncun0nkFmzc8ZsOvY"}}, { "Service": "omni-query", "Name": "localhost", Hallam-Baker November 10, 2014 [Page 11] Internet-Draft Service Connection Service (SXS) May 2014 "Port": 9090, "Priority": 100, "Weight": 100, "Transport": "UDP", "Cryptographic": { "Secret": " P4ImlUQKCsYx3EYmEIed0g", "Encryption": "A128CBC", "Authentication": "HS256T128", "Ticket": " -S_geXUfMQVn4VHQE9aIoeaxtgQovmfVxK2ZGg-Ui2uumdKSwfEvDZtchaLAJLQL VwyrtDsn3seDRK5WJhkg27Hq7LLRVFSZMfotr9Y9xqM"}}]}} 3.2. Unbinding After a year of use, Alice decides to replace the laptop with a new one. Before selling the old laptop on EBay, she tells the Web Service client to cancel the connection to the Web Service Provider. The client sends the following mesasage to the provider: POST /.well-known/sxs-connect/ HTTP/1.1 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Session: Value=k6kaBdumXWBHcMXiRHL8HyF49beYScWIx287K-dws6c; Id=_IXWEJgzv8fUb301-dNfrx_3BQZlrJx14elyFkBGwN_rEV6SBu27clhVVJw6 LTHBsCx950rXH2JjHut1AvS53P_hQDImq3d3xU0UmMCrU-BJc-bwMrmM-B80lJ5 8dMbqQwFWonJ0GRP2lHbdGh7cUA Host: localhost:8080 Content-Length: 24 Expect: 100-continue { "UnbindRequest": {}} The Session ID specifies the connection binding. Since the Unbind Request is only valid for that connection binding, there is no need to specify the connection binding further in the request. The server verifies that the request was authenticated and returns a successful response: HTTP/1.1 OK Success Content-Length: 79 Date: Fri, 09 May 2014 20:58:44 GMT Server: Microsoft-HTTPAPI/2.0 { "UnbindResponse": { "Status": 200, "StatusDescription": "Success"}} Hallam-Baker November 10, 2014 [Page 12] Internet-Draft Service Connection Service (SXS) May 2014 3.3. Out of Band Completion Alice purchases an Internet enabled coffee pot. The installer configures the coffee pot in her kitchen but does not have access to Alice's SXS account or a PIN code to configure it. The installer configures the coffee pot to use the SXS account specified by Alice. The coffee pot does not have a pssscode to enter but does have a link to an image of the coffee pot. The client sends the following request: [TBS: non pin code example] Since the client does not have a PIN code, there is no need to return a challenge. Instead the service returns the status "OOB" to indicate that the transaction will be completed out of band. [TBS: non pin code example] By default the coffee pot attempts to complete the SXS connection at ten second intervals for the first ten minutes, every thirty seconds for the next hour, every five minutes for the following 24 hours and once an hour thereafter. The client sends the following request to check the status of the request: [TBS: should add in a parameter 'don't call again for x seconds'] The first service response tells the coffee pot not to ask again until five minutes have elapsed: [TBS: non pin code example] The installer calls Alice to tell her that the coffee pot is ready to connect. Alice authorizes the connection remotely via the Web Service Provider's Web site. Alice identifies the request to connect the coffee pot by means of the image provided. She can also use the same image to help determine which connection to cancel when the coffee pot is replaced. The next time the coffee pot requests a status update, the service responds with the connection binding parameters: [TBS: non pin code example] 3.3.1. Message: Message Hallam-Baker November 10, 2014 [Page 13] Internet-Draft Service Connection Service (SXS) May 2014 3.3.2. Message: Response Status : Integer [0..1] Application layer server status code StatusDescription : String [0..1] Describes the status code (ignored by processors) 3.3.3. Message: ConnectionRequest 3.3.4. Structure: Cryptographic Parameters describing a cryptographic context. Protocol : Label [0..1] OBP tickets MAY be restricted to use with either the management protocol (Management) or the query protocol (Query). If so a service would typically specify a ticket with a long expiry time or no expiry for use with the management protocol and a separate ticket for use with the query protocol. Secret : Binary [1..1] Shared secret Encryption : Label [1..1] Encryption Algorithm selected Authentication : Label [1..1] Authentication Algorithm selected Ticket : Binary [1..1] Opaque ticket issued by the server that identifies the cryptographic parameters for encryption and authentication of the message payload. Expires : DateTime [0..1] Date and time at which the context will expire 3.3.5. Structure: ImageLink Algorithm : Label [0..1] Image encoding algorithm (e.g. JPG, PNG) Image : Binary [0..1] Image data as specified by algorithm Hallam-Baker November 10, 2014 [Page 14] Internet-Draft Service Connection Service (SXS) May 2014 3.3.6. Structure: Connection Contains information describing a network connection. Service : Label [0..1] The service identifier Name : Name [0..1] DNS Name. Since one of the functions of an OBP service is name resolution, a DNS name is only used to establish a connection if connection by means of the IP address fails. Port : Integer [0..1] TCP or UDP port number. Address : String [0..1] IPv4 (32 bit) or IPv6 (128 bit) service address Priority : Integer [0..1] Service priority. Services with lower priority numbers SHOULD be attempted before those with higher numbers. Weight : Integer [0..1] Weight to be used to select between services of equal priority. Transport : Label [0..1] OBP Transport binding to be used valid values are HTTP, DNS and UDP. Expires : DateTime [0..1] Date and time at which the specified connection context will expire. Cryptographic : Cryptographic [0..1] Cryptographic Parameters. 4. OBPConnection 4.1. Bind 4.1.1. Message: BindRequest The following parameters MAY occur in either a StartRequest or TicketRequest: Service : Label [0..Many] The service identifier for the protocol for which a connection is being established. Hallam-Baker November 10, 2014 [Page 15] Internet-Draft Service Connection Service (SXS) May 2014 Encryption : Label [0..Many] Encryption Algorithm that the client accepts. A Client MAY offer multiple algorithms. If no algorithms are specified then support for the mandatory to implement algorithm is assumed. Otherwise mandatory to implement algorithms MUST be specified explicitly. Authentication : Label [0..Many] Authentication Algorithm that the client accepts. If no algorithms are specified then support for the mandatory to implement algorithm is assumed. Otherwise mandatory to implement algorithms MUST be specified explicitly. 4.2. BindPIN Binding a device with mutual authentication is a two step protocol that begins with the OpenPINRequest followed by the Ticket Request. 4.2.1. Message: OpenPINRequest The OpenRequest Message is used to begin a device binding transaction. Depending on the authentication requirements of the service the transaction may be completed in a single query or require a further Ticket Query to complete. If authentication is required, the mechanism to be used depends on the capabilities of the device, the requirements of the broker and the existing relationship between the user and the broker. If the device supports some means of data entry, authentication MAY be achieved by entering a passcode previously delivered out of band into the device. The OpenRequest specifies the properties of the service (Account, Domain) and Device (ID, URI, Name) that will remain constant throughout the period that the device binding is active and parameters to be used for the mutual authentication protocol. Account : String [0..1] Account name of the user at the OBP service Service : Label [0..Many] The service identifier for the protocol for which a connection is being established. Domain : Name [0..1] Domain name of the OBP broker service Hallam-Baker November 10, 2014 [Page 16] Internet-Draft Service Connection Service (SXS) May 2014 HavePasscode : Boolean [0..1] Default =False If 'true', the user has entered a passcode value for use with passcode authentication. HaveDisplay : Boolean [0..1] Default =False Specifies if the device is capable of displaying information to the user or not. Challenge : Binary [0..1] Client challenge value to be used in authentication challenge mechanism as described in section [ChallengeResponse] DeviceID : URI [0..1] Device identifier unique for a particular instance of a device such as a MAC or EUI-64 address expressed as a URI DeviceURI : URI [0..1] Device identifier specifying the type of device, e.g. an xPhone. DeviceImage : ImageLink [0..1] An image identifying the physical appearance of the device. DeviceName : String [0..1] Descriptive name for the device that would distinguish it from other similar devices, e.g. 'Alice's xPhone". 4.2.2. Message: OpenPINResponse An Open request MAY be accepted immediately or be held pending completion of an inband or out-of-band authentication process. The OpenResponse returns a ticket and a set of cryptographic connection parameters in either case. If the Challenge : Binary [0..1] Challenge value to be used by the client to respond to the server authentication challenge. ChallengeResponse : Binary [0..1] Server response to authentication challenge by the client as described in section Cryptographic : Cryptographic [0..1] Cryptographic Parameters. Hallam-Baker November 10, 2014 [Page 17] Internet-Draft Service Connection Service (SXS) May 2014 VerificationImage : ImageLink [0..Many] Link to an image to be used in an image verification mechanism. 4.3. Ticket 4.3.1. Message: TicketRequest The TicketRequest message is used to (1) complete a binding request begun with an OpenRequest and (2) to refresh ticket or connection parameters as necessary. Service : Label [0..Many] The service identifier for the protocol for which a connection is being established. ChallengeResponse : Binary [0..1] The response to a serer authentication challenge as described in section 4.3.2. Message: TicketResponse The TicketResponse message returns cryptographic and/or connection context information to a client. Cryptographic : Cryptographic [0..Many] Cryptographic Parameters. Service : Connection [0..Many] A Connection describing an OBP service point 4.4. Unbind Requests that a previous device association be deleted. 4.4.1. Message: UnbindRequest Since the ticket identifies the binding to be deleted, the only thing that the unbind message need specify is that the device wishes to cancel the binding. 4.4.2. Message: UnbindResponse Reports on the success of the unbinding operation. If the server reports success, the client SHOULD delete the ticket and all information relating to the binding. Hallam-Baker November 10, 2014 [Page 18] Internet-Draft Service Connection Service (SXS) May 2014 A service MAY continue to accept a ticket after an unbind request has been granted but MUST NOT accept such a ticket for a bind request. 5. Mutual Authentication A Connection Service MAY require that a connection request be authenticated. Two authentication mechanisms are defined. PIN Code The client and server demonstrate mutual knowledge of a PIN code previously exchanged out of band. Out of Band Confirmation The request for access is confirmed out of band. In addition, services MAY accept the use of any message or transport layer authentication scheme. For example HTTP Session Continuation or Transport Layer Security with client authentication. 5.1. PIN Authentication PIN code authentication provides users with a simple and often familiar mechanism for authenticating the connection request. The means by which the user obtains the PIN code is outside the scope of this document. Possible methods for distributing the PIN code include obtaining the code from an account management Web site provided by the Web Service Provider, letter post, email and in person. Although the PIN value is never exposed on the wire in any form, the protcol considers the PIN value to be text encoded in UTF8 encoding. To encourage readability, the use of space (0x20) and hyphen (0x2D) characters to arrange PIN characters into groups of four to seven characters is encouraged. To avoid the risk of this practice introducing user error, space and hyphen characters are ignored when processing the PIN value. Support for the full UNICODE character set in PIN codes is intended to facilitate provision of PIN codes in the user's native language. Web Service Providers MAY make use of any UNICODE characters they choose but capricious choices are likely to cause users difficulty. For example a PIN code MAY contain the ZAPF Dingbats thick tick mark (U+2704) but users would almost certainly find it difficult to enter and may confuse it with the similar thin tick mark (U+2703). Servers that support PIN Authorization SHOULD offer the choice of a PIN that only uses numeric digits ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9'). Clients that support PIN Authorization MUST allow entry of PINS that only contain numeric digits. Hallam-Baker November 10, 2014 [Page 19] Internet-Draft Service Connection Service (SXS) May 2014 The PIN Mechanism is a three step process: The client sends an OpenRequest message to the Service containing a challenge value CC. The service returns an OpenResponse message containing to the client a server challenge value SV and a server response value SR. The client sends a TicketRequest message to the service containing a client response value CR. Since no prior authentication key has been established the OpenRequest and OpenResponse messages are sent without message authentication. The Challenge values CC, and SC are cryptographic nonces. The nonces SHOULD be generated using an appropriate cryptographic random source. The nonces MUST be at least as long as 128 bits, MUST be at least the minimum key size of the authentication algorithm used and MUST NOT more than 640 bits in length (640 bits should be enough for anybody). The server response and client response values are generated using an authentication algorithm selected by the server from the choices proposed by the client in the OpenRequest message. The algorithn chosen may be a MAC algorithm or an encrypt-with- authentication (EWA) algorithm. If an EWA is specified, the encrypted data is discarded and only the authentication value is used in its place. Let A(d,k) be the authentication value obtained by applying the authentication algorithm with key k to data d. To create the Server Response value, the UTF8 encoding of the PIN value 'P' is first pre-processed to remove space and hyphen characters, then converted into a symmetric key KPC by using the Client challenge value as the key truncating if necessary and then applied to the of the OpenRequest message: [ KPC = A (PIN, CC) SR = A (Secret + OpenRequest, KPC) In the Web Service Binding, the Payload of the message is the HTTP Body as presented on the wire. The Secret and Server Challenge are presented in their binary format and the '+' operator stands for simple concatenation of the binary sequences. This protocol construction ensures that the party constructing SR: Knows the PIN code value (through the construction of KPC). Is responding to the Open Request Message (SR depends on OpenRequest). Has knowlege of the secret key which MUST be used to authenticate the Hallam-Baker November 10, 2014 [Page 20] Internet-Draft Service Connection Service (SXS) May 2014 following TicketRequest/TicketResponse interaction that will establish the actual connection. Does not provide an oracle the PIN value. That is, the protocol does not provide a service that reveals the (since the value SR includes the value SC which is a random nonce generated by the server and cannot be predicted by the client). To create the Client Response value, secret key is applied to the PIN value and server Challenge: CR = A (PIN + SC + OpenResponse, Secret) Note that the server can calculate the value of the Client Response token at the time that it generates the Server Challenge. This minimizes the amount of state that needs to be carried from one request to the next in the Ticket value when using the stateless server implementation described in section This protocol construction ensures that the generator of CR Knows the PIN value. Is respoding to the OpenResponse generated by the server. Note that while disclosure of an oracle for the PIN value is a concern in the construction of CR, this is not the case in the construction of SR since the client has already demonstrated knowledge of the PIN value. 5.1.1. Example: Latin PIN Code The Connection Request example of section demonstrates the use of an alphanumeric PIN code using the Latin alphabet. The PIN code is [[Q80370-1RA606-F04B] and the authentication algorithm is [[HS256]. The value KPC is calculated thus: PIN: 51 38 30 33 37 30 2d 31 52 41 36 30 36 2d 46 30 34 42 Client Challenge: b0 a0 3a 6d cd e7 9b 3d ee a6 b4 01 05 4d b3 02 KPC: 0a 77 30 31 a9 6a d8 92 f5 6f 6c 45 79 d0 7b de 22 15 a5 b8 d3 c2 79 67 29 c5 89 8b 84 c8 2e cc For the sake of example, we take the OpenRequest message payload to be {...}. The data over which the hash value is calulated is Secret + OpenRequest: Hallam-Baker November 10, 2014 [Page 21] Internet-Draft Service Connection Service (SXS) May 2014 Secret: a1 73 01 06 9b 2a ff 38 f9 8b ab ff ef 02 69 cd Request Payload: 7b 2e 2e 2e 7d Server Response: 5e 55 0a 24 e3 8e 79 ae c8 54 9a 33 b5 9e 48 79 38 ed 7a 1d 69 39 34 10 1d 0e b6 24 d1 b5 cb ca The data for the client response is PIN + Server Challenge + Payload: PIN: 51 38 30 33 37 30 2d 31 52 41 36 30 36 2d 46 30 34 42 Server Challenge: cd c0 be e5 f4 72 c6 de 23 72 cd 04 07 ee 0a dc Request Payload: 7b 2e 2e 2e 7d Applying the key Secret to the data produces the client response: Client Response: 90 fc be 1b fd ce 2b 6b 5b d3 2b 5f 42 2f 4a a2 cf 6b bf 54 dd 23 4b 49 18 0b 3e 4e 8f 29 27 47 5.1.2. Example: Cyrillic PIN Code If the PIN code in the earlier example was 'parol1' (the Russian for 'password1') in Cyrilic script the value KP would be calculated as follows PIN: d0 bf d0 b0 d1 80 d0 be d0 bb d1 8c 31 KPC: 0a 77 30 31 a9 6a d8 92 f5 6f 6c 45 79 d0 7b de 22 15 a5 b8 d3 c2 79 67 29 c5 89 8b 84 c8 2e cc The rest of the protocol would then continue as before. 5.2. Out of Band Confirmation The Out Of Band Confirmation mechanism is a three step process in which: * The client makes an OpenRequest message to the service and obtains an OpenResponse message. * The connection binding is authorized through an out of band process. * The client makes a TicketRequest to the service and obtains a TicketResponse message to complete the exchange. Since no prior authentication key has been established the OpenRequest and OpenResponse messages are sent without authentication. Hallam-Baker November 10, 2014 [Page 22] Internet-Draft Service Connection Service (SXS) May 2014 The principal concern in the Out Of Band Confirmation mechanism is ensuring that the party authorizing the request is able to identify which party originated the request they are attempting to identify. If a device has the ability to display an image it MAY set the HasDisplay=true in the OpenRequest message. If the broker recieves an OpenRequest with the HasDisplay value set to true, the OpenResponse MAY contain one or more VerificationImage entries specifying image data that is to be displayed to the user by both the client and the confirmation interface. Before confirming the request, the user SHOULD verify that the two images are the same and reject the request in the case that they are not. Many devices do not have a display capability, in particular an embedded device such as a network switch or a thermostat. In this case the device MAY be identified by means of the information provided in DeviceID, DeviceURI, DeviceImage and DeviceName. 6. Protocol Binding A single protocol binding is defined: * JSON encoding is used to express SXS messages. * A HTTP session layer with HTTP session continuation is used for message authentication. * TLS transport is required for confidentiality and service authentication. Implementations MAY support use of alternative encodings, session layers or transports provided that the necessary confidentiality and authentication criteria described below are met. The means by which negotiation of the use of such encodings is achieved is outside the scop of this document. 6.1. JSON encoding Messages are expressed in JSON encoding [RFC4627]. Protocol schema types are mapped to JSON encoding as follows: Integer Data of type Integer is encoded using the JSON number encoding. Name Data of type Name is encoded using the JSON string encoding. Hallam-Baker November 10, 2014 [Page 23] Internet-Draft Service Connection Service (SXS) May 2014 String Data of type String is encoded using the JSON string encoding. Binary Data of type Binary is converted to strings using the Base64url encoding specified in [!RFC4648] /> and encoded using the JSON string type. DateTime Data of type DateTime is converted to string using the UTC time conversion specified in [!RFC3339] /> with a UTC offset of 00:00. 6.1.1. HTTP Session Layer Messages are presented over a HTTP session layer [RFC2616]. The use of HTTP as a session layer permits multiple Web Services on the same host to share the same DNS name, IP address and port number and enables use of HTTP Session Continuation [I-D.hallambaker- httpsession] for message authentication. Use of HTTP Session Continuation mechanism allows message authentication data to be presented in the HTTP message header rather than the message content provides a clean separation of the message authentication data from the data being authenticated. The scope of the authentication data is simply the message content after transport encoding (e.g. chunked) has been removed. The use of HTTP session continuation is necessary to achieve mutual authentication even though TLS transport is required. Only the HTTP Session header is used. The negotiation of the Session parameters is performed within SXS. [TO-DO: Specify TLS binding options?] [TO-DO: Switch back from using JOSE algorithm names to HTTP Session algorithm names] 6.1.2. TLS transport TLS transport [RFC4627] is used Support for the PKIX logotype extension [RFC3709] is highly recommended Use of an enhanced assurance certificate (e.g. CABForum EV) is likely to be required in most applications and is strongly recommended if Lotypes are used. Hallam-Baker November 10, 2014 [Page 24] Internet-Draft Service Connection Service (SXS) May 2014 7. Service Identification and Discovery The prefix '[PREFIX-TBD]' has been registered for use as a protocol identifier for SXS in the URI, SRV and Well Known Location registries. The URI form identifying a SXS account identifier is: PREFIX-TBD:::< or PREFIX- TBD:::<:subaccount> Where is the DNS name of the Web Service Provider, is the name of the account at the service provider and is an optional sub-account specifier. Use of the URI form is only needed in cases where the purpose of the identifier is not clear from the context, in a HTML anchor for example. A SXS client requesting entry of the service account identifier MUST support entry of the short form identifier: @ or <:subaccount>/@ DNS Service (SRV) record discovery is the preferred method of host discovery as this provides for fault tollerance and load balancing. SXS clients SHOULD support use of DNS SRV records for host discovery and MUST support use of DNS A/AAAA records for host discovery. A compliant SXS service MUST be offered at the .well-known location /.well-known/PREFIX-TBD. Use of SXS protocol at other service locations is permissible for testing and protocol development purposes but such configurations are not compliant and clients are not required to support them. The URL for the SXS service is therefore: https:///.well-known/PREFIX-TBD 8. UDP Binding The UDP Binding allows a transaction to be transmitted as a single UDP packet request followed by up to 16 UDP response packets. The message encapsulation is described using the format desribed in [RFC5246]. Note that in this notation the size of a length specifier is defined by the maximum number of octets permitted in the corresponding data field. For convenience these sizes are given as 255 or 65335 to specify 1 and 2 byte length specifiers respectively. The actual length of the data fields that can be used in practice will depend on the maximum size of UDP packet that can be reliably transmitted. Hallam-Baker November 10, 2014 [Page 25] Internet-Draft Service Connection Service (SXS) May 2014 opaque TransactionID<16..255> opaque SecurityContextID<1..255> 8.1. Request If the UDP transport is in use, a request consists of exactly one packet. A request has the following structure: struct { TransactionID transactionID; SecurityContextID securityContextID; opaque encryptedPayload<1..65535> opaque authenticationCode<1..255> } Request; Where: transactionID Is a unquie identifier for the transaction and an input to the function used to derrive the initialization vector (IV) for the encryption algorithm securityContextID Is the opaque security context identifier returned by the Service Connect Service. encryptedPayload Is the encrypted message payload. 8.2. Response A response MAY consist of 1 or up to 16 packets, each formatted as follows: struct { TransactionID transactionID; uint8 index; uint8 maxIndex; uint16 clearResponse; opaque encryptedPayloadSegment<0..65535> opaque authenticationCode<1..255> } Response; Where: transactionID Is a unquie identifier for the transaction and an input to the function used to derrive the initialization vector (IV) for the encryption algorithm Hallam-Baker November 10, 2014 [Page 26] Internet-Draft Service Connection Service (SXS) May 2014 index Is the index number of this response packet. maxIndex Is the index number of the last packet. The value of maxIndex MUST be the same for every packet. Receivers MUST reject packets clearResponse Is a response code sent enclair. The value 0 indicates a successful response. Error codes TBS. It might be expedient to merge these with index and maxIndex to shave some bytes. encryptedPayloadSegment Is the encrypted message payload segment. To obtain the encryptedPayload of the response, the receiver: * Waits for all the response packets to arrive * Sorts the response packets by the value of index. * Extracts the value of encryptedPayloadSegment from each response * Concatenate the values of encryptedPayloadSegment to obtain the encryptedPayload value UDP packets MAY be sent out of order and the order in which they were received MAY not match the order in which they were sent. A receiver MUST accept response packets recieved in any order. 8.3. Payload The payload is a sequence of the following types of data: JSONData Payload data in JSON encoding JSONCData Payload data in JSON-C encoding as described in [!I- D.hallambaker-jsonbcd] DNSMessageEntry A DNS Message as specified in [RFC1035] PaddingEntry The Payload MAY contain padding. Hallam-Baker November 10, 2014 [Page 27] Internet-Draft Service Connection Service (SXS) May 2014 LastMAC MAC value from the previous message in the transaction. SecurityContextIDEntry A replacement security context identifier. KeyEntry A secret key for use with the immediately preceeding SecurityContextID. Future use The Payload may contain additional options (To be defined) The payload data is encoded according to the following schema: enum {PaddingEntry (0), SecurityContextIDEntry (2), KeyEntry (3), LastMac (4), JSONData (16), JSONCData (17), DNSMessageEntry (18), (255)} PayloadEntryType; struct { PayloadEntryType entryType; opaque data<0..65535> } Response; The SecurityContextIDEntry and KeyEntry data types are used by the server to issue a new security context and key to the client. Changing the security context identifier prevents linkage of transactions across network configurations. One consequence of putting the LastMAC value inside the Payload data is that this provides an attacker with a sequence of known plaintext and ciphertext. 9. Acknowledgements Rob Stradling, Robin Alden... 10. Security Considerations 10.1. Denial of Service 10.2. Breach of Trust 10.3. Coercion 11. IANA Considerations [TBS list out all the code points that require an IANA registration] Hallam-Baker November 10, 2014 [Page 28] Internet-Draft Service Connection Service (SXS) May 2014 12. Stateless server The protocol is designed to permit but not require the server to store connection binding state in the Session ID of the HTTP Session Continuation authentication mechanism. The Session IDs are opaque as far as the client is concerned. The client receives the Session ID from the service and returns it with each request. The internal structure of the Session ID is therefore outside the scope of this specification but is provided here to assist implementers. In the PIN Authentication example, two SessionIDs are issued by the server: * A temporary ID in response to the initial client OpenRequest. * A connection binding ID when the client PIN confirmation is accepted and the connection binding is created. Both tickets have the same common wrapper structure: IV + Encrypt ( Ticket + Mac ( Ticket, Key) Key) Where: IV The Initialization vector for the encryption scheme Encrypt The Encryption algorithm (AES in CBC Mode) Ticket The ticket data MAC The Message Authentication algorithm (HMAC-SHA2-256) 12.1. Temporary ID The temporary ticket returned in the OpenRequest example above is represented in Base64URL encoding as follows: _IXWEJgzv8fUb301-dNfrx_3BQZlrJx14elyFkBGwN_rEV6SBu27clhVVJw6LTHB sCx950rXH2JjHut1AvS53P_hQDImq3d3xU0UmMCrU-BJc-bwMrmM-B80lJ58dMbq QwFWonJ0GRP2lHbdGh7cUA Hallam-Baker November 10, 2014 [Page 29] Internet-Draft Service Connection Service (SXS) May 2014 The format of the ticket is 16 IV: fc 85 d6 10 98 33 bf c7 d4 6f 7d 35 f9 d3 5f af Encrypted Data: 1f f7 05 06 65 ac 9c 75 e1 e9 72 16 40 46 c0 df eb 11 5e 92 06 ed bb 72 58 55 54 9c 3a 2d 31 c1 b0 2c 7d e7 4a d7 1f 62 63 1e eb 75 02 f4 b9 dc ff e1 40 32 26 ab 77 77 c5 4d 14 98 c0 ab 53 e0 49 73 e6 f0 32 b9 8c f8 1f 34 94 9e 7c 74 c6 ea 43 01 56 a2 72 74 19 13 f6 94 76 dd 1a 1e dc 50 The encrypted data is decrypted under the master key of the server. In this example the server has a single fixed key that does not change over time. There should really be a key index prefixing it to identify the key number. The Master Key is: 55 e1 0a 1a 8e 68 8a bd 5a 15 d8 cb b2 63 38 ef 9d 3d 78 bf 62 62 f9 eb 52 ed af ee a5 55 67 0d The decrypted data contains the algorithm identifiers, shared secret and message authentication code: Version Number: 00 Key Identifier: 01 Authentication Algorithm: 00 Encryption Algorithm: 00 Key Data: a1 73 01 06 9b 2a ff 38 f9 8b ab ff ef 02 69 cd User Name Length: 11 User Name: 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d Client Challenge Length: 10 Client Challenge: b0 a0 3a 6d cd e7 9b 3d ee a6 b4 01 05 4d b3 02 Server Challenge Length: 10 Server Challenge: cd c0 be e5 f4 72 c6 de 23 72 cd 04 07 ee 0a dc Message Authentication Code: ed 6e 9b fc bc 1d 4f 03 49 1c 79 22 4e b4 14 1c ea ee 08 82 96 3b 5b 75 99 ff 14 43 c9 40 2f 8b 12.2. Connection Binding ID The format of the Connection binding ticket is similar to that of the Temporary ticket except that it does not contain the Client or Server challenge nonces. Hallam-Baker November 10, 2014 [Page 30] Internet-Draft Service Connection Service (SXS) May 2014 IV: 62 fa b7 2f 4d a7 a0 a2 53 06 17 af b7 8b 8a ba Encrypted Data: 93 fc a5 34 9d 80 82 4f 8d 16 2c 5d 16 51 55 b1 d6 f1 75 5c 70 b5 a2 99 95 a4 08 d8 aa 19 e3 2e a3 70 65 77 ca 77 fb 8e 7c e7 e6 a4 2e e3 20 9a 66 24 df 34 b1 26 a7 ed 19 d7 33 8c 87 3e df 9f The decrypted data is: Version Number: 00 Key Identifier: 00 Authentication Algorithm: 00 Encryption Algorithm: 00 Key Data: 4e cf 16 2f 79 54 79 47 5b 3f 21 13 96 5f e3 84 User Name Length: 0c User Name: 65 40 65 78 61 6d 70 6c 65 2e 63 40 Message Authentication Code: e9 56 3e 59 45 02 fe ca 93 86 05 4e 45 2b 5d c1 c8 89 62 be 7a d5 0e 72 8a 6b ad 8e 91 20 28 a4 13. References 13.1. Normative References [RFC3709] Santesson, S.,Housley, R.,Freeman, T., "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", RFC 3709, February 2004. [RFC3339] Klyne, G.,Newman, C., "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [I-D.hallambaker-jsonbcd] Hallam-Baker, P, "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Internet-Draft draft-hallambaker-jsonbcd-01, 21 January 2014. [RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. Hallam-Baker November 10, 2014 [Page 31] Internet-Draft Service Connection Service (SXS) May 2014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.hallambaker-httpsession] Hallam-Baker, P, "HTTP Session Management", Internet-Draft draft-hallambaker-httpsession- 02, 21 January 2014. [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Author's Address Phillip Hallam-Baker Comodo Group Inc. philliph@comodo.com Hallam-Baker November 10, 2014 [Page 32]