Showing papers on "IPsec published in 1997"

IMAP/POP AUTHorize Extension for Simple Challenge/Response

Abstract: While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access. This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.

RSVP Extensions for IPSEC Data Flows

Abstract: This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6.

Implementing IPsec

Abstract: The IP security protocols are sufficiently mature to benefit from multiple independent implementations and worldwide deployment. Towards that goal, we implemented the protocols for the BSD/OS, Linux, OpenBSD and NetBSD. While some differences in the implementations exist due to the differences in the underlying operating system structures, the design philosophy is common. A radix tree, namely the one used by the BSD code for routing purposes, is used to implement the policy engine; a transform table switch is used to make addition of security transformations an easy process; a lightweight kernel-user communication mechanism is used to pass key material and other configuration information from user space to kernel space, and to report asynchronous events such as requests for new keys from the kernel space to a user-level keying daemon; and two distinct ways of intercepting outgoing packets and applying the IPsec transformations to them are employed. The techniques used in our implementations are explained, differences in approaches are analysed, and hints are given to potential future implementers of new transforms.

Probable plaintext cryptanalysis of the IP security protocols

Abstract: The Internet Engineering Task Force (IETF) is in the process of adopting standards for IP-layer encryption and authentication (IPSEC). We describe how "probable plaintext" can be used to aid in cryptanalytic attacks, and analyze the protocol to show how much probable plaintext is available. We also show how traffic analysis is a powerful aid to the cryptanalyst. We conclude by outlining some likely changes to the underlying protocols that may strengthen them against these attacks.

TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security

Abstract: From the Publisher: When it comes to teaching computer professionals how to plan for,use,operate,and maintain a TCP/IP network and associated services,Dr Sidnie Feit literally "wrote the book " Now,fully updated,her widely used book covers the most significant changes in the field including; Next Generation Internet Protocol,better known as IPng or IPv6 A dramatic new development designed to meet the surging demand for address space created by the e-mail explosion,Internet growth,and the implementation of client/server computing,IPng will change the way DP managers,network planners,and Internet Administrators enhance and extend their networking capabilities The author helps readers determine what impact TCP/IP will have on their existing environments-and what they must do now to coexist or migrate smoothly to the new technology

Software-Defined Networking (SDN)-based IPsec Flow Protection

Abstract: This document describes the use case of providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka Security Controller) and establishes the requirements to support this service It considers two main well-known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-host This document describes a mechanism based on the SDN paradigm to support the distribution and monitoring of IPsec information from a SDN controller to one or several flow-based Network Security Function (NSF) The NSFs implement IPsec to protect data traffic between network resources with IPsec The document focuses in the NSF Facing Interface by providing models for Configuration and State data model required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE to establish security associations with a reduced intervention of the network administrator NOTE: State data model will be developed as part of this work but it is still TBD

A Simple IP Security API Extension to BSD Sockets

Abstract: In order to take advantage of the IP Security Architecture [Atk95], an application should be able to tell the system what IP-layer security services it needs to function with some degree of confidence. A simple API that also allows simple security association policy to be set is presented here. This document descends from earlier work performed in the U. S. Naval Research Laboratory's IPv6 and IP security implementation [AMPMC96].

Security for ATM networks

Abstract: This paper addresses the design and management of security services for ATM networks. Various options for the positioning of security services within the ATM protocol stack are discussed. After considering these possibilities, it is proposed to place the security layer between the AAL and ATM layers. The proposed security layer provides confidentiality, integrity and data origin authentication in the user plane. The paper then presents an authentication scheme and a key establishment protocol. This protocol is integrated with the existing ATM signaling protocol, as part of the call setup procedures. The developed security design can be transparently integrated into the B-ISDN protocol reference model without violating the existing standards.

Labeled IPsec Traffic Selector support for IKEv2

Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9.

Internet Security Protocols

Abstract: This article describes various efforts to address security in three areas of the Internet protocol suite: the Internet Protocol itself (IPsec), the domain between transport and application layer (the Secure Sockets Layer and the Transport Layer Security protocols) and security extensions for the HyperText Transfer Protocol (S-HTTP). For each area the current technology, relevant standardization activities and likely future developments are discussed. In addition, a brief introduction to the Internet standardization process is given.