This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE). All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography. These groups and the associated test data are defined by NIST on

Abstract. There have been several attempts in the past to secure the Simple Network Management Protocol (SNMP). Version 3 of the SNMP protocol introduced a User-based Security Model (USM) which comes with its own user and key-management infrastructure. However, many operators are reluctant to introduce a new user and key management infrastructure just to secure SNMP. This paper describes how the Secure Shell (SSH) protocol can be used to secure SNMP and it provides a performance analysis of a prototype implementation which compares the performance of SNMP over SSH with other secure and insecure versions of SNMP. 1

the Grants No. (NSC95-main) and No. (NSC95-org), and by gifts from AMD and Intel.

Securing VoIP is a crucial requirement for its successful adoption. A key component of this is securing the signaling path, which is performed by SIP. Securing SIP is accomplished by using TLS instead of UDP as the transport protocol. However, using TLS for SIP is not yet widespread, perhaps due to concerns about the performance overhead. This paper studies the performance impact of using TLS as a transport protocol for SIP servers. We evaluate the cost of TLS experimentally using a testbed with OpenSIPS, OpenSSL, and Linux running on an Intel-based server. We analyze TLS costs using application, library, and kernel profiling, and use the profiles to illustrate when and how different costs are incurred, such as bulk data encryption, public key encryption, private key decryption, and MAC-based verification. We show that using TLS can reduce performance by up to a factor of 17 compared to the typical case of SIP-over-UDP. The primary factor in determining performance is whether and how TLS connection establishment is performed, due to the heavy costs of RSA operations used for session negotiation. This depends both on how the SIP proxy is deployed (e.g., as an inbound or outbound proxy) and what TLS options are used (e.g., mutual authentication, session reuse). The cost of symmetric key operations such as AES, in contrast, tends to be small.

Web sites fail in the worst ways. They can reveal private data that can never be retracted [60, 72, 78, 79]. Or they can succumb to vandalism, and subsequently show corrupt data to users [27]. Blame can fall on the off-the-shelf software that runs the site (e.g., the operating system, the application libraries, the Web server, etc.), but more frequently (as in the above references), the custom application code is the guilty party. Unfortunately, the custom code behind many Web sites is difficult to secure and audit, due to large and rapidly-changing trusted computing bases (TCBs). A promising approach to reducing TCBs for Web sites is decentralized information flow

Abstract not found

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the

The spread of wide-scale Internet surveillance has spurred interest in ano-nymity systems that protect users ’ privacy by restricting unauthorised access to their identity. This requirement can be considered as a flow control policy in the well established field of multilevel secure systems. I apply previous re-search on covert channels (unintended means to communicate in violation of a security policy) to analyse several anonymity systems in an innovative way. One application for anonymity systems is to prevent collusion in compe-titions. I show how covert channels may be exploited to violate these pro-tections and construct defences against such attacks, drawing from previous covert channel research and collusion-resistant voting systems. In the military context, for which multilevel secure systems were designed, covert channels are increasingly eliminated by physical separation of intercon-nected single-role computers. Prior work on the remaining network covert channels has been solely based on protocol specifications. I examine some pro-tocol implementations and show how the use of several covert channels can be

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI " mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to