![](bg7.png)
message for channel requests in SEC_CHAN_REQ
message.
For MC-SSL to support multiple cipher suites,
we decide to make a small extension to SSL (This
will be explained in the next section). However, it is
possible that the SSL implementation at C and/or S
does not support the new extension for MC-SSL. In
that case, the negotiation of secondary channels will
either fail or not start at all.
5.2.2 Extension of SSL for Secondary Channels
SSL is the basis of the design and the
implementation of MC-SSL. In order to support
multiple channels, we propose to slightly extend
current SSL protocol, that is, to add a new field in
every SSL packet. The new field is channel id,
which indicates the channel that a packet comes
from so that the receiver can choose the right cipher
suite to decrypt and verify the data fragment
encapsulated in the packet. The purpose of channel
id is to realize (de)multiplexation inside an SSL
connection.
Considering that other new extensions may
emerge to require changing the packet format of the
SSL record protocol as MC-SSL does, we prefer
adding a general extension field so that future
extensions or options can be accommodated without
change. A similar extension mechanism has been
introduced into the client and server hello messages
of SSL handshake protocol. RFC 3546 has the
details for TLS extensions (Blake-Wilson, 2003). In
fact, many Internet protocols such as TCP and IP
have fields in their packet formats for options or
future extensions.
Because of the introduction of channel id field,
several changes regarding SSL protocol and its
implementations follow. First, the calculation of the
MAC must include the value of channel id field if a
SSL packet has a MAC field; therefore, the channel
id will not be tampered at will. Second, SSL
software must choose the right cipher suite for each
incoming packet according to the channel id. The
mapping relation between a channel id and a cipher
suite is managed by the protocol described in section
5.2.1. Third, some API (Application Programming
Interface) functions of SSL are different than before:
the write function has a channel id as an input
parameter, and the read function returns as an output
parameter the id of the channel from which the data
comes. It is up to applications to decide how to use
different channels.
Obviously, adding a channel id field is a simple
and straightforward approach for SSL to support
multiple cipher suites. The downside is that the SSL
protocol has to be revised and SSL software needs
upgrade to a new version. To completely avoid the
change of SSL protocol and implementation, we
have figured out a possible alternative for SSL
libraries such as OpenSSL (OpenSSL, 2004). The
basic idea is to “switch” among different channels
instead of simultaneously having multiple channels
in a SSL connection. The switching of channels is
realized by a handshake process implemented in the
upper layer codes of MC-SSL instead of the
underlying SSL. Basically, one endpoint sends a
MC-SSL message to notify the other endpoint what
channel it wants to switch to, and then receive the
confirmation message from the other endpoint. After
that, MC-SSL automatically changes the working
cipher suite in the SSL session. However, things are
not finished yet. First, it is much harder to switch the
working cipher suite for proxy channels, especially
multi-hop proxy channels. Second, if we change the
working channel to a cleartext channel (null cipher
suite without MAC), and then when we want to
switch it back to the primary channel, we must make
sure that the handshake messages are not tampered
by a man-in-the-middle attacker; otherwise, we
could be deceived to use a channel that is
cryptographically weaker. As a result, we must make
one more handshake through the new channel to
exchange the MAC data that is calculated upon the
previous handshake messages. This approach turns
out to require a handshake process that resembles
the abbreviated handshake of TLS 1.0 (Dierks,
1999). Such a four-way handshake is inefficient if an
application frequently uses different channels, for
example, to use different cipher suites for requests
and responses. In conclusion, we prefer to add a
channel id field in SSL packets than to add a
complex handshake process.
5.2.3 Typical Usage of Multiple Cipher Suites
A typical SSL session uses a cipher suite including a
128-bit cipher, and MD5 or SHA-1 hash algorithm
for MAC. With MC-SSL we can have an additional
channel with only MAC, but without encryption.
This channel could be useful for transporting data
that does not need confidentiality but require
authenticity. Such a channel combination is similar
to that of IPSec, in which authentication alone or
authentication plus encryption can be separately
provided by Authentication Header (AH) and
Encapsulating Security Payload (ESP) protocol.
A combination of block cipher and stream cipher
is another usage of multiple cipher suites. Streaming
media applications such as VoIP telephony often use
a stream cipher for confidentiality or privacy, but a
block cipher is probably necessary for user
authentication. For SSL, it has to renegotiate one
more time or open an additional connection.
ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS
252