Management of industry wide security tokens is a complex discussion ongoing within STAR Transport committees. STAR anticipates future releases of this guideline will define and make recommendations on the creation and management of binary security tokens that provide for Identity, Authentication and Privacy.

In this release STAR Transport has focused on recommending technologies that can support binary security tokens including Digital Certificates and Username/Password combinations. Field experience with the simple use of these tokens will help STAR define the requirements for management models that may include Certificate Authorities and or Federated authentication systems.

The ebMS Ping/Pong services enable one EndPoint Gateway (which ebMS refers to as a Message Service Handler) to determine if another EndPoint Gateway is operating. A sending gateway would send a Ping message to a receiving gateway which replies with a Pong. The Ping and Pong message formats are clearly defined in the ebMS 2 specification and are composed of the typical ebMS message format with no payloads and a required Service element value of “urn:oasis:names:tc:ebxml-msg:service” and a required Action element value of “Ping” or “Pong” as appropriate.

Recipients of a Ping MAY ignore the message if they determine the sender is unauthorized or that the message is part of a denial of service attack.

Parties should digitally sign Ping and Pong messages to minimize the security risks. If a Ping message is sent with a ds:Signature, the receiving party can authenticate the sending party. If the responding Pong message is sent with a Signature, the originating gateway can authenticate the original receiver. This will establish an important layer of security in implementing Ping/Pong services. If the signature verification fails on the receipt of a Ping message, the receiving gateway should not generate a pong response.

Network Time Protocol is a widely used internet standard mechanism for synchronizing computer clocks. NTP clients poll NTP servers, which are connected to precise UTC time sources via radio, satellite or other means. The net effect is that a client computer system can maintain its own system clock with milliseconds or fractions of milliseconds of UTC time, enabling networks of computers to have their internal clocks precisely synchronized.

UTC (Coordinated Universal Time) is a widely used mechanism that can be leveraged to express precise values of time a manner that makes it easy to avoid issues with changes in time zones.

UTC is the successor to what used to be generally referred to as Greenwich Mean Time and is often referred to as Zulu time. By combing XML Schema datetime elements with UTC, STAR parties can enable consistent and precise timestamps that do not suffer from time zone issues. For example a sender timestamp can always be interpreted correctly, as there is no need for the receiver to understand which time zone and or daylight savings times the sending system is subject to.

Logging all messages provides a reliable record of message traffic between two parties. Diagnostic research for issues such as lost messages, performance problems, or transmission problems is greatly improved with a message log. Logging all messages may be the only way that a single lost message can be tracked down. Logging may also be switched off or on as necessary to assist in debugging transport or message implementations.

Since the Transport layer is only concerned with message traffic, the log entries SHOULD contain information about the transfer, such as message ID, sender, receiver, timestamp of transmission and receipt, type of message, and sender network ID. Additional information may be maintained, but this is a minimum set of useful information. Message logs may be exchanged through out-of-band means such as email or FTP.

There is a concern that logging messages comes at a cost of storage and processing that depends on the retention of the logs. For example, 50 messages a day from 1000 dealers would generate 50,000 messages; if each message log entry is 200 bytes then the log will grow by 10MB each day. The storage requirements for a week’s messages would be about 50MB, for a month’s messages, 200MB. An automated system for archiving, deleting or rotating logs is necessary to manage storage of logs with continuous logging. Some parties may turn off logging to avoid consuming storage. There are no recommendations or requirements regarding the retention of logs for management purposes.

To insure that log information can be obtained, all parties MUST be able to capture and provide logging upon request. There are significant benefits to have logging always turned on, but STAR will NOT REQUIRE continuous logging.