Internet DRAFT - draft-ietf-ipsec-ah
draft-ietf-ipsec-ah
Network Working Group P Metzger
Internet Draft W A Simpson
expires in six months January 1995
IPv4 Authentication Header (4AH)
draft-ietf-ipsec-ah-00.txt
Status of this Memo
This document is a submission to the IP Security Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipsec@ans.net mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Abstract
This document describes an authentication mechanism for IPv4, by
inserting an intervening header between the IPv4 Header and any
transport headers.
Troublemakers expires in six months [Page 1]
DRAFT 4AH January 1995
1. Introduction
The Authentication Header (AH) seeks to provide integrity and
authentication for IP datagrams. It may also provide non-
repudiation, depending on which algorithm is used.
Users desiring confidentiality should consider using the
Encapsulating Security Protocol (ESP) [RAesp], either in lieu of or
in conjunction with the Authentication Header.
This document assumes that the reader is familiar with the related
document "IPv4 Security Overview" [RAsa], which defines the overall
security plan for IPv4, and provides important background for this
specification.
1.1. Overview
The Authentication Header (AH) seeks to provide security by adding
authentication information to an IP datagram. The authentication
information is calculated using all of the fields in the IP datagram
which do not change in transit. This includes portions of the IP
Header, transport headers, and the user data.
In order for the Authentication Header to work properly without
changing the entire Internet infrastructure (particularly non-
participating routers), the authentication data is carried in its own
IP protocol payload. Nodes that aren't participating in the
authentication ignore the Authentication Header.
In some environments, intermediate routing authentication might be
desirable [RFC-1636]. If an asymmetric authentication algorithm is
used, then the routers performing such intermediate authentication
would need to be aware of the appropriate public keys and
authentication algorithm. The routers could authenticate the traffic
being handled, without being able to forge or modify otherwise
legitimate traffic.
If a symmetric authentication algorithm is used, then the routers
performing such intermediate authentication would need to be provided
with the appropriate keys. Possession of those keys would permit any
one of those systems to forge traffic claiming to be from the
legitimate sender to the legitimate receiver, or to modify the
contents of otherwise legitimate traffic.
Use of this specification will increase the protocol processing costs
in participating systems, and will also increase the communications
Troublemakers expires in six months [Page 1]
DRAFT 4AH January 1995
latency. The increased latency is primarily due to time required for
calculation of the authentication data by the sender, and the
calculation and comparison of the authentication data by the
receiver, over each datagram containing an Authentication Header.
The impact will vary with authentication algorithm used and other
factors, but is expected to be relatively inexpensive to implement.
1.2. Key Management
Key management is an important part of the IP security architecture.
A scalable standard Internet key management protocol is needed to
make widespread use of authentication practical.
However, in order to facilitate early adoption, manual key management
is the only key management technique required by this specification.
The only coupling between key management and the AH is the Security
Association Identifier (SAID), which is described in more detail
later. This permits several different key management mechanisms to
be used.
More importantly, it permits the key management protocol to be
changed or corrected without unduly impacting the security protocol
implementations. Thus, key management is specified in a separate
specification [TBD].
Nota Bene: It is intended that the key management mechanisms being
developed in other IETF Working Groups will be useful for both
IPv4 and IPv6.
1.3. Security Associations
The key management mechanism is used to negotiate a number of
parameters for each Security Association between the communicating
parties. This includes the key(s) used to generate the
authentication data, and also other parameters (such as the
authentication algorithm and mode).
The key management protocol implementation usually maintains a table
containing the several parameters for each current Security
Association. The AH implementation needs to access that security
parameter table to determine how to process each datagram.
The Security Association Identifier (SAID) is assigned by the entity
Troublemakers expires in six months [Page 2]
DRAFT 4AH January 1995
controlling the Destination IP address of the Security Association.
The selection mechanism used for the SAID is implementation
dependent.
A given Destination is not necessarily in control of the
negotiation process. In the case of multicast groups, a single
node or cooperating subset of the multicast group may work on
behalf of the entire group to set up a Security Association.
A session between two nodes will normally have two SAID values (one
in each direction). The nodes use the combination of SAID and IP
Destination to distinguish the correct association.
Senders to a multicast group may share a common Security Association,
if all communications are authenticated using the same security
configuration parameters. In this case, the receiver only knows that
the message came from a node knowing the Security Association for the
group, and cannot authenticate which member of the group sent the
datagram when symmetric algorithms are in use.
Multicast groups may also use a separate Security Association value
for each Source. If each sender is keyed separately and asymmetric
algorithms are used, data origin authentication is also provided.
1.4. Mechanisms
It is intended that the AH format should be sufficiently general to
permit the specification of new mechanisms as new cryptographic
algorithms are developed.
Each SAID value indicates the algorithm and mode used, the block size
(if any) of the algorithm, and the presence/absence and size of a
cryptographic synchronization or initialization vector field. These
parameters are described in companion mechanism documents.
The authentication mechanism uses a message digest algorithm (such as
MD5), either encrypting that message digest or keying the message
digest directly. Because conventional checksums (such as CRC-16) are
not cryptographically strong and can be easily reversed, they MUST
NOT be used with the Authentication Header.
Troublemakers expires in six months [Page 3]
DRAFT 4AH January 1995
2. Payload Format
The Authentication Header (AH) may appear after any other headers
which are examined at each hop, and before any other headers which
are not examined at an intermediate hop. The header immediately
preceding the Authentication Header will always contain the value
<TBD> in its Next Header (Protocol) field.
+-----------+-----------------+-----------+---------+-----------+
| IP Header | Routing/Hop-Hop | Auth Head | End-End | Transport |
+-----------+-----------------+-----------+---------+-----------+
2.1. Header Fields
A more detailed diagram of the Authentication Header follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Identifier (SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
Identifies the next header after the Authentication Header, using
the IP Protocol/Payload value. Up-to-date values of the IP
Protocol/Payload are specified in the most recent "Assigned
Numbers" [RFC-1700].
Length
The length of the Authentication Data field in 64-bit increments.
Minimum value is 0, which is only used in the degenerate case of a
"null" authentication algorithm.
Security Association Identifier (SAID)
A value identifying the Security Association for this datagram.
If no Security Association has been established, the value of this
field is zero.
Troublemakers expires in six months [Page 4]
DRAFT 4AH January 1995
SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are
reserved for future use.
Authentication Data
The length of this field is variable, but is always an integral
number of 64-bits.
An implementation will normally use the SAID to determine the
field's size and use. It retains the same format for all
datagrams of any given SAID and IP Destination.
The Authentication Data fills the field beginning immediately
after the SAID field. If the field is longer than necessary to
store the actual authentication data, then the unused bit
positions MUST be ignored by the receiver. Each mechanism will
have such special processing instructions included in its
specification.
Refer to each Authentication Mechanism specification for more
information regarding the contents of this field.
3. Processing
This chapter describes the steps taken when the AH is in use between
two communicating parties.
The sender first determines if a Security Association has been
established with the target Destination. If not, then the key
management mechanism is used to establish the SAID for this
communications session prior to the use of the AH.
If an unauthenticated datagram arrives from a Source after a SAID has
been established, or a SAID is received which is not valid, then an
error is indicated. The datagram is discarded, and an appropriate
ICMP message is returned. The failure SHOULD be recorded in the
system or audit log, including the cleartext values for the SAID,
date/time, Source, Destination, and other identifying information.
Multicast is different from unicast only in the area of key
management.
Troublemakers expires in six months [Page 5]
DRAFT 4AH January 1995
3.1. Calculation
The Authentication Data is the output of the authentication algorithm
calculated over the invariant portions of the entire IPv4 datagram.
The sender places this algorithm output into the Authentication Data
field within the Authentication Header.
When a keyed message digest algorithm is used (such as MD5), the
secret key is fed into the algorithm first, followed by the invariant
fields of the IP datagram in sequence.
The secret key is fed in first, because that increases the work
function for someone attempting to cryptanalyse the key from
knowledge of the plaintext datagram. Feeding the secret key in
first also permits implementations to precompute the start of the
hash for a given destination, and possibly improve performance
thereby.
The key does not need to be fed in at the end. Including the IP
Header's invariant Total Length field in the authentication
calculation precludes appending attacks.
Fields which will necessarily vary in transit from the sender to the
receiver (such as the Hop Count), are included in the calculation,
but the value zero is substituted for the actual value of such
fields.
The Authentication Data field itself is also zeroed during the
calculation. All other Authentication Header fields are included.
This substitution of zero is used instead of omitting those
fields, because it preserves alignment of the data during
calculation, which can significantly improve performance.
If a block-oriented authentication algorithm is in use (such as MD2,
MD4, MD5), and the IP datagram is not an integral number of blocks,
the authentication data calculation is performed using zero bytes at
the end of the datagram to pad the length out to an integral number
of blocks.
These block padding bytes are not included in the actual IP
datagram, and are not sent over the link. Adding padding at that
point in protocol processing could make implementation of MTU
related calculations very difficult.
The sender MUST compute the calculation over the datagram as it will
appear at the receiver. This requirement allows for future
intervening headers which are removed or altered during transit. The
Troublemakers expires in six months [Page 6]
DRAFT 4AH January 1995
sender needs to know the final values when including such headers in
the datagram. Each such header will have special processing
instructions included in its specification.
Upon receipt of a datagram containing an Authentication Header, the
receiver independently calculates the authentication data. It
compares the received Authentication Data field contents with the
calculated authentication value.
If they differ, then the receiver SHOULD discard the received IP
datagram, and return an appropriate ICMP message. The failure MUST
be recorded in the system or audit log, as described earlier.
Security Considerations
This specification is principly concerned with a security mechanism
for use with IP. This mechanism is not a panacea, but it does
provide an important component useful in creating a secure
internetwork.
Users need to understand that the quality of the security provided by
this specification depends completely on the strength of whichever
cryptographic algorithm that has been implemented, the correctness of
that algorithm's implementation, the security of the key management
mechanism and its implementation, the strength of the key [CN94], and
upon the correctness of the implementations in all of the
participating systems.
If any of these assumptions do not hold, then little or no real
security will be provided to the user. Implementers are encouraged
to use high assurance development techniques to develop all of the
security relevant parts of their products.
Acknowledgements
The original text of this specification was derived from work by Ran
Atkinson for the SIP, SIPP, and IPv6 Working Groups.
The basic concept is derived in large part from the work done for
SNMPv2 [RFC-1446].
Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic
provided useful critiques of earlier versions of this draft.
Troublemakers expires in six months [Page 7]
DRAFT 4AH January 1995
References
[CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
253-280, July 1994.
[RAsa] Randall Atkinson, IPv6 Security Architecture, work in
progress, 4 November 1994.
[RAesp] Randall Atkinson, IPv6 Encapsulating Security Payload, work
in progress, 4 November 1994.
[RFC-1446]
James Galvin & Keith McCloghrie, Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2), RFC-1446, DDN Network Information Center, April
1993.
[RFC-1636]
R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of
IAB Workshop on Security in the Internet Architecture",
RFC-1636, DDN Network Information Center, 9 June 1994, pp.
21-34.
[RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[Bell89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol.
19, No. 2, March 1989.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
Author's Address
Questions about this memo can also be directed to:
Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington,
DC 20375-5320
USA
Troublemakers expires in six months [Page 8]
DRAFT 4AH January 1995
Telephone: (DSN) 354-8590
Fax: (DSN) 354-7942
<atkinson@itd.nrl.navy.mil>
Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY 10033
perry@piermont.com
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Troublemakers expires in six months [Page 9]
DRAFT 4AH January 1995
Table of Contents
1. Introduction .......................................... 1
1.1 Overview ........................................ 1
1.2 Key Management .................................. 2
1.3 Security Associations ........................... 2
1.4 Mechanisms ...................................... 3
2. Payload Format ........................................ 4
2.1 Header Fields ................................... 4
3. Processing ............................................ 5
3.1 Calculation ..................................... 6
SECURITY CONSIDERATIONS ...................................... 7
ACKNOWLEDGEMENTS ............................................. 7
REFERENCES ................................................... 8
AUTHOR'S ADDRESS ............................................. 8
