R. Moskowitz, ICSA, Inc. Internet Draft Document: May 1999 The Use of DSS within ESP and AH Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This memo describes the use of DSS [FIPS-186] in as an authentication mechanism within the IPSEC Encapsulating Security Payload [ESP] and the IPSEC Authentication Header [AH]. DSS provides data origin authentication and integrity protection. DSS authenticated ESP or AH can be used with the Host Identity Payload [HIP99]. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Introduction This memo specifies the use of DSS [FIPS-186] as an authentication mechanism within the context of the Encapsulating Security Payload Moskowitz 1 The Use of DSS within ESP and AH May 1999 and the Authentication Header. The goal of DSS is to ensure that the packet is authentic and cannot be modified in transit. DSS uses SHA1 [FIPS-180-1] with DSA [DSA-1], a public key authentication algorithm to authenticate the message. In this memo, DSS is used within the context of ESP and AH. For further information on how the various pieces of ESP - including the confidentiality mechanism -- fit together to provide security services, refer to [ESP] and [Thayer97a]. For further information on AH, refer to [AH] and [Thayer97a]. For further information on how to use the Host Identity Payload to exchange the DSA public keys within the same datagram as the AH or ESP payload, refer to HIP [HIP99]. 4. Algorithm [FIPS-180-1] describes the underlying SHA1 algorithm, while [FIPS- 186] describes the DSA algorithm and the complete signing and validation process. DSS operates on 64-byte blocks of data. Padding requirements are specified in [FIPS-180-1] and are part of the SHA-1 algorithm. If you build SHA-1 according to [FIPS-180-1] you do not need to add any additional padding as far as DSS is concerned. With regard to "implicit packet padding" as defined in [AH] no implicit packet padding is required. The length of the authenticator value is based on the length of the DSA keys. Unlike HMAC-SHA-1-96 [HMAC-SHA-1-96], they MUST NOT be truncated. Thus the selection of the DSA parameters will directly impact the size of the AH or ESP payload. 5. Performance DSA is estimated to be 100 times slower than HMAC-SHA-1-96. Thus until fast hardware implementations for DSA are available, this auth mode is best suited to special cases like protocols that have very few packets. That is where the cost of establishing the HMAC keying material exceeds the cost of the DSA operations on each datagram. 6. Keying Material DSA is a public key algorithm. While no fixed key length is specified in [FIPS-186], a common length is 320 bits. Key lengths are defined in the DSA parameters. The method of establishing the DSA parameters are outside the bonds of this document. Moskowitz 2 The Use of DSS within ESP and AH May 1999 [FIPS-186] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudo- random function MUST be used to generate the required key. 7. Security Considerations Any implementation of the DSA requires the ability to generate random or pseudorandom integers. Such numbers are used to derive a user's private key, x, and a user's per message secret number, k. These randomly or pseudorandomly generated integers are selected to be between 0 and the 160- bit prime q (as specified in the standard). 8. IANA Considerations The IP Security Domain of Interpretation [DOI] defines the IPSEC Security Association Attributes in section 4.5. DSS represents a new Authentication Algorithm. IANA will assign a value of [N] for DSS. 9. References [ESP], Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [AH], Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [FIPS-186], US National Bureau of Standards, "Digital Signature Standard (DSS)", Federal Information Processing Standard (FIPS) Publication 186, May 1994, http://www.itl.nist.gov/div897/pubs/fip186.htm. [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) http://csrc.nist.gov/fips/fip180-1.ps (postscript) [Thayer97a], Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [HMAC-SHA-1-96], Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998. [DOI], Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. 10. Acknowledgments Moskowitz 3 The Use of DSS within ESP and AH May 1999 This document is derived in part from HMAC-SHA-1-96 by Cheryl Madson and Rob Glenn. I would also like to thank Steve Bellovin, Baiju Patel, and Hilarie Orman for their comments and recommendations this document. 11. Author's Addresses Robert Moskowitz ICSA, Inc. 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net Moskowitz 4