The Simple Interdomain Bandwidth Broker Signalling (SIBBS) protocol specifies the Resource Allocation Request and Answer format, used to signal QoS parameters between Bandwidth-Brokers. Because the information that is transferred is related to contracts called Service Level Agreements, its content is sensitive to attacks. For this purpose, it is essential to ensure the integrity of Resource Allocation messages within SIBBS. This document describes two technical approaches which can be used by SIBBS.

 

A common way to authenticate messages is to use public key mechanisms. Public key mechanisms use keys to transform plaintext to ciphertext and vice versa. There are two types of keys used:

·        Private Keys are only known by the subject which is identified through it. Typically, they are stored symmetrically encrypted on disk.

·        Public Keys are known by every subject which wants to authenticate a message from the subject the public key is assigned to.

 

There is a strong relationship between private and public keys: a public key is associated with exactly one private key. The key pair is chosen by special algorithms, so that the encryption of a plaintext through one key can only be decrypted through the other:

 

Plaintext = Decrypt{ Encrypt{Plaintext}Public Key   }Private Key

             = Decrypt{ Encrypt{Plaintext}Private Key }Public Key

 

 

If the message can be decrypted with a subject´s public key, its originator has proven the knowledge of the related private key and hence authenticated himself.

 

Often it is not necessary to encrypt whole messages, but to assure the integrity of messages. A simple solution for this is to add a hash field to the message and to encrypt this field with the private key. This signature now assures two things:

 

  1. The message was not modified. To prove this, the receiver uses the subject´s public key to decrypt the encrypted hash. The original value is now compared with a hash value calculated from the received message. As good hash functions do have an extreme low probability that two messages might have the same hash value, it can be assumed that the same hash value indicates an unmodified message.
  2. The message was originated (or signed) by a specific subject because only someone with the private key could have made the hash decryptable with the public key.

 

Based on this concept, SIBBS can assure the integrity of messages with two mechanisms:

 

1.      All messages transferred within SIBBS are signed by the (logical) source.

The receiver of a message must have the possibility to identify the source of a message, and must have access to the public key of the identities. As the signature is the only authentication tool within this concept, the message is not required to be submitted from the originator. Conceptually, any subject can transport the message. The integrity is proved by the Sender ID, which indicates the public key to be used, and the signature. The process delivering the message is irrelevant for authentication purposes. 

Note that the current version of SIBBS enforces a BB-to-BB communication. For authentication purposes this is not required.

 

By itself, this technique is unable to prevent so-called replay attacks where the SIBBS messages are captured by a sniffer and then retransmitted without any modifications.  To prevent replay attacks, the RAR ID field (and CANCEL ID field) can be used by BB implementations. Each RAR ID has to be stored until its associated reservation expires. In doing this, the BB is able to identify replay messages. However, to support modifications of reservations, it is necessary to add a counter to either the SPO, the RAR ID or the whole message. Otherwise it might be possible to replay reservations which have been modified more than once, by replaying one of the modify messages (renegotiation is currently only indicated by a flag). So a BB must have the ability to distinguish between each modification.

 

2.      Mutual authentication is performed. All messages are additionally checked for integrity.

The above mentioned model has the disadvantage that the source of a RAR is not able to check whether the message has been received by the correct BB until a RAA indicates this. One solution is to perform mutual authentication as it is done in the Grid Security Infrastructure. All messages can be authenticated in a manner that assures the integrity and that guarantees that the message has been received by the correct BB. Typically, as this is also true for the Grid Security Infrastructure, this is done by using the SSL protocol version 3 (or TLS in later SIBBS versions). Within this concept, each communication entity must have a certificate, signed by a trusted certificate authority. During the establishment of a session, the SSL handshake protocol is performed, which mainly consists of the exchange of the certificates and the proof of the knowledge of the private key. Additionally, a session secret is exchanged. This secret can be used to encrypt the hash of a message by using a symmetric encryption algorithm. Consequently, this concept does not require the usage of signatures in the message fields, as the transport protocol is assuring the integrity of messages and does provide shields against attacks.

 

This concept fits well into the current version of SIBBS, where messages are exchanged between neighboring BBs within long term TCP sessions.

 

Recommended Implementation

 

Depending on the chosen authentication model, we propose the following issues any implementation must follow:

 

1.      To sign messages, the implementation should support at least the MD5 hash function. For encryption of the hash we propose to support RSA. This proposal is compatible to the usage in the Grid Security infrastructure. To avoid interoperability problems between different software implementations, we propose to use SSLeay 0.9.0 or OpenSSL to implement the signing function. If different software has been selected, interoperability with signatures created with the proposed software must have been proved. We claim that each BB should apply for an X509 certificate, as access to the public key can be established by accessing the encoded certificate. There is no requirement to claim specific certificate encoding formats.

 

2.      To perform mutual authentication implementations should use SSLeay 0.9.0 or OpenSSL. The use of different software must have demonstrated its interoperability.

 

Each SIBBS message is passed to the Message Integrity Check (MIC) routines of the SSL implementation. In the current SIBBS version, MD5 must be used to create the message authentication code (MAC). The secret used to calculate the MAC is the session key that SSL has set up specific for each session via the mutual authentication phase (via RSA). As all BBs must have a certificate, we will establish a list of certificate authorities which must be supported.

 

To simplify the implementation, we recommend the usage of high-level libraries such as Globus I/O (http://www.globus.org/v1.1/io/globus_io.html). This library provides a uniform I/O interface  to stream and datagram style communications. It can easily replace all socket calls in any existing applications and is build on top of SSLeay. The main advantage of the usage of this library is that it is capable in performing the discussed security functions automatically, simply by adding a call setting the desired authentication mode.