Security Architecture for the Internet Protocol
RFC 1825
Document | Type |
RFC - Proposed Standard
(August 1995; No errata)
Obsoleted by RFC 2401
|
|
---|---|---|---|
Author | Randall Atkinson | ||
Last updated | 2013-03-02 | ||
Replaces | draft-ietf-ipngwg-sec | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1825 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Atkinson Request for Comments: 1825 Naval Research Laboratory Category: Standards Track August 1995 Security Architecture for the Internet Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 1. INTRODUCTION This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. This document also describes key management requirements for systems implementing those security mechanisms. This document is not an overall Security Architecture for the Internet and is instead focused on IP-layer security. 1.1 Technical Definitions This section provides a few basic definitions that are applicable to this document. Other documents provide more definitions and background information [VK83, HA94]. Authentication The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. Integrity The property of ensuring that data is transmitted from source to destination without undetected alteration. Confidentiality The property of communicating such that the intended recipients know what was being sent but unintended parties cannot determine what was sent. Encryption A mechanism commonly used to provide confidentiality. Atkinson Standards Track [Page 1] RFC 1825 Security Architecture for IP August 1995 Non-repudiation The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data. SPI Acronym for "Security Parameters Index". An unstructured opaque index which is used in conjunction with the Destination Address to identify a particular Security Association. Security Association The set of security information relating to a given network connection or set of connections. This is described in detail below. Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, Flow Identifiers used, etc. [Sch94]. 1.2 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Atkinson Standards Track [Page 2] RFC 1825 Security Architecture for IP August 1995 1.3 Typical Use There are two specific headers that are used to provide security services in IPv4 and IPv6. These headers are the "IP Authentication Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload (ESP)" [Atk95b] header. There are a number of ways in which these IP security mechanisms might be used. This section describes some of the more likely uses. These descriptions are not complete or exhaustive. Other uses can also be envisioned. The IP Authentication Header is designed to provide integrity and authentication without confidentiality to IP datagrams. The lack of confidentiality ensures that implementations of the Authentication Header will be widely available on the Internet, even in locations where the export, import, or use of encryption to provide confidentiality is regulated. The Authentication Header supportsShow full document text