Internet DRAFT - draft-ietf-moskowitz-auth-dss
draft-ietf-moskowitz-auth-dss
R. Moskowitz, ICSA, Inc.
Internet Draft
Document: <draft-ietf-moskowitz-auth-dss-00.txt> 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
