Copyright 1997 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
This article was published in the May/June 1997 issue of
IEEE Network.

ABSTRACT

 

It is envisioned that asynchronous transfer mode (ATM) will provide scalable and high-performance application-independent security services. The ATM Forum Security Working Group is currently developing its phase one security specification, which defines a number of security services for the ATM user plane and control plane. In addition, mechanisms for carrying security-related messages and required security infrastructure mechanisms are also being defined. These mechanisms will allow an organization to build an ATM network which not only meets its performance objectives, but also its information protection requirements as specified in its site security policy. This article provides an overview of ATM security as specified by the ATM Forum Security Working Group. First, the ATM user and control planes' security services and mechanisms are described. Then the security messaging mechanisms at connection establishment and during connection lifetime phases are discussed.

 

 

Asynchronous Transfer Mode Security

 

Mohammad Peyravian, IBM Corporation
Thomas D. Tarman, Sandia National Laboratories

 

Thomas D. Tarman's work was supported by the United States Department of Energy under contract DE-AC04-94AL85000.

Asynchronous transfer mode (ATM) promises secure and manageable bandwidth on demand with a seamless local/wide area network (LAN/WAN) integration and performance. ATM is a high-speed connection-oriented networking standard envisioned to integrate in the network a variety of applications (voice, video, data, image, etc.) with different quality of service (QoS) requirements. Characterizing ATM as connection-oriented indicates that connections use fixed routes through the network, and bandwidth is reserved on the links constituting the routes to meet the QoS requirements of applications. To establish a connection for a given source-destination pair of nodes, a route through the network is selected. Routes in ATM networks are either pre-established (i.e., semi-permanent connections) or established on demand dynamically as connection requests arrive. Many different kinds of information are carried in short fixed-length packets called ATM cells. The ATM cell is composed of 53 bytes, of which 48 bytes are the payload and 5 bytes make up the header. At the edges of the network user information frames are broken up into ATM cells. At the destination side of the network the user information frames are reconstructed from the received cells.
One of the present weaknesses of ATM is that it does not offer security services. This is a major inhibitor of the customers' ability to implement ATM. Increasingly, businesses, financial institutions, and government agencies want to migrate to ATM; however, to exploit its full potential, they will need security services. Currently, most ATM circuits are available only as PVCs (permanent virtual circuits), and private lines connect fixed company sites. However, when it comes to SVCs (switched virtual circuits) across corporate boundaries or intracompany SVCs across a service provider network, the availability of ATM security will become a major factor in determining the spread of ATM.
ATM will likely be used in the future to provide mission-critical communications for applications such as financial transactions, medical information systems, and military communications. These applications require strong cryptographic algorithms and protocols to provide a high degree of assurance in the security of the communications. With strong ATM security mechanisms, protection against spoofing, malicious data modification, and eavesdropping can be ensured. Without these mechanisms, mission-critical applications can only exist with the help of expensive, possibly noninteroperable devices.
The minimum level of security ATM needs to provide is authentication of ATM endpoints, as well as a method of protecting user data [1]. The high-speed cell relay nature of ATM presents some unique problems to the task of securing it. Some of these issues are outlined below.

The need for interoperable security for ATM was first addressed by the ATM Forum in early 1995 in a number of contributions that addressed high-level requirements [2–4]. A clear need for standardization of security for ATM was articulated; as a result, the Security Working Group was officially formed in October 1995.
ATM security, as defined by the ATM Forum Security Working Group, is modeled after the ATM protocol reference model, which is divided into three planes: user, control, and management [5]. The user plane provides for the transfer of user data. It contains the physical layer, ATM layer, and multiple ATM adaptation layer (AAL) types. The control plane deals with connection establishment, release, and other connection functions. The control plane shares the physical and ATM layers with the user plane. In addition, it also includes a signaling AAL based on AAL5 and higher-layer signaling protocols. The management plane performs management and coordination functions related to both the user and control planes. Phase one of the ATM Forum security specification provides security services for the user plane and limited services for the control plane. Security services for the management plane will likely be provided in a future release of the specification.
In this article, we provide an overview of ATM security as specified by the ATM Forum's Security Working Group. The ATM user and control plane security services and mechanisms are described first. Then we discuss the security messaging mechanisms at the connection establishment and connection lifetime phases.

ATM Security Services

The scope of work for phase one in the ATM Forum Security Working group includes the specification of user plane (data) security services and control plane (signaling) security services. User plane security services provide protection for user information carried over virtual connections in a number of ways. Authentication allows the calling and called parties to positively identify each other such that a third party cannot impersonate one of the two (i.e., "spoofing" or masquerade threats). The key exchange service allows the calling and called parties to agree on keys which will be used during the lifetime of the virtual connection to provide data integrity and confidentiality services. The integrity service provides assurance that the data carried by the virtual connection cannot be modified by a third party. The confidentiality service provides protection against third-party "eavesdropping" of the data sent on the virtual connection. Finally, the access control service provides additional security-related information which, at the time of connection establishment, allows the endpoints to determine whether to accept the connection request [5] according to the site security policy.
Control plane security services provide security protection mechanisms for the ATM signaling infrastructure. Currently, the ATM Forum Security Working Group is working on a specification for a control plane authentication service, which allows signaling entities (such as endpoints and switches) to validate the source and contents of the signaling message [6]. This service will provide protection against threats associated with spoofing and denial-of-service attacks.

User Plane Security Services

The user plane security services being defined by the ATM Forum will apply to virtual channel connections (VCCs) and virtual path connections (VPCs) for both point-to-point and point-to-multipoint connections. For the phase one security specification, these security services are being defined for three scenarios: user-to-user, user-to-network, and network-to-network. The security-enabled ATM nodes have "security agents" which implement the necessary security protocols and mechanisms that function at connection setup and during the lifetime of the connection.
Initial Authentication, Key Exchange, and Negotiation of Security Options -- Authentication is the user plane security service that allows the two parties in a connection establishment context to positively identify each other. This is an important function not only for its direct benefits, but also because it is often required for other security services such as key exchange. Authentication, key exchange, and security negotiation are described together here because the same protocol is used to accomplish these three features.
Unlike datagram-oriented protocols, which accomplish authentication only on a per-packet basis, the connection-oriented nature of ATM allows two parties to use a more elaborate authentication protocol during connection establishment. Because the cost of the overhead associated with digital signature algorithms is amortized across the lifetime of the connection, stronger (albeit slower) authentication protocols can be used during connection setup. This also allows other security functions (such as key exchange) to be accomplished at the same time with little additional overhead.
With this property in mind, the ATM Forum Working Group has defined a protocol used during the establishment of a VCC or VPC which accomplishes authentication, key exchange, and negotiation of security attributes. This protocol, which is largely based on International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 9594-8 and ISO/IEC 11770-2, provides for mutual authentication using three flows or two flows (Fig. 1 and Fig. 2) [5, 7]. The two- and three-way user plane security message exchange protocols are not dependent on the use of any particular cryptographic algorithm. For each approach, authentication can be accomplished using asymmetric or symmetric cryptographic algorithms. Additionally, these protocols provide the following functions: optional mutual authentication and optional one- or two-way key exchange. Finally, the three-way security message exchange protocol supports negotiation of security services and options, and optional certificate exchange [8]. In the current ATM security specification, the exchange of certificate revocation lists (CRLs) is not supported, and the exchange of certificates is only allowed when "in-band" messaging is used. The "signaling-based" exchange of certificates is not allowed due to the rather large size of certificates. (The in-band and signaling-based security message exchange mechanisms are discussed in the third section.)
Security Message Exchange Protocols -- In the two- and three-way security message exchange protocols, one user of the protocol assumes the "initiating" role, the other remote user the "responding" role. The "security agent" operating on behalf of the initiating user is referred to as the "initiator," that operating on behalf of the responding user as the "responder." When setting up a point-to-point connection or when setting up the first leaf of a point-to-multipoint connection, the initiator has the option to use either the two-way or three-way security message exchange protocol.
In the security message exchange protocols, when asymmetric (public) key algorithms are used, it is assumed that each authentication entity (i.e., A and B) possesses a public/private key pair. Ka represents the public component of A's asymmetric key when it is used for encryption, and the private component of A's asymmetric key when it is used for digital signature. Similarly, Kb represents the public component of B's asymmetric key when it is used for encryption, and the private component of B's asymmetric key when it is used for digital signature. When symmetric (secret) key algorithms are used, it is assumed that the authentication entities A and B share two unidirectional secret keys Ka and Kb, or a single secret key Ka = Kb.
The key exchange option of the security message exchange protocols allows the security agents at two endpoints to agree on keys which will be used for confidentiality and encryption services during the lifetime of the connection. These keys could be used directly, but, as described below, they are more likely to be used as "master" keys which encrypt the short-lived "session" keys. Key exchange is accomplished in the two- and three-way protocols through the use of the ConfPar variables contained in the authentication flows. These variables could be encrypted using either symmetric or asymmetric encryption algorithms. Once established, these session keys may be changed periodically during the duration of the connection using the "session key update" protocol described later.
Security negotiation is accomplished in the three-way exchange protocol through use of the SecNeg parameters. Negotiation is required in order to support flexibility in the architecture. This flexibility allows implementors and users to select which cryptographic algorithms and protocols they would like to use -- a choice which is often constrained by export laws, royalty costs, and site security policies. In the first flow, the initiator provides a list of security services and parameters (e.g., algorithm type, length of key, public algorithm-specific parameters) that it is capable of using for the connection. In the second flow, the responder replies with the list of services and parameters for the connection. If the initiator agrees with the response, it completes the protocol, and both parties use the services and parameters contained in the responder's reply; otherwise, the protocol and connection request fail.
The three-way security message exchange protocol supports both asymmetric and symmetric key algorithms. When authentication or key exchange is invoked, this protocol uses a nonce-based (i.e., Ra, Rb) mutual authentication: A is authenticated to B and B is authenticated to A. Note that A is not authenticated to B until FLOW3-3WE is received and checked. It involves the following steps:
  • A sends FLOW1-3WE (which contains the following required tokens: A, Ra, and SecNega) to B. When certificate exchange is needed, Certa is also included in FLOW1-3WE. Certa is used to carry the initiator's certificate.
  • When B receives FLOW1-3WE, it carries out the following actions:
    -Checks that B itself is the intended recipient when B is included
    -Extracts SecNega and interprets it for its reply
    -When authentication or key exchange is required
    Extracts the nonce Ra for its reply
    Extracts Certa if present and verifies its validity
  • B sends FLOW2-3WE (which contains the following required tokens: A, B, and SecNegb) to A. When authentication or key exchange is required, the authentication token (i.e., {Ra, Rb, ...}) is included in the flow. When key exchange is needed, ConfParb is also included in FLOW2-3WE. When certificate exchange is needed, Certb is also included in FLOW2-3WE.
  • When A receives FLOW2-3WE, it carries out the following actions:
    -Checks that A itself is the intended recipient
    -Extracts SecNegb and interprets it
    -When authentication or key exchange is required:
    Verifies the signature, and thus the integrity of both FLOW1-3WE and FLOW2-3WE
    Checks that the received Ra in FLOW2-3WE is identical to that sent in FLOW1-3WE
    Extracts the nonce Rb for its reply
    Extracts ConfParb if present and interprets it
    Extracts Certb if present and verifies its validity
  • When authentication or key exchange is required, A sends FLOW3-3WE (which contains the following required tokens: A, B, Rb, ...) to B. When key exchange is needed, it is also included in FLOW3-3WE.
  • When B receives FLOW3-3WE, it carries out the following actions:
    -Checks that B itself is the intended recipient
    -When authentication or key exchange is required:
    Verifies the signature, and thus the integrity of FLOW1-3WE
    Checks that the received Rb in FLOW3-3WE is identical to that sent in FLOW2-3WE
    Extracts ConfParb if present and interprets it
In the two-way security message exchange protocol, the initiator uses the SecOpt token to indicate to the responder what security services are to be provided for the connection. SecOpt carries the security services, options, and parameters requested for the connection. This includes the type of security services to be provided for the connection (e.g., authentication, data confidentiality) and the algorithms/modes of operation to be used for each security service. Figure 2 shows the two-way security message exchange protocol. This protocol supports both asymmetric and symmetric key algorithms.
When authentication or key exchange is invoked, the two-way security message exchange protocol uses a timestamp and nonce-based (i.e., Ta, Ra) mutual authentication. A gets authenticated to B and B gets authenticated to A. It involves the following steps:
  • A sends FLOW1-2WE (which contains the following required tokens: A, B, and SecOpt) to B. When authentication or key exchange is required, the authentication token (i.e., {Ta, Ra, ...}) is included in the flow. When key exchange is needed, it is also included in FLOW1-2WE.
  • When B receives FLOW1-2WE, it carries out the following actions:
    -Checks that B itself is the intended recipient
    -Extracts SecOpt and interprets it
    -When authentication or key exchange is required
    Verifies the signature, and thus the integrity of FLOW1-2WE
    Checks that the timestamp is fresh and that the flow is not a replay or out-of-order
    Extracts the nonce Ra for its reply
    Extracts ConfPara if present and interprets it
  • When authentication or key exchange is required, B sends FLOW2-2WE (which contains the following required tokens: A, B, Ra,...) to A. When key exchange is needed, ConfParb is also included in FLOW2-2WE.
  • When A receives FLOW2-2WE, it carries out the following actions:
    -Checks that A itself is the intended recipient.
    -When authentication or key exchange is required:
    Verifies the signature, and thus the integrity, of FLOW2-2WE
    Checks that the received Ra in FLOW2-2WE is identical to that sent in FLOW1-2WE
    Extracts ConfParb if present and interprets it
For point-to-multipoint connections, the first "leaf" is added to the call by using one of the security message exchange protocols described above. However, when setting up subsequent leaves in a point-to-multipoint connection, the initiator can only use the two-way security message exchange protocol.
Protocol Trade-offs -- There are a number of trade-offs which should be considered when selecting the ATM two- or three-way security messaging protocols. These trade-offs are described below and summarized in Table 1 (where n is the number of nodes in the network for which security services apply). In order to protect the authentication protocol from spoofing using the well-known "replay attack," the authentication flows must be unique, in order, and fresh. This can be accomplished in two ways: using timestamps and sequence numbers, or via a "challenge-response" protocol.
The timestamp-based approach should be used if mutual authentication is required in two flows or source authentication is required in one flow. The latter case is important if an ATM "firewall" is used to passively filter (with respect to the end systems) connection requests based on the authentication credentials of the source. However, the drawback of a timestamp-based approach is that it requires a certain degree of time synchronization between the source of the message and the entity that verifies the authentication credentials.
The "challenge-response" approach provides the requisite guarantees of uniqueness, ordering, and freshness through the use of one-time random numbers, or "nonces." This is accomplished by sending a nonce as a "challenge," which the remote entity digitally signs and returns to the challenging entity. This approach circumvents the need for time synchronization. However, it is unsuitable for the ATM firewall scenario, because the firewall must now actively participate in the protocol.
Another interesting trade-off concerns the use of asymmetric (public key) algorithms versus symmetric (secret key) algorithms. Asymmetric algorithms provide each entity with a "private key" held only by the entity, and a "public key," which can be freely disseminated and used by others to validate a digital signature generated by the entity to which the key belongs. The advantage of asymmetric algorithms (for both digital signatures and encryption) is that private keys need only be issued once per user, making the key management complexity O(n). However, asymmetric algorithms are computationally intensive due to complex functions such as "modulo exponentiation."
Symmetric algorithms, on the other hand, can be quickly computed because they typically use "shift and permute" operations. However, symmetric algorithms require the source and destination entities to share a common key. For a network of n nodes, the ability to authenticate each other with the two and three-way exchange protocols requires that each node have a common key with every other node, resulting in a key management complexity of O(n2). In large networks, key management complexity makes authentication based on symmetric algorithms unrealistic.
Access Control -- Access control is an ATM security service that decides whether a connection is authorized to proceed. While the mechanism is vendor-specific, the format of the information required by the access control device must be standardized in order to achieve interoperability. In addition to the security-relevant information contained in the authentication protocol, the phase one security specification also defines a "label-based access control" information element [5, 9]. This allows a trusted calling party (such as a compartmented-mode workstation, CMW) to "label" the sensitivity of the requested connection. If the label falls within acceptable bounds (as determined by the called party or an intermediate device), the connection request is allowed to proceed. This is an important security service for so-called multilevel secure (MLS) ATM networks, which contain trusted components that process data at multiple sensitivity levels.
Integrity and Data Origin Authentication -- Unlike the security services described above, the integrity service (sometimes known as "data origin authentication") is active once the ATM virtual circuit is established. This mechanism provides protection against malicious modification and data insertion attacks, which could spoof an end system into acting on false data. This protection is accomplished through the use of a message authentication code (MAC), which is appended to the AAL service data unit (SDU) before transmission. The data integrity function is provided at the AAL SDU level (rather than the ATM layer) because the ATM cell has a fixed size and does not have any room left for a MAC. This MAC uses a key, negotiated during connection establishment, to bind the data to the source. This provides assurance to the receiver that the AAL SDU was originated by the source which authenticated itself at connection setup.
The phase one ATM security specification defines two methods of data integrity protection -- data integrity without replay/reordering protection, and data integrity with replay/reordering protection. When data integrity is provided without replay/reordering protection, the MAC is simply calculated over the contents of the AAL SDU (Fig. 3). This integrity option is most useful in cases where higher-layer protocols (e.g., Transmission Control Protocol, TCP) use their own sequence numbers. In this case, any AAL SDUs that are stored and resent or reordered will be detected at the higher layer, making replay/reordering protection at the AAL level unnecessary overhead [5, 10].
Alternatively, data integrity may be performed with replay/reordering protection. In this case, cells that are stored and resent or reordered will cause the receiving end system to detect this attack at the AAL level and react accordingly. This protection is provided by a sequence number appended to the AAL SDU before the MAC is calculated. This level of integrity protection is useful for applications that do not append sequence numbers to higher-level (above AAL) data units, such as so-called native ATM applications.
Confidentiality -- The confidentiality security service provides protection against unauthorized disclosure of data due to "eavesdropping" attacks. This service uses encryption to ensure that only those recipients with the proper key(s) are capable of deciphering the data into something more meaningful.
The data confidentiality service, as defined in the phase one ATM security specification, is an ATM cell-level service. With this service, the 48-byte payload of the ATM cell is encrypted; the 5-byte header is left intact [10]. This is fortunate for ATM encryptor developers, since ATM cells are fixed in length, making high-speed, hardware-based implementations possible. This is particularly important for encryption devices to operate at rates above 155 Mb/s.
Encryption of high-data-rate ATM traffic has always been of concern to the ATM Forum Security Working Group. Fortunately, most symmetric (secret key) encryption algorithms can be implemented in silicon, and can therefore be made to scale to higher speeds. However, the mode of operation1 in which the algorithm is used (e.g., cipher block chaining, CBC) can adversely affect the interoperability between parallel (scaled) implementations and serial implementations of the algorithm [11].
One potential problem for ATM cell encryption is the management of cell loss. For certain modes of operation, a lost cell will result in loss of cryptographic synchronization. That is, once a cell is lost, the receiver will not be able to properly decrypt the rest of the cell stream. To address this issue, the Security Working Group has defined an operation, administration, and maintenance (OAM) cell (a subspecification of the system management OAM cell) which carries resynchronization information (such as a cryptographic state vector). This OAM cell is sent periodically at a user-specified frequency such that both information loss and OAM overhead are minimized.
The phase one ATM security specification supports a number of symmetric-key block encryption algorithms. These are data encryption standard (DES) and triple-DES in electronic codebook (ECB), CBC, and counter modes and FEAL in ECB and CBC modes. The counter mode is currently the only defined mode with cryptographic resynchronization. The other two modes (ECB and CBC) are self-synchronizing. The algorithm and mode of operation to be used for a connection can be negotiated during the connection setup using the three-way security message exchange protocol.
Session Key Update -- As stated earlier, when a connection is established, keys for integrity and confidentiality services are negotiated. However, when a key is used to provide confidentiality and integrity protection, the probability of successfully "cracking" the key increases with time. To prevent such an attack from being successful, keys must be changed periodically (the frequency of change depends on the rate at which data is transformed under a given key) [12]. To this end, a "session key update" procedure has been defined to support periodic key changeover.
This procedure uses a master key, which is used to encrypt short-lived session keys, which are then used for a period of time for integrity and confidentiality services. The master key and first session key are exchanged during initial negotiation. However, subsequent session keys must be transferred in the data channel so that the receiver may load them and start using them at the appropriate time.
The method for session key update as described in the phase one ATM security specification consists of two phases: session key exchange (SKE) and session key changeover (SKC). SKE allows the transmitting end system to generate a new session key, encrypt it, and send it to the receiving end system. This new key is transferred in a special OAM cell which has been defined for this purpose. Since the OAM cell may be lost in transit, multiple copies of the OAM cell may be transmitted to the receiving end to increase the probability of successful exchange [5, 7].
Once the SKE is accomplished, the key is stored by the receiving device until the SKC. When the transmitting end system decides to change keys, it sends a specially defined SKC OAM cell to the receiver. Again, to increase the probability of successful reception, the transmitter may send multiple copies of the SKC OAM cell. Once the receiving end system receives the SKC OAM cell, it immediately loads the new key so that it can be applied to the next unit of data (which could be the next cell).

Control Plane Security Services

The ATM control plane is responsible for configuring network devices to achieve a desired objective. For example, the control plane is used by end systems and network devices to establish an SVC. Because the control plane plays an important role in network configuration and operation, its protection from malicious and nonmalicious (accidental) activities is important.
For the phase one ATM security specification, the Security Working Group is considering mechanisms to provide authentication of control plane messages. Other control plane security functions will be addressed in future versions of the specification.
Authentication -- As with user plane authentication, control plane authentication provides strong protection against spoofing. This allows network components to be confident that a control plane request (such as a signaling message) originated from a "trustworthy" component. This provides protection against some "denial of service attacks" because messages that are not authentic (i.e., shown not to originate from a "trustworthy" source) can be ignored.
The Security Working Group is currently developing a definition for an "authentication information element" which contains a digital signature and a timestamp (to provide the freshness, ordering, and uniqueness guarantees described earlier for user plane authentication). In addition, the authentication information element contains information that describes which components of the message have been included in the digital signature. This allows certain fields (information elements) in a signaling message to be modified by ATM switching equipment without invalidating the digital signature [6] (which is computed across the other, nonvariant components of the message).

ATM Security Messaging

In order to accomplish the security services described earlier, a mechanism for conveying security-related messages is required. The messaging mechanism used by the security services varies, depending on whether the service is invoked at connection establishment or during the connection lifetime. At connection setup, security messages may be exchanged via the signaling channel or in the newly established data channel. During the connection lifetime, OAM cells are used to carry security messages.

Security Messaging at Connection Establishment

For connection establishment, two methods exist for security messaging. If the signaling entities in the end systems and network devices support security messaging, security messages may be exchanged in the signaling channel. However, if these devices do not support security messages, the end systems and security agents must exchange security messages in the data channel immediately after connection establishment and before data is sent on the new VCC/VPC.
Security Signaling -- To support the security protocols described earlier, extensions to existing ATM signaling specifications are currently being developed by the Security, Signaling, PNNI (private network-to-network interface), and B-ICI (between-intercarrier interface) working groups of the ATM Forum. These extensions consist of definitions of protocol procedures and information elements (IEs) to carry the information required of these protocols. These IEs include the security options, alternate security options, security authentication parameters, security confidential parameters, and label-based access control IEs [5, 13, 14].
The security options and alternate security options IEs contain information regarding the security capabilities of the end systems and security agents involved in the security association. This information includes type of service (authentication, confidentiality, etc.), algorithms, modes of operation, and algorithm details (public parameters, key length, etc.). These IEs are used by the end systems and security agents to negotiate a common set of services, algorithms, and other details which will be used for the duration of the connection. This negotiation is accomplished by the authentication and key exchange protocol described earlier.
The other IEs defined in the phase one ATM security specification provide a means to communicate service-specific parameters between security agents along the virtual channel. Such parameters include algorithms, connection labels, and key lengths. (Since the "Phase I ATM Security Specification" is currently a working draft, the IE formats are not described in this article. For more information, the reader is advised to consult [5]).
In-Band Security Messaging -- As stated earlier, a potential problem with exchanging security messages in the signaling channel is backward compatibility. In order for such messages to be successfully exchanged, the security IEs must be passed transparently by all network devices that process the message in which the IEs reside. In older networks, such IEs may be unrecognized and dropped.
As a solution to this problem, the Security Working Group has defined an "in-band" security messaging protocol which exchanges the security IEs in the user data channel immediately after it is established and before user data traffic begins. This protocol specifies that once the connection is established (through either signaling for SVCs or management for PVCs), the security agents block user data traffic and exchange security messages. These messages are formatted as user-network interface (UNI) signaling messages, but transmitted in the user data VCC/VPC. Once the security protocol completes, the security agents unblock the user data traffic, and communication (under the established security parameters) begins [5, 15].

Security Messaging During Connection Lifetime

Once a data connection is established, a mechanism for exchanging security messages is required to maintain cryptographic synchronization and perform session key update. Since these messages are time-sensitive with respect to the data traffic, they must be transmitted in the same VCC/VPC as the data to which they pertain. Otherwise, for example, a resynchronization message may arrive too late, leaving the decryption process out of synchronization.
The approach adopted by the Security Working Group uses an OAM cell to carry security-related information. This OAM cell may be either an F4 (VPC level) or F5 (VCC level) OAM cell, and as such can quickly be identified by the receiving end system or security agent. In either case, the OAM cell type is "system management," with appropriate "function types" defined to indicate security functions [2].

Summary

ATM security will provide protection for both user information as well as network infrastructure. ATM security is modeled after the ATM protocol reference model, which is divided into three planes: user, control, and management. Phase one of the ATM Forum security specification deals mainly with security services for the user plane and limited services for the control plane.
The ATM user plane security services provide protection for user information carried within virtual circuits in a number of ways. The access control service enforces what is allowed to access ATM-connected services and assets. The authentication service ensures that the identities of the calling and called parties are indeed genuine. The confidentiality service provides cryptographic mechanisms to protect user information carried over ATM connections from unauthorized disclosure. The integrity service guarantees that modifications to user data values or sequences of user data values will be detected, even in the presence of active malicious threats.
In addition, the ATM control plane security service provides strong signaling message authentication. This mechanism allows ATM control plane entities to verify the source and contents of a signaling message before acting on it, thereby protecting the network infrastructure from a number of attacks, including denial-of-service attacks.

References
 [1] L. Pierson, et al., "Threat-Asset Analysis for ATM," ATM Forum/96-0229, Feb. 1996.
[2] M. Peyravian et al., "ATM Security Scope and Requirements," ATM Forum/95-0579, June 1995.
[3] C. Kubic et al., "Proposed Framework for ATM Security Services," ATM Forum/95-0783, June 1995.
[4] M. Lazer, "Framework for Developing Security-Related Signaling Standards," ATM Forum/95-0408, Apr. 1995.
[5] ATM Forum/BTD-SECURITY-01.02, "Phase 1 ATM Security Specification (Draft)," Feb. 1997.
[6] T. Tarman et al. "Mechanism for Control Plane Authentication," ATM Forum/96-0368, Apr. 1996.
[7] M. Peyravian et al., "Signaling-Based Exchange of User Plane Security Messages," ATM Forum/96-1021, Aug. 1996.
[8] M. Peyravian et al., "Certificate-Based Public Key Exchange," ATM Forum/96-0380, Apr. 1996.
[9] D. Schnackenberg, "A Proposed Label-Based Access Control Information Element," ATM Forum/96-0129, Jan. 1996.
[10] M. Peyravian et al., "User Plane Data Integrity Mechanism," ATM Forum/96-1020, June 1996.
[11] L. G. Pierson, "Integrating End-to-End Encryption and Authentication Technology into Broadband Networks," Proc. Photonics East '95: SPIE Int'l. Symp. Info., Commun., and Comp. Technologies, Oct. 1995.
[12] B. Schneier, Applied Cryptography, 2nd edition, New York: John Wiley & Sons, 1996.
[13] M. Peyravian et al., "UNI Signaling Additions to Support User Plane Security Capabilities," ATM Forum/96-1019, June 1996.
[14] M. Peyravian et al., "Point-to-Multipoint Signaling Support for User Plane Security," ATM Forum/96-1245, Oct. 1996.
[15] E. Salans et al., "In-Band Exchange of User Plane Security Messages," ATM Forum/96-1050, Aug. 1996.

Additional Reading
[1] D. Stevenson et al., "Secure Communications in ATM Networks," Commun. ACM, vol. 38, no. 2, Feb. 1995.

Biographies
 Mohammad Peyravian [M] is a senior scientist at IBM, Research Triangle Park, North Carolina, where he is involved with protocol and algorithm design for high-speed networking technologies. He received B.S. and M.S. degrees from the University of Miami and a Ph.D. degree from the Georgia Institute of Technology in electrical engineering in 1987, 1989, and 1992, respectively. He does research in the areas of networking, telecommunications, and cryptography. Dr. Peyravian has published papers extensively in various journals and proceedings. He has received several IBM invention and technical achievement awards. Dr. Peyravian is the founder and chairman of the ATM Forum Security Working Group.
Thomas Tarman is a Senior Member of Technical Staff with Sandia National Laboratories, Albuquerque, New Mexico. Since joining Sandia in 1989, he has worked on the development of mobile command and control centers using commercial, off-the-shelf products and standards. More recently, his interests have focused on security issues for ATM networks, and he has been an active contributor and editor for the Security Working Group since its inception in June 1995. Mr. Tarman received a B.S. degree in computer and electrical engineering (with highest distinction) from Purdue University in 1988, and a Master's degree in electrical engineering from Purdue University in 1989.