Publications

As described in contribution AF99-0335, it is interesting that new security services and mechanisms are allowed to be negotiated during a connection in progress. To do that, new ''negotiation OAM cells'' dedicated to security should be defined, as well as some acknowledgment cells allowing negotiation OAM cells to be exchanged reliably. Remarks which were given at the New Orleans meeting regarding those cell formats are taken into account. This contribution presents some baseline text describing the format of the negotiation and acknowledgment cells, and the using of those cells. All the modifications brought to the specifications are reversible using the Word tools.

This contribution proposes strawman techniques for Security Service Discovery by ATM endsystems in ATM networks. Candidate techniques include ILMI extensions, ANS extensions and new ATM anycast addresses. Another option is a new protocol based on an IETF service discovery protocol, such as Service Location Protocol (SLP). Finally, this contribution provides strawman requirements for Security-Based Routing in ATM networks.

Abstract not provided.

The ATM Forum UNI 4.0 Security Addendum has undergone 4 revisions and has been without substantive modifications for 3 ATM Forurn meetings. This contribution is intended to assist the ATM Forum CS Working Group in the process of bringing BTD-CS-UNI-SEC-O1 .04 DIUFT to Straw Ballot. This effort applies equally to its companion documen~ BTD-CS-PNNI-SEC-O 1.02 DRAFT. BTD-CS-UNI-SEC-01 .04 DRAFT is an addendum to UNI 4.0 Signaling that describes the additional procedures needed of ATM signaling to support the signaling-based securily message exchange protocol, and its 4 basic security mechanisms, authentication, confidentiality, integrity and access control for ATM VC/VPs. These services are specified in detail in ATM Forurn document af-sec-0100.000, which is currently in Final Ballot. The remaining identified work for BTD-CS-UNI-SEC-01 .04 DRAFT includes the resolution of the TBD items in the draft, and a review of the sections of the ATM Forum Security Specification V 1.0 af-sec- 0100.000, that are specifically referenced by BTD-CS-UNI-SEC-O 1.04 DRAFT. In support of this effort, this contribution includes the relevant baseline text of the referenced sections of that Security Specification.

This contribution describes three interoperability scenarios for the ATM Security Message Exchange (SME) protocol. These scenarios include network-wide signaling support for the Security Services Information Element, partial signaling support wherethe SSIE is only supported in private or workgroup ATM networks, and the case where the SSIE is nonsupported by any network elements (exceptthosethat implement security services). Explanatory text is proposed for inclusion infection 2.3 of the ATM Security Specification, Version 1.0.

This contribution provides Sandia`s comments to the ATM Forum Security 1.0 straw ballot specification, STR-SECURITY-01.01. These comments are organized as follows--major comments indicate technical defects in the specification which, if not resolved, may preclude Sandia`s vote in favor of the specification. Minor comments are technical comments which, if left unresolved, will not preclude Sandia`s favorable vote. Finally, editorial comments are also provided.

This contribution proposes additional text for Section 7.1.5.5 of [1] which defines the contents of the digital signature buffer for each relevant flow in the Two-Way and Three-Way Security Message Exchange Protocols. This is clearly an interoperability issue because these signature buffers must be constructed identically at the sender (signature generator) and receiver (signature validator) in order for the protocols to proceed correctly. Sections 2 and 3 of this contribution are intended to be placed in Section 7.1.5.5 of [1]. In addition, text is proposed in Motion 2 of Section 4 of this contribution which clarifies the scope of encryption of the Confidential Section, which is defined in Section 7.1.4 of [1].

This document specifies signaling procedures required to support security services in the Phase I ATM Security Specification. These signaling procedures are in addition to those described in UNI 4.0 Signaling. When establishing point-to-point and point-to-multipoint calls, the call control procedures described in the ATM Forum UNI 4.0 Signaling apply. This document describes the additional information elements and procedures necessary to support security services. This description is in an incremental form with differences from the point-to-point and point-to-multipoint calls with respect to messages, information elements, and signaling procedures.

Asynchronous Transfer Mode (ATM) is a new data communications technology that promises to integrate voice, video, and data traffic into a common network infrastructure. In order to fully utilize ATM`s ability to transfer real-time data at high rates, applications will start to access the ATM layer directly. As a result of this trend, security mechanisms at the ATM layer will be required. A number of research programs are currently in progress which seek to better understand the unique issues associated with ATM security. This paper describes some of these issues, and the approaches taken by various organizations in the design of ATM layer security mechanisms. Efforts within the ATM Forum to address the user communities need for ATM security are also described.

The purpose of this contribution is to propose an ``Authentication Information Element`` that can be used to carry authentication information within the ATM signaling protocols. This information may be used by either signaling entity to validate the claimed identity of the other, and to verify the integrity of a portion of a message`s contents. By specifying a generic authentication IE, authentication information can be generated by any signature algorithm, and can be appended to any ATM signaling message. Procedures for the use of this information element are also provided.

This is the summary report for the Protocol Extensions for Asynchronous Transfer Mode project, funded under Sandia`s Laboratory Directed Research and Development program. During this one-year effort, techniques were examined for integrating security enhancements within standard ATM protocols, and mechanisms were developed to validate these techniques and to provide a basic set of ATM security assurances. Based on our experience during this project, recommendations were presented to the ATM Forum (a world-wide consortium of ATM product developers, service providers, and users) to assist with the development of security-related enhancements to their ATM specifications. As a result of this project, Sandia has taken a leading role in the formation of the ATM Forum`s Security Working Group, and has gained valuable alliances and leading-edge experience with emerging ATM security technologies and protocols.

This contribution addresses requirements for ATM signaling channel authentication. Signaling channel authentication is an ATM security service that binds an ATM signaling message to its source. By creating this binding, the message recipient, and even a third party, can confidently verify that the message originated from its claimed source. This provides a useful mechanism to mitigate a number of threats. For example, a denial of service attack which attempts to tear-down an active connection by surreptitiously injecting RELEASE or DROP PARTY messages could be easily thwarted when authenticity assurances are in place for the signaling channel. Signaling channel authentication could also be used to provide the required auditing information for accurate billing which is impervious to repudiation. Finally, depending on the signaling channel authentication mechanism, end-to-end integrity of the message (or at least part of it) can be provided. None of these capabilities exist in the current specifications.

This contribution proposes the format of the ``Algorithm-Specific Information`` and ``Signature`` fields within the ``Proposed Generic Authentication Information Element`` for authentication IEs based on the Digital Signature Standard (DSS). These fields are designed to allow various levels of authentication ``strength`` (or robustness), and many of these fields may be omitted in systems that optimize authentication performance by sharing common (public) Digital Signature Algorithm (DSA) parameters. This allows users and site security officers to design their authenticated signaling according to site security and performance requirements.

This contribution describes a proposed information element that can convey authentication information within an ATM signaling message. The design of this information element provides a large amount of flexibility to the user because it does not specify a particular signature algorithm, and it does not specify which information elements must accompany the Authentication IE in a signaling message. This allows the user to implement authenticated signaling based on her site`s security policies and performance requirements.

There has been some interest lately in the need for ``authenticated signalling``, and the development of signalling specifications by the ATM Forum that support this need. The purpose of this contribution is to show that if authenticated signalling is required, then supporting signalling facilities for directory services (i.e. key management) are also required. Furthermore, this contribution identifies other security related mechanisms that may also benefit from ATM-level signalling accommodations. For each of these mechanisms outlined here, an overview of the signalling issues and a rough cut at the required fields for supporting Information Elements are provided. Finally, since each of these security mechanisms are specified by a number of different standards, issues pertaining to the selection of a particular security mechanism at connection setup time (i.e. specification of a required ``Security Quality of Service``) are also discussed.

The design of a software package that provides a variety of Asynchronous Transfer Mode (ATM) test functions is presented here. These functions include cell capture, protocol decode for Transmission Control Protocol/Internet Protocol (TCP/IP) services, removal of cells (to support testing of an ATM system under cell loss conditions), and echo functions. This package is currently written to operate on the Sun Microsystems SPARCstation 10/SunOS 4.1.3 environment with a Fore Systems SBA-100 Sbus ATM adapter (140 Mbit/s TAXI interface), and the DEC 5000/240 running ULTRIX 4.2A with a Fore Systems TCA-100 TurboChannel adapter. Application scenarios and performance measurements of this software package on these host environments are presented here.