| Related sites for http://www.faqs.org/rfcs/rfc1852.html |
| Sannella,_Donald University of Edinburgh - Functional languages, algebraic specification languages, mechanised reasoning, foundations for algebraic specification and formal software development. | | Martin_Laine__1_Pixel_Out News, articles, tutorials, downloads, opinions and general thoughts on ColdFusion, Mach-II, Fusebox, Web Standards and other web things. | | 1_On_1_Consulting Offers implementation, training and support of Platinum accounting software. | | Dynamx_Presentation_Systems Supplier of quality LCD and DLP projectors for sale and rental. | | RFC_1126 Goals and Functional Requirements for Inter-Autonomous System Routing. M. Little. October 1989. | | Nomadic_Studio Offers managed internet solutions compliant with Section 508. Includes services offeres, information about the regulations and associated news and links. | | RFC_2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. August 2001. | | Anjuta__Integrated_Development_Environment Anjuta is a very versatile Integrated development environment for c and c++ (Linux). Written in gtk/gnome and written for gtk/gnome, it features many advanced programming tools and utilities. It is a | | Computer_and_Communications Collection of computer and communications businesses on the Internet. The directory is maintained by staff at the University of California's Lawrence Livermores National Laboratory. | | Comparison_of_Oberon-2_with_Modula-2 Short text summary of main features of Oberon-2; target audience: Modula-2 programmers unfamiliar with Oberon-2, but familiar with object-oriented and extensible programming concepts. | | Frogland_Wallpapers Several really "frogish" wallpapers. | | JavaBeat Java certification resources. | | TrimURL_com Trim your long URL's. | | LawsonTalk Discussion forum with areas for general, functional, upgrade, technical, and employment topics. | | Michael_A__Golub Macros and russification for KEDIT and THE. | | Otolo_Web_Solutions Includes web design, database integration, marketing, streaming media, Flash, and submission services. Located in Sydenham, London, United Kingdom. | | Why_FrontPage_sucks Let me count the ways. | | The_Main_Menu Utility that is ideal as a boot-up menu for computer novices who never will master DOS commands. | | Prophet_Systems_Innovations Digital audio software for the broadcast and entertainment industries, featuring state-of-the-art audio equipment, centralized management, and complex computer automation. | | Mashed_Life Password manager for online accounts. Optionally uses a USB device for safekeeping and portability. |
|
RFC 1852 (rfc1852) - IP Authentication using Keyed SHA@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc1852.txt | rfc1852.txt.pdfRFC 1852 - IP Authentication using Keyed SHASearch the Archives  Display RFC by number RFC1852 - IP Authentication using Keyed SHANetwork Working Group P. MetzgerRequest for Comments: 1852 PiermontCategory: Experimental W. Simpson Daydreamer September 1995 IP Authentication using Keyed SHAStatus 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 ............................................. 61. 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, 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 avoid the physical copy in some implementations. The trailing copy of the key is not necessary to protect against appending attacks, as the IP datagram already includes a total length field. It reintroduces mixing of the entire key, providing minimal protection for very long and very short datagrams, and marginal robustness against possible attacks on the IP length field itself. 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 SHA 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. The SHA algorithm was originally derived from the MD4 algorithm [RFC-1320]. A flaw was apparently found in the original specification of SHA [FIPS-180], and this document specifies the use of a corrected version [FIPS-180-1]. At the time of writing of this document, there are no known flaws in the SHA algorithm. That is, there are no known attacks on SHA or any of its components that are better than brute force, and the 160-bit hash output by SHA is substantially more resistant to brute force attacks than the 128-bit hash size of MD4 and MD5. However, as the flaw in the original SHA algorithm shows, cryptographers are fallible, and there may be substantial deficiencies yet to be discovered in the algorithm.Acknowledgements Some of the text of this specification was derived from work by Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. Preliminary performance analysis was provided by Joe Touch. Comments should be submitted to the ipsec@ans.net mailing list.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. [FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993. Also known as: 58 Fed Reg 27712 (1993). [FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995. Also known as: 59 Fed Reg 35317 (1994). [RFC-1320] Ronald Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 1992. [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC-1825, Naval Research Laboratory, July 1995. [RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval Research Laboratory, July 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 Comments about this RFC:RFC 1852: Can I get on more information about the Programming of RFC 1852 ? by Mahmoud Maqableh - M5vip Balila (1/2/2006)RFC 1852: I would like learn more about the SHA-1 programming by Mahmoud Maqableh - M5vip (12/31/2005) Previous: RFC 1851 - The ESP Triple DES Transform Next: RFC 1853 - IP in IP Tunneling [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. |
|
