Sept 17th Meeting Minutes

[fplpo_x]

Imported from previous forum

[fplpo_x]

[ original email was from Charles Blauner - blauner_c@jpmorgan.com ]
FIX Encryption Working Group Meeting Minutes

The following is the set of “high-level” minutes of the FIX encryption
working group meeting held on September 17, 1998 at Goldman Sachs’ offices
at 125 Broad Street in NYC. The meeting was attended by people representing
FIX users, FIX product/service vendors, and invited technical experts.
The set of attendees included:

1. Charles Blauner - JP Morgan (Chair)
2. Sam Johnson - Goldman Sachs
3. Nick Seth-Smith - Goldman Sachs
4. Brien Oberstein - Goldman Sachs
5. Steven Polinsky - Goldman Sachs
6. Frank Marsillo - Goldman Sachs
7. Collin Sampson - Bear Stearns
8. Danny Shobrook - Apt Computer Systems
9. Joe Sommer - DLJ
10. Dwight Arhtur - NSCC
11. Ryan Pierce - Townsend Analytics
12. Bill Hebert - Thomson Financial Services
13. Curt Vincent - Morgan Stanley
14. Marla Dans - Morgan Stanely
15. Gene Rao - Chase
16. Howard Taylor - Chase
17. Larry LaBella - Merrill Lynch
18. Val Melamed - Ease Technologies
19. Russell Morgan - Entrust Technologies
20. Peter Wittaker - Entrust Technologies
21. John Linn - RSA/Security Dynamics
22. Tim Dierks - Certicom

After Introductions, the group started to review the high-level security
requirements document that had been developed and previously published,
by reviewing the current usage models for FIX and then describing the usage
models that were of interest to the group. The results of the discussion
yielded four basic business/usage models:

• Straight point-to-point with telephone confirmation for most
  transactions
  • Note some small $ value transactions may not involve a
    recorded phone conversation as the legal basis for the
    transaction. The executing firm accepts the risk of a
    repudiated transaction.
• Hub model
  • Hub takes no liability for anything going wrong with
    the transaction.
  • Hub is not to be aware of actual transaction details.
• Retail model
  • Similar to hub model, where hub acts as an intermediary
    between retail clients and firms actually executing the
    transaction
  • Hub accepts some amount of liability
• Point-to-point with the recorded phone conversations eliminated
  • Non-repudiation provided by end-to-end digital signatures
  • This is the high-end model which when implemented could
    provide all of the functionality of the other models
    described above

Based on these four business models we created a simplified view of the
security goals/requirements relative to the session and application views
of the FIX protocol.

• Encryption at the session layer
  • Ability to move FIX away from private VANs of leased lines
    to cheaper public networks such as the Internet
  • Provides endpoint authentication (not persistent)
• Encryption at the application layer
  • Partial or complete content hiding (i.e., from a hub)
  • Also supports the move to public networks
• Signing at the application layer (note, it was basically agreed that
  signing at the session or transport layer provides no useful
  functionality other than message integrity which you get for free
  with the encryption at the session layer model)
  • Facilitates non-repudiation
  • Provides endpoint authentication (persistent)

In order to implement these goals within FIX, a number of different security
models were discussed:

• FIX engine directly to another FIX engine
  • Provides accountability at a corporate level.
  • Implemented by transport/session layer encryption.
    • Does not provide non-repudiation, but that is OK if
      the right contracts are in place or if the value of
      the transaction is low enough that the material risk
      to the firms participating in the transaction is
      negligible.
• FIX engine to a hub, which provides some value add, to another FIX
  engine
  • Provides accountability at a corporate level.
  • Implemented by application level encryption/signing
  • Full and partial message confidentiality
  • Full and partial message signatures, multiple signatures
    possible
    • Cascading or enveloping of signatures
    • Corporate level signature(s)
• Order entry system (system or person) through a pair of FIX engines
  to an order execution system (system or person)
  • Provides accountability at a corporate or individual level.
  • Implemented by application level encryption/signing.
    • Requires extending the security model beyond the
      current boundaries of the FIX protocol specification.
  • Provides full and partial message confidentiality
  • Full and partial message signatures, multiple signatures
    possible
    • Cascading or enveloping of signatures
    • Corporate or individual signature(s)
  • Subset problem of one end point being a FIX engine is easy
    once this higher end problem is solved.
• Retail client to hub (over a light-weight UDP protocol) then on to
  a FIX engine.
  • This model was brought-up but the problems associated with
    UDP protocols limited any discussion.
  • Would require security model to be implemented at the
    application layer since the use of UDP precludes a session
    layer solution.

Path forward is to break the solution development up into several phases:

• 1st phase is to address FIX engine to FIX engine transport
  • Limits changes required to the session layer protocol
  • 3 options:
    • FIX engine configured to think that no encryption
      is taking place
      > Run it over SSL
      > Run it over a VPN proxy
    • FIX engine is SSL aware
      > Requires modified logon message and integrated
      SSL libraries
  • Target completion date of a phase one specification is 12/98
    • Will try to debate pros and cons of the three options
      to the e-mail list
• 2nd phase focuses on changes to the application protocol but limiting
  efforts to the current FIX space
• 3rd phase extends the security model beyond the current purview of
  FIX into order entry/execution systems to support non-repudiation and
  individual accountability
  • It is this 3rd phase that will allow the elimination of the
    phone call as the basis for the legal standing of an electronic
    FIX transaction. There was some discussion about signing of
    the major invariant fields in a defined format and sequence at
    source in order to enable this option. This will clearly need
    further investigation.