VIEWS: 1 PAGES: 43 POSTED ON: 12/3/2011
SECURITY CONSENSUS REQUIREMENTS - APPLICABLE TO ALL IMPLEMENTATIONS Security Requirement Use of X.509 Certificates Certificate Anchor Configuration Certificate Granularity Revocation Sender Identification Encryption Ease of Use Integrity US REQUIREMENTS - APPLICABLE TO ALL IMPLEMENTATIONS Requirement Text The NHIN Direct protocol relies on agreement that possession of the private key of an x.509 certificate with a particular subject assures compliance of the bearer with a set of arbitrary policies as defined by the issuing authority of the certificate. For example, Verisign assures that bearers of their "extended validation" certificates have been validated according to their official "Certification Practice Statement." Certificates can be used in many ways, but NHIN Direct relies on the embedded subject and issuing chain as indicated in the following points. Specific implementations may choose to go beyond these basic requirements. Implementations must allow configuration of one or more public certificates representing "anchors" that implement agreed-to message handing policies. Implementations should allow anchors for sending messages to be distinct from those for receiving messages. Implementations should allow these configurations to be unique per-address in addition to per- health-domain. This will ease integration for participants with an existing PKI infrastructure, and provides a path to more fine-grained assurance for future use cases. Implementations must be able to accept messages identified per-address or per-health-domain per [Sender Identification requirement below]. When possible, implementations must frequently check the validity of configured or cached certificates through standard means. The definition of "frequently" should be defined by external policy. NHIN Direct messages must be reliably linked to the public certificates possessed by the sender, through standard digital signatures or other means that match the certificate subject to the sender's address or health domain. Implementations must reject messages that are not linked to valid, non-expired, non-revoked public certificates inheriting up to a configured Anchor certificate per [Certificate Anchor Configuration requirement above]. NHIN Direct messages sent over unsecured channels must be protected by standard encryption techniques using key material from the recipient's valid, non-expired, non-revoked public certificate inheriting up to a configured Anchor certificate per [Certificate Anchor Configuration requirement above]. Normally this will mean symmetric encryption with key exchange encrypted with PKI. Implementations must also be able to ensure that source and destination endpoint addresses used for routing purposes are not disclosed in transit. Implementations should attempt to ease the complexity of certificate management for end users and organizations. While this is not a hard protocol requirement, it is important to be aware that many systems leveraging certificate technology have failed to achieve adoption due to complexity of PKI management, so efforts here will be a key driver of success or failure for NHIN Direct. If possible implementations should enable NHIN Direct users to think in terms of "who do I trust" rather than "what certificates to I import". Implementations should also ensure that users can leverage existing credential management programs; for example, ICAM in the federal space (see related links). NHIN Direct messages must be protected using standard hashing techniques acceptable in current regulation. Implied Policy A digital certificate may be used to authenticate the identity of an entity involved in an NHIN Direct exchange. Certificate Authorities ("anchors") for certificates used in NHIN Direct exchanges must agree to, and implement, a set of established message-handling policies. Authentication of end points must include validation of end-point certificates with their respective Certificate Authorities. NHIN Direct senders and receivers are not required to use the same Certificate Authority. A sender or receiver may be either an individual or an organizational entity. NHIN Direct senders and receivers must periodically check the validity of digital certificates, but are not required to always check. Messages exchanged using NHIN Direct must be reliably attributable to their sender. Digital signatures may be used to reliably attribute messages to senders; however, other less relable means, such as sender's email address or domain, are also acceptable. Messages sent over exposed communication channels must be encrypted. Most commonly, symmetric encryption using a secret key exchanged using public-key certificates will be used, though policy allows other encryption schemes. Source and destination endpoint addresses used for internal routing must be protected in transit. Certificate management should be as simple as possible for end users and their organizations. Implementations should be driven by end users' need for trust, with complex detail abstracted from the user experience. Where possible, implementations should enable the use of existing credential management programs. The integrity of message content should be protected using a secure hashing function. Comments & Questions Certificates can be assigned to organizations (health domains) and to people (health endpoints). The implementations vary w.r.t. the entities to which certificates are issued. Who establishes these "message handling policies?" Note that frequency is left open. Depending upon the nature of the communication, email address or domain may not be sufficiently reliable. "Unsecured channels" needs to be defined, including both wired and wireless. The Standards & Certification Criteria IFR requires the use of of AES for symmetric encryption. I believe I have interpreted the final statement correctly, though it's somewhat ambiguous. Existing credential management programs should be required to meet the same minimal "message handling policies" referenced in the Certificate Anchor Configuration requirement above. The Standards & Certification Criteria IFR requires the use of of a SHA1 hash function for integrity protection. IHE Implementation: Allows flexibility (e.g., REST, SMTP, XMPP) for sending information from source system to H secure channel using a SOAP IHE XDR message to the destination HISP, again allowing flexibility in transport from Technical Implementation Source HISP generates and adds XDS-compliant metadata to document before forwarding on to destination HISP. X.509 certificates used to authenticate the source system (for source-to-HISP connection) and to mutually authenticate source and destination HISPs. Support for self-signed certificates that are pre-coordinated and configured into a trust-store Typical configuration is to use certificates to secure the service- endpoints of the communications IHE does not mandate a revocation checking protocol as the use of CRL and PKCS are both mature and widely available. When intermediaries are required for step-up or step-down, the intermediaries are included in the trust fabric once they have been appropriately onboarded through validation of business process, technology, and procedures. TLS channels are encrypted using an encryption algorithm negotiated between end points; IHE profiles require at least AES (Advanced Encryption Standard). TLS channels are integrity protected using a hashing algorithm negotiated between end points; IHE profiles require at least SHA1. SMTP, XMPP) for sending information from source system to Health Information Service Provider (HISP), where XDR metada he destination HISP, again allowing flexibility in transport from the HISP to the destination system. Stated Policy This solution supports but does not require that the source or destination pre-coordinate the certificates as long as the resulting certificates can be chain-validated to an Anchor. All Certificates must be validated when they are used to assure their signature validates, that their time boundaries are valid, and that they have not been revoked. IHE profiles require that production systems are at least able to utilize AES. IHE profiles require that production systems are at least able to utilize SHA1. Health Information Service Provider (HISP), where XDR metadata are generated. The document and metadata are then sent the HISP to the destination system. Implied Policy The HISP may provide value-added services that require disclosure of PHI and generation of metadata. A source system must authenticate itself to a HISP before using it to exchange health information. A destination system must authenticate itself to a HISP before receiving information from the HISP. Source and destination HISPs must be mutually authenticated before exchanging health information between them. Certificates are not required to be signed by an independent certificate authority. Certificates may be used to authenticate end points (source and destination systems), as well as HISPs involved in the exchange. Either CRL (Certificate Revocation List) or PKCS (Public Key Cryptography Standard #10 - Certification Request Syntax) may be used to validate certificates. Transport from source system to XDR backbone, and from backbone to destination system may involve intermediaries. Trustworthiness of intermediaries must be validated. Data exchanged must be encrypted using at least AES encryption algorithm. Hashing algorithm must be at least a SHA1 hashing function. ta are generated. The document and metadata are then sent over a Comments & Questions Note: The only transport from the source system to the Source HISP, and from the Destination HISP to the destination system is the XDR Provide and Register Document Set-b transaction. Others are shown as options that could be implemented. XDR was designed as a reliable, point-to-point messaging system for exchanging documents relating to a specific patient, in the absence of an XDS document-sharing infrastructure. XDR reuses the metadata and messages defined by the XDS (Cross-Enterprise Document Sharing) Integration Profile. This model subjects PHI to unnecessary exposure. There's no compelling business reason why the data being exchanged over the NHIN needs to be manipulated by the HISP in order to be transported from point A to point B. Who defines the validation criteria? REST Implementation: End-to-end Transport Layer Security (TLS) protection between source and destination, pl Service Providers (HISPs). Technical Implementation Message integrity and non-repudiation are achieved through a message-based S/MIME signature using the private key of the Source (often times executed by the Source HISP). Verification of the signature at the Destination HISP (or possibly the Destination) requires the X.509 public certificate corresponding to the private key used to generate the signature. Message privacy is achieved through asymmetric encryption using the public X.509 certificate (public key) of the Destination. Decryption of the message is only possible using the private key of the Destination HISP thus guaranteeing privacy in transit and at rest. S/MIME expresses the X.509-based privacy and integrity features described above in standard multipart MIME types and headers. All X.509 public certificates are obtained through the Certificates REST resource. Certificates may be issued at the organization or individual level. The HISP-to-HISP transactions use TLS primarily to mitigate against on-the-wire snooping of metadata (such as To and From addresses) that could be considered Protected Health Information (PHI). TLS used to protect transmissions between source/destination end users and source/destination HISPs. sport Layer Security (TLS) protection between source and destination, plus S/MIME message integrity, confidentiality, and n Stated Policy Certificates may be issued at the organization or individual level. tion, plus S/MIME message integrity, confidentiality, and non-repudiation (digital signature) protection between Health Info Implied Policy The integrity of message content must be protected between HISPs. Messages sent between HISPs must be digitally signed by the source HISP. The digital signature of the source HISP must be verified by the destination HISP. X.509 certificates may be used to authenticate source and destination servers. Message content must be public-key encrypted, using the public key of the destination server. Messages passed between HISPs must remain encrypted in transit and at rest, until they are explicitly decrypted by the destination HISP server. Communications between HISPs must be authenticated, integrity protected, and encrypted. Sensitive data used to describe (e.g., metadata) and route (e.g., end-user email addresses) the information being exchanged must be protected. Communications between source/destination end users and source/destination HISPs must be encrypted. -repudiation (digital signature) protection between Health Information Comments & Questions Note that this model provides S/MIME integrity, confidentiality, and non-repudiation (digital signature) only between two HISPs involved in the exchange. These services are not provided between the user and the HISP unless the local client chooses to provide them. However, all transmissions from the user (client) to the final destination are protected using TLS, which provides end-point authentication, integrity, and confidentiality protection. A policy requiring that content be encrypted only using asymmetric (public-key) encryption may not be reasonable or practical. Symmetric encryption (with the secret key exchanged using a public-key protocol) should be an option, particularly for high- bandwidth content (e.g., images). Note that this is a key difference between a TLS approach and an S/MIME approach. TLS transmissions are encrypted as they are sent and decrypted upon arrival at the end point; if that end point is in front of a firewall, there is an opportunity for exposure. S/MIME messages remain encrypted while "at rest" in send and receive queues and are decrypted only when opened at the destination. However, S/MIME is used only between the source HISP and destination HISP. The only security provided between tthe source/destination end users and the source/destination HISPs is TLS -- unless provided by local client or server. Unclear whether TLS between end users and HISPs is mutually authenticated or singly authenticated (end user or HISP). Also, does not provide any details re integrity protection or encryption on these links. SMTP Implementation: Provides users with traditional email accounts to NHIN Direct that can be used with the transparently adds S/MIME digital signatures and encryption using certificates bound to the source and destinat Full Service: All functionality is wrapped into a service provided by an organization. Email clients connect to their servers ove existing email protocols. Mail Client Plug-In with ISP: Single user (e.g., provider) installs NHIN Direct plug-in into their email client and uses with existi 3rd-party email and DNS services. Technical Implementation Adds S/MIME signatures and encryption using certificates bound to the source and destination endpoints. NHIN Direct Agent supports the use of x.509 certificates. This implementation supports certificate granularity required; whether organization or individual certificates or both are used is a matter of configuration. Uses online re-fetch of certificates to manage revocation. Attempts an individual subject match, then an organization match before rejecting a message. Encrypts all messages using a public key of the recipient. Management of certificates can be handled by a HISP on behalf of an organization, or directly by the organization itself, resulting in 3 levels of ease-of-use: 1) At the highest "ease-of-use" level, certificate management can be delegated to the HISP. 2) An organization can obtain one certificate per trusted CA. 3) An organization can take complete control of certificate management. with traditional email accounts to NHIN Direct that can be used with their normal (client or web-based) email applications o ures and encryption using certificates bound to the source and destination endpoints. Certificates can be handled by a HIS a service provided by an organization. Email clients connect to their servers over provider) installs NHIN Direct plug-in into their email client and uses with existing Stated Policy ith their normal (client or web-based) email applications or with email integrated with EHR products. Adds a security “plug estination endpoints. Certificates can be handled by a HISP on behalf of an organization, or directly by the organization its Existing ISP and Gateway: Organization uses existing ISP-based email and DNS services, and inserts a gateway in their organiz handle NHIN Direct agent duties. Implied Policy The integrity of email messages must be protected between sender and receiver. Email messages must be digitally signed by the sender. X.509 certificates can be used to authenticate end points in NHIN Direct exchanges. Certificates used to authenticate senders and receivers can be associated with organizations or individuals. Message content must be public-key encrypted, using the public key of the destination server. Certificate management is left up to the individual organization. with email integrated with EHR products. Adds a security “plug in” that on behalf of an organization, or directly by the organization itself. -based email and DNS services, and inserts a gateway in their organization to Comments & Questions Note: In this model, policy enforcement is left up to the discretion of the user, who must decide when to use their NHIN Account and what email needs to be sent through the "NHIN agent." Also, email clients typically allow one to turn off encryption and digital signature. A policy requiring that content be encrypted only using asymmetric (public-key) encryption may not be reasonable or practical. Symmetric encryption (with the secret key exchanged using a public-key protocol) should be an option, particularly for high- bandwidth content (e.g., images, video). XMPP (Extensible Messaging and Presence Protocol) Implementation: Communication between clients and serv networking applications, such as Facebook, Google Wave, and instant messaging. Implementation includes a Ja applications can be implemented using other software-development languages, and can be created such that the Technical Implementation Communication between client and server encrypted using TLS. Clients authenticate themselves to the HISP using SASL (Simple Authentication and Security Layer) mechanism. Server to Server communication encrypted using TLS. Server to Server authentication will be performed using SASL External mechanism. XMPP implementation is testing signing and encrypting payloads using PKI infrastructure -- not yet part of implementation. Server white-listing capability (The capability provides an easy mechanism for HISP's to determine the other HISP's that they would like to communicate with). This feature may or may not be used in the real world but allows organizations to block organizations or spams. Endpoint/User level blocking: All end points or users have the capability to maintain rosters (buddy lists) of other endpoints/users that they wish to communicate with. A basic agreement to communicate is established initially upon mutual consent for communication. ce Protocol) Implementation: Communication between clients and servers, and between HISPs, are performed using the XM ok, Google Wave, and instant messaging. Implementation includes a Java "XMPP client" application and a Java "XMPP serv ther software-development languages, and can be created such that they only use a web browser. Stated Policy nd servers, and between HISPs, are performed using the XMPP protocol and its extensions; i.e., protocol commonly used by es a Java "XMPP client" application and a Java "XMPP server" application, both constructed using open-source software. C hat they only use a web browser. Implied Policy The transport channel between a source or destination client and an HISP must be encrypted. Clients must authenticate themselves to the HISP using a challenge- reponse authentication scheme. Communications between HISPs must be protected using an authenticated and encrypted channel between HISPs. Authentication between HISPs does not require X.509 certificates, but can be context-based challenge-response. P protocol and its extensions; i.e., protocol commonly used by social " application, both constructed using open-source software. Client Comments & Questions NOTE: This implementation does not meet the consensus requirements. SASL is an IETF proposed standard, originally developed by Carnegie-Mellon. SASL decouples authentication from other services to enable secure connections (e.g., TLS connections) to be established using a broad range of challenge-response authentication mechanisms ranging from "External" (implicit based on context) to Microsoft GateKeeper. Unclear whether mutual authentication is required. This mechanism does not meet the consensus requirement for X.509-based authentication. Implementation Compliance with Consensus Requirements Note: These two columns assume that the consensus requirements represent valid policy underpinnings. As Arien Malec has noted, the NHIN Direct project got "technology and policy a bit backwards." The HITPC Tiger teamwill be providing policy guidance and direction to the NHIN Direct project. IHE Compliant REST Compliant SMTP Compliant XMPP Non-compliant Recommendations 1. We recommend further development and piloting of the REST implementation, with SMTP email provided by the HISP as a 2. We recommend that no implementation move forward to a pilot until the policy framework, and associated security requ Security at the consensus requirements represent valid policy oted, the NHIN Direct project got "technology and policy a bit ill be providing policy guidance and direction to the NHIN Direct SOAP WS-Security from HISP to HISP; and between HISP and source/destination if the XDR is used for the on-ramp. Information sent to HISP is used to generate XDS- compliant metadata. End-to-end TLS for trusted communication path; S/MIME for document authentication, confidentiality, and digital signature between source and destination HISPs. End-to-end email security, enforced by individual user. Uses an arbitrary set of authentication schemes, none of which use X.509 certificates. he REST implementation, with SMTP email provided by the HISP as an option. d to a pilot until the policy framework, and associated security requirements, being developed by the Privacy and Security Tiger Team are Simplicity May be overly complex as "simple" interoperability. Simple May be too "simple." Not well enough defined to be complex or simple. he HISP as an option. curity requirements, being developed by the Privacy and Security Tiger Team are in place. Other XDR designed for point-to-point exchange of patient- specific XDS documents; not well suited for exchanges of MU quality reports. Minimizing disclosure of PHI should be a fundamental policy. Also, unnecessarily exposes and manipulates PHI, presenting both confidentiality and integrity risks. Establishment of TLS link between source/destination end users and source/destination HISPs is not well defined. Accommodates asymmetric encryption only; symmetric encryption may be needed for high-bandwidth exchanges. I believe this implementation leaves too much to the discretion of the individual user. Difficult to integrate with NHIN Exchange. Eliminate from further consideration. ecurity Tiger Team are in place.
"HITSCReviewSpreadsheet_V1_.xlsx - Direct Project"