Open APIs

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Personal Opinion.
There isn't a clear documented team position and most of the lab prop types have used clear communications
In the ODA Component Security discussion, we have a clear requirement for Zero Trust implementation that all inter component communions including use of Open APIs are encrypted.

SSH would seem to be a quite sensible and commonly used approach. the ODA Security and Privacy team is discussing this exact topic but from a Zero Trust implementation perspective.

------------------------------
Dave Milham
TM Forum, Chief Architect
------------------------------

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway
------------------------------

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Thanks all

Yes. This is actually the case. It's additional encryption above the transport encryption

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Original Message:
Sent: Oct 06, 2022 02:46
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Thanks for the clarification - I had missed this detail.

We are currently looking at ODA security and have identified a number of requirements sources which are currently documented at: 
20220802 Security and Privacy Requirements Workshop discussion points/ Materials - End to end ODA - TM Forum Confluence  
However, we haven't converted these into team approved specifications as yet.




------------------------------
Dave Milham
TM Forum, Chief Architect
------------------------------

Original Message:
Sent: Oct 06, 2022 03:04
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Thanks all

Yes. This is actually the case. It's additional encryption above the transport encryption

------------------------------
George Munyi
Safaricom Ltd

Original Message:
Sent: Oct 06, 2022 02:46
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Hey Jonathan,

We have had similar questions about at-rest encryption, specifically that property formats such as DateTime cause issues if the data within that property is encrypted.  This means that we may need to extend these entities to give an encrypted field to avoid the problems with deserializing a value that violates the property format or figure out some other way of managing at-rest encryption of data when using systems that do not support it, such as Kafka.  Are there any suggestions for handling situations like this or is extending the entities the best choice, at least for now?

Thanks,

Sean

------------------------------
Sean Garagan
Bell Canada
------------------------------

Original Message:
Sent: Oct 06, 2022 02:46
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Life is tough, Sean. You are absolutely correct that specific formats clash with encryption, this is our experience as well at Amdocs. And this clash impacts API signatures and underlying database schemas. Not to mention the problem of how to search efficiently (index) over encrypted data - e.g. in a Find Caller flow how do I find all the Sean Garagan in my Individual data store.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Original Message:
Sent: Oct 06, 2022 09:29
From: Sean Garagan
Subject: Payload Encryption on TMF Compliant endpoint

Hey Jonathan,

We have had similar questions about at-rest encryption, specifically that property formats such as DateTime cause issues if the data within that property is encrypted.  This means that we may need to extend these entities to give an encrypted field to avoid the problems with deserializing a value that violates the property format or figure out some other way of managing at-rest encryption of data when using systems that do not support it, such as Kafka.  Are there any suggestions for handling situations like this or is extending the entities the best choice, at least for now?

Thanks,

Sean

------------------------------
Sean Garagan
Bell Canada

Original Message:
Sent: Oct 06, 2022 02:46
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------

Seems that the requirement is to have a separate key for the transmission encryption from the payload encryption. 
Something like this was supported in ebXML using SOAP with attachments where different keys could be used for hearer (routing and metadata) from the payload
Seems like the payload needs an end to end encryption between parties.

Is this correct understanding of the requirements?
IN the current security requirements at 20220802 Security and Privacy Requirements Workshop discussion points/ Materials - End to end ODA - TM Forum Confluence we only have the transmission encryption. 

Regulatory

All transmissions links must be encrypted

There are a number of government security recommendations for security that have now transitioned to all transmission links must be encrypted. As encryption has become more easily achieved and is typically now not limited by the processing power of the equipment the expectation is that telecommunication providers that are classified as critical infrastructure increase their resiliency and availability through security within the perimeter rather than at the perimeter. An insecure communications path within a network perimeter is a point of vulnerability within a critical infrastructure providers assets.

Internal Correspondence

See draft-menon-svr-02 - Secure Vector Routing (SVR) (ietf.org)   as an example

Looks like we need to add payload encryption as another requirement.
Looking at the data model for TMF676 it looks as if some resources need to be encrypted e2e ( e.g. Payment, PaymentItem  RelatedParty  but perhaps not the other resources. Wondering it model needs refactoring to allow for metadata like data time to be separated  from  the other attributes  like total amount;. or maybe these could be referenced to a separate entity Ref  which is encrypted with e2e key?

------------------------------
Dave Milham
TM Forum, Chief Architect
------------------------------

Original Message:
Sent: Oct 06, 2022 09:41
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Life is tough, Sean. You are absolutely correct that specific formats clash with encryption, this is our experience as well at Amdocs. And this clash impacts API signatures and underlying database schemas. Not to mention the problem of how to search efficiently (index) over encrypted data - e.g. in a Find Caller flow how do I find all the Sean Garagan in my Individual data store.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 06, 2022 09:29
From: Sean Garagan
Subject: Payload Encryption on TMF Compliant endpoint

Hey Jonathan,

We have had similar questions about at-rest encryption, specifically that property formats such as DateTime cause issues if the data within that property is encrypted.  This means that we may need to extend these entities to give an encrypted field to avoid the problems with deserializing a value that violates the property format or figure out some other way of managing at-rest encryption of data when using systems that do not support it, such as Kafka.  Are there any suggestions for handling situations like this or is extending the entities the best choice, at least for now?

Thanks,

Sean

------------------------------
Sean Garagan
Bell Canada

Original Message:
Sent: Oct 06, 2022 02:46
From: Jonathan Goldberg
Subject: Payload Encryption on TMF Compliant endpoint

Hi all
If I understand George's query correctly, he is not referring only to the transport encryption, which would be achieved by https, but rather to payload encryption. https/ssl protects (perhaps) against network sniffers and the like, but doesn't help after the transport is decrypted at the https end points.
This whole area needs more study, it relates also at-rest encryption, e.g. in persistent storage.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Oct 05, 2022 09:43
From: Koen Peeters
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

The TMF630 document doesn't spend a lot of words on this.
It does however contain the following:

All APIs SHOULD use HTTP/SSL, "HTTPS" as the scheme.

This means that the use of HTTPS with HTTPS compliant encryption of the payload is best practise.
I guess that means your endpoint is still compliant.





------------------------------
Koen Peeters
OryxGateway

Original Message:
Sent: Oct 04, 2022 03:03
From: George Munyi
Subject: Payload Encryption on TMF Compliant endpoint

Hi,

We are currently working on Payment specific endpoint following TMF676 and our security team requires that the Payload is encrypted and additionally relayed via HTTP via SSL. My question is would the endpoint still be TMF compliant ?

Unfortunately I haven't seen anything on encryption requirements from TMF630 Guidelines...

------------------------------
George Munyi
Safaricom Ltd
------------------------------