Interfaces: Security keys for sessions

[fixtradingcommunity]

Interfaces: Security keys for sessions

[SpeedyGoneZales]

Many firms now mandate authentication using a TLS certificate and private key.
Implementing this certificate & key can sometimes present a challenge, particularly for proprietary software.
It would be great to be able to include the certificate / key into an Orchestra file, thus making the implementation transparent to the end user (possibly with the added security benefit of not needing to handle / store the private key in plain text and having to email it among various people.

This would be in a separate Orchestra file dedicated to session-level aspects (connectivity etc), not the application level file.

The structure of the supplied .zip for the TLS certificate is as follows:

• cms
  -- cert.kdb
  -- cert.sth
  --password.txt
• jks
  -- cert.jks
  -- password.txt
• pem
  -- CACerts.pem
  -- cert.pem
  -- cert_all.pem
  -- key.pem
• pkcs12
  -- cert.pfx
  -- password.txt

I've attached an example of a (revoked) certificate archive:
cert.zip

[SpeedyGoneZales]

Further to the working group call just now:

• it would be most convenient to include the certificate directly into the interface-type FIX Orchestra file (as opposed to include a pointer to an external file). This would allow vendors to read the information directly from the Orchestra file.

• can we afford to include the private key in the Orchestra file, too?
  Interface-type (as opposed to application-type) FIX Orchestra files are unlikely to be shared / publicly available, since they by definition contain proprietary information, such as CompIds, ports, IPs, etc.
  Thus, it can be reasonably assumed that the private key can form part of this information.
  On the other hand, integrating the key into the FIX Orchestra file may mask the fact that it contains sensitive information, thus there may be fewer concerns about sharing it (e.g. by putting it on a public file share). Would be good to discuss, certainly including the private key would be more convenient than having separately.

• Different implementations currently use different formats for TLS authentication (e.g. QuickFIX uses pkcs12, sTunnel uses pem).
  Could FIX Orchestra could define one standard for encryption (e.g. pem), which can be adopted by implementers as they see fit?

[donmendelson]

The Interfaces schema describes a service offering in terms of the OSI model protocol layers, and then allows for session configurations for the protocol stack. The familiar model layers of application, presentation, session, transport, and lower media layers are described in ISO/IEC 7498-1 The Basic Model.

There is also a second part ISO 7498-2 Security Architecture that describes security by layers.

1. The Authentication Layer
2. The Access Control Layer
3. The Non-Repudiation Layer
4. The Data Integrity Layer
5. The Confidentiality Layer
6. The Assurance / Availability Layer
7. Notarization / Signature Layer

This model may provide useful terminology for extending the Interfaces schema.

[donmendelson]

On the other hand, cipher suites combine features of multiple layers in the model, namely key exchange (authentication), encryption (confidentiality), and message authentication (non-repudiation).

[donmendelson]

Propose that a session configuration should support security keys in the format specified by IETF RFC 7468