20150911 - Meeting minutes, Friday, September 11th, 2015 - OpenNCP integration with SMP

Owned by Rui Alves (Unlicensed)
Last updated: Mar 08, 2016 by Kostas KarkaletsisVersion comment
8 min read

OpenNCP integration with SMP

 

Estimated - 14:00 to 15:00 CEST

Performed - 14:00 to 16:00 CEST (appologies for the delay)

AGENDA

0. Overview

1. Document on SMP and Open Questions

2. AOB

 

 

LOCATION

- Wiki+ WorkBench + AdobeConnect

PARTICIPANTS

Today's Meeting Participants:

Joao Cunha

Rui Alves (Unlicensed)

@Uwe Roth

Massimiliano Masi

S

Adrien Ferial (DG DIGIT),

João (DG Digit),

Stéphane Spahni

[Appologizes] Heiko Zimmermann

 

Invited Members List:

Licinio Kustra Mano

Markus (Unlicensed)

michele.foucart

@Gwenaelle Quivy

Marcello Melgara

@François

Natasha Carl

Alexandre Santos

Kostas Karkaletsis

Ortwin Donak

 

MEETING NOTES

0. Overview

  • Work Scope

    • USE SMP to convey public information of TSL (Certificates, End Points) and International Patient Search Mask;
      • TSL files should be removed and replaced by SMP Signed Information files. 
      • (Maybe not to delete the TSL EDITOR, explore TSL EDITOR to prepare the information to submit to the SMP )
        • INTEGRATE a REST client to CRUD the information...
      • About "International Patient Search Mask", how to include on the  SMP configs
        • Can be a child on an XML node on the SMP file.
    • USE SMP to the establishment of VPN?
      • Certificates, End Points and OpenSwan Config (PRIVATE)
    • OUT OF SCOPE BY NOW - Automate the configuration of OpenNCP

  • Time Scope: 

    • New release OpenNCP 2.3.0-RC0 Released in August.


  • Relevant Documentation: 

    • SMP:

Draft version shared for comments: e-SENS-eHealth-SMP_SML-v02-Draft_ForComments.doc

Questions from Last Meeting (Q1 to Q5): https://openncp.atlassian.net/wiki/x/ZACqAw 

    • Following the exchange of e-mails and questions compiled by Joao Cunha

      6) In the document where you propose a mapping for the SMP file there's this comment under the ServiceMetadataCollectionReference tag: "For the 1,2 transaction: should we group them, or we allow to have different endpoints for the same service?". I couldn't understand what you were talking about. For example, the epSOS consent service has two operations: Put and Discard. For that I created two pointers to ServiceMetadata, epSOS-51 and epSOS-52. Should we use just one instead? The question is: do we think that we may have different SMP configuration for the Put and Discard?

      Answer: We should keep them separated, it prevents future problems in case a MS wants to provide different endpoints for those two operations.

       

      7) In the EXPAND CP document, there's an example of how to use SMP to store information about the International Search Masks (1.1.6). That example makes use of the <Extension> element in order to share the XML file of the search mask. The SMP spec states that "SMP publishing services MUST NOT produce metadata that contain extensions necessary for a Client to understand in order to make use of this metadata." (2.3.2) If we analyze this as "the international search masks' metadata (inside its own <Process> element) must not contain extensions necessary for a client to understand in order to make use of it" then it's ok: a client doesn't need to know the XML extension of the search mask in order to make use of its metadata (identifiers, begin/end date, description). But if we analyze this in a broader scope and read it as "none of the metadata in a SMP can have extensions necessary for a Client to understand in order to make use of this metadata.", and reading this statement from SMP specification "The ability to parse and adjust client behavior based on an extension element MUST NOT be a prerequisite for a client to locate a service, or to make a successful request at the referenced service", then I believe there's a dependency between making a XCPD request to a country and its search mask: you can only perform the XCPD request if you know the search masks beforehand to provide the input fields. What do you think of this?

      Answer: Correct, and I consider it a mistake of the SMP. The MUST NOT should become a MAY NOT, and then let the specification to profile the standard as needed (as all the other WS-* does). This is clear: the MUST NOT seems to be there to avoid the usage of SMP in other context. I asked Sven Rostgaard (the SMP editor) by Skype today, I will initiate a channel with him and the BDX TC.

      ABBs in eSENS says that Extension semantics must be agreed by participants.

      SMP extensions should not be abused.

      It only has impact on search masks.

      DIGIT supports extensions. 

      • João (DIGIT): eHealth DSI intends to re-use SMP - DG-DIGIT internal assessements. Possibly have Conf Calls. e-SENS important for this.

      8) Regarding SMP Redirects, the specification states the following about their CertificateUID element (2.3.4.4): "Holds the Subject Unique Identifier of the certificate of the destination SMP. A client SHOULD validate that the Subject Unique Identifier of the certificate used to sign the resource at the destination SMP matches the Subject Unique Identifier published in the redirecting SMP."

      If we look at epSOS D3.4.2 - 5.4.1 - Certificate Profiles - General Stipulations for epSOS compliant certificates, we see that: "The field "SubjectUniqueID" MUST NOT be used.". Do you agree that we have a conflict between the specifications here? If so, how are we going to deal with it? Can the two specifications coexist?

      Answer: The situation here is clear: we do use another trust model, so the optional value check of the certificate should be discarded.

       

      9) In the "e-SENS: ABB and Configuration Services (into CS)" page from OpenNCP (https://openncp.atlassian.net/wiki/pages/viewpage.action?pageId=49447055), when asked about "Is service locator aware of the status of the service (up-down)?", you answered "Yes". Do you mean that the SML/DNS server is aware of the status of the SMP server?

      Answer: I think there is a misunderstanding: I said yes to the question “Is service Locator aware of the status of the service” by saying the ServiceStatus entry of the TSL.

       

      10) Will the central services (SMP server) support VPN connection?

      Answer: DIGIT: can't tell. Marked as a requirement.

       

       11) Is there any need for private information? Regarding the need to have the VPN config as private data in SMP server (Stéphane: "not mandatory but recommended"), Marcello stated: Central Services must have the same level of technical and organisational security of the NCP. They must pass the initial audit." Some countries place private IP addresses for the VPN in the TSL-file (ex: LU)

      Answer: VPN info is sensitive. Security by hiding info is not security. Limiting access is good but not a prerequisite. As long as adequate security measures are put in place in the OpenNCPs, we can have VPN info in the SMP.

      • Public vs Private Information in the Keystore...
        • Stéphane Spahni: VPN Connection is a "sensitive" subject...
        • Check with Marcello - Issues to be adressed
          •  

       

      12) Should the DNS server be a secure node? And SMP?

      Answer: Massi (about the DNS server): "Maybe not, since it does not contain PHI, and the configuration changes will be audited by the NCP."

      Massi (about the SMP server): "not in my opinion: An ATNA SN is defined by IHE, thus IHE puts under its umbrella everything which involves PHI. The configuration change is an event with security relevance, and it is thus audited by the OpenNCP, not by the SMP: why the SMP should audit “the german NCP asked for the ISM of the Portuguese NCP”. But it is important that the German NCP audits something like “I changed the ISM for portugal”.  Why, it is not important. Check also this post: http://healthcaresecprivacy.blogspot.it/2015/08/dont-disassemble-atna-what-you-are.html from John, the guy behind ATNA."

      The NCP, as the PHI holder, should be an ATNA secure node, but the SMP not.

      We should ask Marcello for clarification (by email) (Stéphane: "Marcello stated that the CS must be in the same circle of trust of the NCPs")

      12.1) Will we have an audit trail in SMP server?

      Answer: No: the SMP server does not contain PHI, thus the audit “Security Event / Security Alert” should only be sent by the NCP according with ATNA.

       

      13) DNS Security (Uwe)  - Chapter 5 from the document e-SENS-eHealth-SMP_SML-v02-Draft_ForComments.docx

      Answer:

      - DNSSEC should be implemented

            - Client code can obtain certificate of DNSSEC with a DNS lookup

            - DIGIT: it's still unknown if the NCP has to be changed to communicate with DNSSEC

            - Query made with DIGIT's client (it has to be DNSSEC-aware)

 

 

14) OpenNCP as ATNA Secure node

14.1 (Heiko): There is also nowadays a point related to the creation of the ATNA logfiles format. Since the specification from IHE has been modified and now requests the implementation of the logfiles in compliance to the DICOM format, which OpenNCP is currently not capable of.

Answer: epSOS log files were based on RFC 3881, which is deprecated ("The use of RFC3881 has been deprecated by IHE and IETF." - IHE IT Infrastructure Technical Framework Supplement - Add RESTful Query to ATNA, section 3.20.4.1.3.2). Audit log is now based on DICOM audit schema. That affects the whole epSOS specification. We depend on EXPAND's work to update the specifications (syntactical change, not semantic). More info can be checked in the minutes from a Non-repudiation meeting.

14.2  TSL Sync has quartz job (WAR. JAR doesn't - should it be run with cron?). Does it work like the syncapp then? Does it do all the needed tasks like rebooting for creating the start & stop audit log (mandatory - Massi)? Does it make OpenNCP a secure node? What about sharing the search masks?

Answer: We should address this issue in an OpenNCP specific meeting.

 

15) Mapping TSL-SMP (Massi's doc EXPAND CP)

- EndpointURI

               Section 1.1.4: VPN endpoint must be an URI (xs:anyURI) but all we have is an IP address or domain name. Possible solution: use a non-standard scheme (e.g. "ipsec:")

Masi agrees with Uwe’s and João’s suggestion to go with the non-standard. 

 

- Certificates

                Signature certificate is used separately in NCP-B STS (IdP) endpoint configuration.

                In each endpoint we use the TLS certificate.

                This doesn't restrict the provision of epSOS compliant certificates by the MS.

- TSL envelope

                If such records are considered, they SHOULD be part of the ServiceGroup (as Extensions).      

- ServiceStatus

                - Should it be removed? It addresses epSOS pilot phase 1. If is not in accordance, then the activation date is less than now, or the SMP record should not be there. This decision should be taken in a broader scope:

                               - Put in comments and let EXPAND discuss.      

- Fields mandated by SMP:

                - RequireBusinessLevelSignature (not needed for us)

                - MinimumAuthenticationLevel (useful in eID level 2?)

- Advanced signature -- EXPAND to discuss

 

- Section 1.1.4 - VPN Endpoint/@transportProfile

                - Should we use for the type of VPN?

 

16) Relaxations that still exist:

Answer:

i) SHA1 vs SHA2 certificate relaxation;

ii) CA problem (not Trusted Third Party, but ministry or national level CA) and the certificate profiles

 

17) Is eID dependent (completely or partially) on SMP/SML?

Answer: Completely dependent I would say no, but using SMP will help a lot the deployments and its usability. LAM needs additional info (in comparison with LARMS)

                      - Patient consent (TRCA signed by patient)

                      - Where is TRC-STS?

                      - Which auth plan (is this patient allowed to sign the TRCA, or the stork IT (which one? STORK, eIDAS, etc?))

                      - Which certificates to use to validate TLS connection?

      - In order to avoid configuration entries in the hospital or PoC

      - Use SMP to bring info from the country of treatment

      - LAM contacts SMP. NPC-B is not touched

      - Portal init() triggers transaction and tells LAM who is the caller

      - LAM builds SML query

 

18) Building domain name of country (Uwe)

Answer:

SML domain (comes from DIGIT)

       - A NAPTR entry for each service

       - SAML NameID of the remote's issuer

                       - HCID or STS -- unique fields of each NCP

 

 

2. AOB

  • Joao Cunha and @Uwe will try to complete the document with the new inputs.
    • Try to have it ready by 25th Sept(?)
    • Massimiliano Masi: Take care of EXPAND document (CP) - must be ready for 25th Sept
    • After doc ready - create test assertions for Gazelle... for EXPAND and e-SENS - after the 25th 
    • Rui Alves (Unlicensed) will share the CP to EC ASAP
    • Massimiliano Masi create JIRA issue - expect comments from Main Shop - should not affect the EXPANDATHON.

  • Rui Alves (Unlicensed) will gather the questions asked today and share them here in the minutes with comments/answers.

 


Today's meeting actions and next meeting: