summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1828.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1828.txt')
-rw-r--r--doc/rfc/rfc1828.txt335
1 files changed, 335 insertions, 0 deletions
diff --git a/doc/rfc/rfc1828.txt b/doc/rfc/rfc1828.txt
new file mode 100644
index 0000000..4ece5d5
--- /dev/null
+++ b/doc/rfc/rfc1828.txt
@@ -0,0 +1,335 @@
+
+
+
+
+
+
+Network Working Group P. Metzger
+Request for Comments: 1828 Piermont
+Category: Standards Track W. Simpson
+ Daydreamer
+ August 1995
+
+
+ IP Authentication using Keyed MD5
+
+
+
+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.
+
+
+Abstract
+
+ This document describes the use of keyed MD5 with the IP
+ Authentication Header.
+
+
+Table of Contents
+
+ 1. Introduction .......................................... 1
+ 1.1 Keys ............................................ 1
+ 1.2 Data Size ....................................... 1
+ 1.3 Performance ..................................... 1
+
+ 2. Calculation ........................................... 2
+
+ SECURITY CONSIDERATIONS ...................................... 2
+ ACKNOWLEDGEMENTS ............................................. 3
+ REFERENCES ................................................... 3
+ AUTHOR'S ADDRESS ............................................. 4
+
+
+
+
+
+
+
+
+
+
+
+
+Metzger & Simpson Standards Track [Page i]
+
+RFC 1828 AH MD5 August 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 Message Digest 5 (MD5) [RFC-1321].
+
+ All implementations that claim conformance or compliance with the
+ Authentication Header specification MUST implement this keyed MD5
+ mechanism.
+
+ 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 128 bits MUST be supported by the
+ implementation, although any particular key may be shorter. Longer
+ keys are encouraged.
+
+
+
+1.2. Data Size
+
+ MD5's 128-bit output is naturally 64-bit aligned. Typically, there
+ is no further padding of the Authentication Data field.
+
+
+
+1.3. Performance
+
+ MD5 software speeds are adequate for commonly deployed LAN and WAN
+ links, but reportedly are too slow for newer link technologies [RFC-
+ 1810].
+
+ Nota Bene:
+ Suggestions are sought on alternative authentication algorithms
+ that have significantly faster throughput, are not patent-
+ encumbered, and still retain adequate cryptographic strength.
+
+
+
+Metzger & Simpson Standards Track [Page 1]
+
+RFC 1828 AH MD5 August 1995
+
+
+2. Calculation
+
+ The 128-bit digest is calculated as described in [RFC-1321]. The
+ specification of MD5 includes a portable 'C' programming language
+ description of the MD5 algorithm.
+
+ The form of the authenticated message is
+
+ key, keyfill, datagram, key, MD5fill
+
+ First, the variable length secret authentication key is filled to the
+ next 512-bit boundary, using the same pad with length technique
+ defined for MD5.
+
+ 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 MD5 itself. The 128-bit MD5 digest is
+ calculated, and the result is inserted into the Authentication Data
+ field.
+
+ Discussion:
+ When the implementation adds the keys and padding in place before
+ and after the IP datagram, care must be taken that the keys and/or
+ padding are not sent over the link by the link driver.
+
+
+
+Security Considerations
+
+ Users need to understand that the quality of the security provided by
+ this specification depends completely on the strength of the MD5 hash
+ function, 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 nodes.
+
+ At the time of writing of this document, it is known to be possible
+ to produce collisions in the compression function of MD5 [dBB93].
+ There is not yet a known method to exploit these collisions to attack
+ MD5 in practice, but this fact is disturbing to some authors
+ [Schneier94].
+
+ It has also recently been determined [vOW94] that it is possible to
+ build a machine for $10 Million that could find two chosen text
+
+
+
+Metzger & Simpson Standards Track [Page 2]
+
+RFC 1828 AH MD5 August 1995
+
+
+ variants with a common MD5 hash value. However, it is unclear
+ whether this attack is applicable to a keyed MD5 transform.
+
+ This attack requires approximately 24 days. The same form of attack
+ is useful on any iterated n-bit hash function, and the time is
+ entirely due to the 128-bit length of the MD5 hash.
+
+ Although there is no substantial weakness for most IP security
+ applications, it should be recognized that current technology is
+ catching up to the 128-bit hash length used by MD5. Applications
+ requiring extremely high levels of security may wish to move in the
+ near future to algorithms with longer hash lengths.
+
+
+
+Acknowledgements
+
+ This document was reviewed by the IP Security Working Group of the
+ Internet Engineering Task Force (IETF). Comments should be submitted
+ to the ipsec@ans.net mailing list.
+
+ Some of the text of this specification was derived from work by
+ Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
+
+ The basic concept and use of MD5 is derived in large part from the
+ work done for SNMPv2 [RFC-1446].
+
+ Steve Bellovin, Phil Karn, Charles Lynn, Dave Mihelcic, Hilarie
+ Orman, Jeffrey Schiller, Joe Touch, and David Wagner provided useful
+ critiques of earlier versions of this draft.
+
+
+
+References
+
+ [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
+ Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
+ 253-280, July 1994.
+
+ [dBB93] den Boer, B., and Bosselaers, A., "Collisions for the
+ Compression function of MD5", Advances in Cryptology --
+ Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994
+
+ [KR95] Kaliski, B., and Robshaw, M., "Message authentication with
+ MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1
+ no.1, Spring 1995.
+
+
+
+
+Metzger & Simpson Standards Track [Page 3]
+
+RFC 1828 AH MD5 August 1995
+
+
+ [RFC-1321]
+ Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ MIT and RSA Data Security, Inc., April 1992.
+
+ [RFC-1446]
+ Galvin, J., and K. McCloghrie, "Security Protocols for
+ Version 2 of the Simple Network Management Protocol
+ (SNMPv2)", RFC 1446, TIS, Hughes LAN Systems, April
+ 1993.
+
+ [RFC-1700]
+ Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+ RFC 1700, USC/Information Sciences Institute, October 1994.
+
+ [RFC-1800]
+ Postel, J., "Internet Official Protocol Standards", STD 1,
+ RFC 1800, USC/Information Sciences Institute, July 1995.
+
+ [RFC-1810]
+ Touch, J., "Report on MD5 Performance", RFC 1810,
+ USC/Information Sciences Institute, June 1995.
+
+ [RFC-1825]
+ Atkinson, R., "Security Architecture for the Internet
+ Protocol", RFC 1825, NRL, August 1995.
+
+ [RFC-1826]
+ Atkinson, R., "IP Authentication Header", RFC 1826, NRL
+ August 1995.
+
+ [Schneier94]
+ Schneier, B., "Applied Cryptography", John Wiley & Sons, New
+ York, NY, 1994. ISBN 0-471-59756-2
+
+ [vOW94] van Oorschot, P. C., and Wiener, M. J., "Parallel Collision
+ Search with Applications to Hash Functions and Discrete
+ Logarithms", Proceedings of the 2nd ACM Conf. Computer and
+ Communications Security, Fairfax, VA, November 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+Metzger & Simpson Standards Track [Page 4]
+
+RFC 1828 AH MD5 August 1995
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Metzger & Simpson Standards Track [Page 5]
+ \ No newline at end of file