IP Authentication using Keyed SHA
RFC 1852
Document | Type |
RFC - Experimental
(September 1995; No errata)
Obsoleted by RFC 2841
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1852 (Experimental) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group P. Metzger Request for Comments: 1852 Piermont Category: Experimental W. Simpson Daydreamer September 1995 IP Authentication using Keyed SHA Status of this Memo This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract This document describes the use of keyed SHA with the IP Authentication Header. Table of Contents 1. Introduction .......................................... 2 1.1 Keys ............................................ 2 1.2 Data Size ....................................... 2 1.3 Performance ..................................... 2 2. Calculation ........................................... 3 SECURITY CONSIDERATIONS ...................................... 4 ACKNOWLEDGEMENTS ............................................. 4 REFERENCES ................................................... 5 AUTHOR'S ADDRESS ............................................. 6 Metzger & Simpson Experimental [Page 1] RFC 1852 AH SHA September 1995 1. Introduction The Authentication Header (AH) [RFC-1826] provides integrity and authentication for IP datagrams. This specification describes the AH use of keys with the Secure Hash Algorithm (SHA) [FIPS-180-1]. It should be noted that this document specifies a newer version of the SHA than that described in [FIPS-180], which was flawed. The older version is not interoperable with the newer version. This document assumes that the reader is familiar with the related document "Security Architecture for the Internet Protocol" [RFC- 1825], which defines the overall security plan for IP, and provides important background for this specification. 1.1. Keys The secret authentication key shared between the communicating parties SHOULD be a cryptographically strong random number, not a guessable string of any sort. The shared key is not constrained by this transform to any particular size. Lengths of up to 160 bits MUST be supported by the implementation, although any particular key may be shorter. Longer keys are encouraged. 1.2. Data Size SHA's 160-bit output is naturally 32-bit aligned. However, many implementations require 64-bit alignment of the following headers, in which case an additional 32 bits of padding is added, either before or after the SHA output. The size and position of this padding are negotiated as part of the key management. Padding bits are filled with unspecified implementation dependent (random) values, which are ignored on receipt. 1.3. Performance Preliminary results indicate that SHA is 62% as fast as MD5, and 80% as fast as DES hashing. That is, Metzger & Simpson Experimental [Page 2] RFC 1852 AH SHA September 1995 SHA < DES < MD5 Nota Bene: Suggestions are sought on alternative authentication algorithms that have significantly faster throughput, are not patent- encumbered, and still retain adequate cryptographic strength. 2. Calculation The 160-bit digest is calculated as described in [FIPS-180-1]. At the time of writing, a portable C language implementation of SHA is available via FTP from ftp://rand.org/pub/jim/sha.tar.gz. The form of the authenticated message is key, keyfill, datagram, key, SHAfill First, the variable length secret authentication key is filled to the next 512-bit boundary, using the same pad with length technique defined for SHA. Then, the filled key is concatenated with (immediately followed by) the invariant fields of the entire IP datagram (variant fields are zeroed), concatenated with (immediately followed by) the original variable length key again. A trailing pad with length to the next 512-bit boundary for the entire message is added by SHA itself. The 160-bit SHA digest is calculated, and the result is inserted into the Authentication Data field. Discussion: The leading copy of the key is padded in order to facilitate copying of the key at machine boundaries without requiring re- alignment of the following datagram. The padding technique includes a length which protects arbitrary length keys. Filling to the SHA block size also allows the key to be prehashed to avoidShow full document text