This section corresponds to transaction [19] of the IHE ITI Technical Framework. Transaction [ITI-19] is used by the Secure Application Actor.

Scope

In the Authenticate Node transaction, the local Secure Application presents its identity to a remote Secure Application and authenticates the identity of the remote application. After this mutual authentication, other secure transactions may take place through this secure pipe between the two nodes.

In addition, the Secure Application authenticates the identity of the user who requests access to the node. This user authentication is a local operation that does not involve communication with a remote node.

Note that when the OAuth authentication is used to authenticate the client, there is typically no need for mutual TLS authentication.

Messages

Note: This diagram does not imply sequencing of Authentication Node and Local User Authentication.

Trigger Events

The Local Secure Application initiates the bi-directional authentication process with the Remote Secure Application when information exchange between the two nodes is requested. The first transaction shall be the Authenticate Node transaction, and all subsequent PHI transactions performed by IHE actors shall be secure transactions. This authentication process is needed when a secure connection is established.

The Secure Application shall always apply the Authenticate Node process to every connection.

Message Semantics

The Authenticate node transaction involves the exchange of certificates representing the identities of the nodes.

The cipher suites specified here set a baseline to ensure that interoperability is possible. This baseline shall not prohibit more secure configurations from being used. The actual cipher suites will be negotiated in order and according to local policies, with the most secure configurations preferred.

Certificate Validation

The local organization will make the choice of what mixture of chain of trust and direct comparison is used to authenticate and also authorize communications. This may be entirely based on chaining trust to selected Certificate Authorities (CAs), entirely based upon provision of node certificates for direct comparison, or a mixture of both.

Note: The CAs used for CA:Sec chain of trust will be different than the default browser trusted list of CAs used for authenticating internet web servers. A worldwide CA, such as VeriSign, is not generally trusted to determine which individual nodes within an organization should and should not communicate patient identifiable information.

When Authenticating the Remote Secure Application, the Local Secure Application:

  • Shall be able to perform certificate validation based on signature by a trusted CA (see section Chain to a trusted certificate authority) and
  • Shall be able to perform direct certificate validation to a set of trusted certificates (see section Direct certificate validation)

It may reject communications when the certificate validation fails or may restrict communications to only that which is appropriate for an unidentified other party.

Chain to a trusted certificate authority

The Secure Application:

  • Shall provide the means for configuring which CAs are trusted to authenticate node certificates for use in a chain of trust. These CAs shall be identified by means of the public signing certificate for the signing CA.
  • Shall support digital certificates encoded using both Deterministic Encoding Rules (DER) and Basic Encoding Rules (BER).
  • Shall accept communications for which there is a certificate that is signed by a CA that is listed as a trusted signing authority.

Additional security considerations for API transactions:

  • There may be other methods with respect to authorization, e.g., API key or certificate issued by the app.
Direct certificate validation

The Secure Application:

  • Shall provide means for installing of the required certificates, for example, via removable media or network interchange (where the set of trusted certificates can be a mixture of CA signed certificates and self-signed certificates).
  • Shall support digital certificates encoded using both DER and BER.
  • Shall accept communications for which there is a certificate configured as acceptable for direct certificate validation.
Other Certificate requirements

The Secure Application shall not require any specific certificate attribute contents, nor shall it reject certificates that contain unknown attributes or other parameters. Note that for node certificates the Common Name (CN) often is a hostname, attempting to use this hostname provides no additional security and will introduce a new failure mode (e.g., DNS failure).

The certificates used for mutual authentication shall be X.509 certificates based on either:

  • RSA key with key length in the range of 2048-4096 bit, where the key length chosen is based on local site policy and as per minimum accepted by today’s standards (NIST SP 800-57, FIPS140-3), or
  • BCP195 certificate recommendations.

Maximum expiration time acceptable for certificates should be defined in the applicable security policy. The IHE Technical Framework recommends a maximum expiration time of 2 years.

The method used to determine whether a node is authorized to perform transactions is not specified. This may be use of a set of trusted certificates, based on some attribute value contained in the certificates, access control lists, or some other method. Using a certificate chain back to an external trusted certificate authority to determine authorizations is strongly discouraged.

FQDN Validation of Server Certificate Option

The FQDN Validation of Server Certificate Option applies the rules presented in RFC6125 when a client authenticates the server using an X.509 certificate in the context of Transport Layer Security (TLS).

A client, who is validating a server’s identity, shall validate that the reference identifier present in a subjectAltName entry of type DNS-ID matches the source domain of the server, per RFC6125 Section 6. Note that the rules described in RFC6125 Section 6 require the validation to be performed based on the input source and the DNS-ID fully qualified domain name.

In an environment where clients have implemented this option, a server’s X.509 certificate shall contain a subjectAltName entry of type DNS-ID, per RFC6125 Section 4.

All Connections carrying Protected Information (PI) using TLS

TLS Floor Option

An actor using the TLS floor Option:

  • Shall be able to comply with BCP195. This implies that the implementation:
    • Utilizes the framework and negotiation mechanism specified by the Transport Layer Security protocol.
    • Supports current version of TLS or higher
  • Shall also be able to restrict to use current version of TLS or higher.
  • Shall also support the following cipher suites if using TLS 1.2:
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • Shall also support the following cipher suites if using TLS 1.3:
    • TLS_AES_256_GCM_SHA384
    • TLS_AES_128_GCM_SHA256
  • Shall reject negotiation of any cipher suites that have been identified as providing weak security, or less than 128-bit encryption

Additional cipher suites of similar or greater cryptographic strength may be supported.

Referenced Standards

IETF: 

  • [RFC6125] - Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
  • [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, MAY 2015. Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, March 2021. <https://www.rfc-editor.org/info/bcp195>
  • ATNA - Audit Trail and Node Authentication https://wiki.ihe.net/index.php/Audit_Trail_and_Node_Authentication

ITU-T:

  • Recommendation X.509 (03/00). “Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks"

Audit Considerations

To add support for audit, CA:Sec actors can be grouped with CA:Aud actors (see section Cross Profile Considerations). Alternatively, other non-IHE methods can be used to record audit messages, that do not require grouping with CA:Aud actors.

To enable audit, a Secure Application shall detect and report the events defined in table below. Additional events may be reported.

Audit Event Trigger

Description

Actor-start-stop

Startup and shutdown of any actor. Applies to all actors. Is distinct from hardware powerup and shutdown.

Mobile-machine-event

Mobile machine joins or leaves secure domain.

Node-Authentication-failure

A secure application authentication failure has occurred during TLS negotiation, e.g., invalid certificate.

Security Alert

Security Administrative actions create, modify, delete, query, and display the following:

Configuration and other changes, e.g., software updates that affect any software that processes protected information. Hardware changes may also be reported in this event.

1.       Security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods (e.g., WSDL, UDDI), program creation and maintenance, etc.

2.       Security domains according to various organizational categories such as entity-wide, institutional, departmental, etc.

3.       Security categories or groupings for functions and data such as patient management, nursing, clinical, etc.

4.       The allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods.

5.       Security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control.

6.       User accounts. This includes assigning or changing password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control.

7.       Unauthorized user attempt to use security administration functions.

8.       Audit enabling and disabling.

9.       User authentication revocation.

10.   Emergency Mode Access (aka Break-Glass)

Security administration events should always be audited.

User Authentication

This message describes the event of a user log on or log off, whether successful or not. No Participant Objects are needed for this message.

  • No labels