340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group D. EastLake
|
|||
|
Request for Comments: 2536 IBM
|
|||
|
Category: Standards Track March 1999
|
|||
|
|
|||
|
|
|||
|
DSA KEYs and SIGs in the Domain Name System (DNS)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
A standard method for storing US Government Digital Signature
|
|||
|
Algorithm keys and signatures in the Domain Name System is described
|
|||
|
which utilizes DNS KEY and SIG resource records.
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
Abstract...................................................1
|
|||
|
1. Introduction............................................1
|
|||
|
2. DSA KEY Resource Records................................2
|
|||
|
3. DSA SIG Resource Records................................3
|
|||
|
4. Performance Considerations..............................3
|
|||
|
5. Security Considerations.................................4
|
|||
|
6. IANA Considerations.....................................4
|
|||
|
References.................................................5
|
|||
|
Author's Address...........................................5
|
|||
|
Full Copyright Statement...................................6
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The Domain Name System (DNS) is the global hierarchical replicated
|
|||
|
distributed database system for Internet addressing, mail proxy, and
|
|||
|
other information. The DNS has been extended to include digital
|
|||
|
signatures and cryptographic keys as described in [RFC 2535]. Thus
|
|||
|
the DNS can now be secured and can be used for secure key
|
|||
|
distribution.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 2536 DSA in the DNS March 1999
|
|||
|
|
|||
|
|
|||
|
This document describes how to store US Government Digital Signature
|
|||
|
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
|
|||
|
US Digital Signature Algorithm is assumed [Schneier]. Implementation
|
|||
|
of DSA is mandatory for DNS security.
|
|||
|
|
|||
|
2. DSA KEY Resource Records
|
|||
|
|
|||
|
DSA public keys are stored in the DNS as KEY RRs using algorithm
|
|||
|
number 3 [RFC 2535]. The structure of the algorithm specific portion
|
|||
|
of the RDATA part of this RR is as shown below. These fields, from Q
|
|||
|
through Y are the "public key" part of the DSA KEY RR.
|
|||
|
|
|||
|
The period of key validity is not in the KEY RR but is indicated by
|
|||
|
the SIG RR(s) which signs and authenticates the KEY RR(s) at that
|
|||
|
domain name.
|
|||
|
|
|||
|
Field Size
|
|||
|
----- ----
|
|||
|
T 1 octet
|
|||
|
Q 20 octets
|
|||
|
P 64 + T*8 octets
|
|||
|
G 64 + T*8 octets
|
|||
|
Y 64 + T*8 octets
|
|||
|
|
|||
|
As described in [FIPS 186] and [Schneier]: T is a key size parameter
|
|||
|
chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T
|
|||
|
octet is greater than 8 is reserved and the remainder of the RDATA
|
|||
|
portion may have a different format in that case.) Q is a prime
|
|||
|
number selected at key generation time such that 2**159 < Q < 2**160
|
|||
|
so Q is always 20 octets long and, as with all other fields, is
|
|||
|
stored in "big-endian" network order. P, G, and Y are calculated as
|
|||
|
directed by the FIPS 186 key generation algorithm [Schneier]. P is
|
|||
|
in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
|
|||
|
octets long. G and Y are quantities modulus P and so can be up to
|
|||
|
the same length as P and are allocated fixed size fields with the
|
|||
|
same number of octets as P.
|
|||
|
|
|||
|
During the key generation process, a random number X must be
|
|||
|
generated such that 1 <= X <= Q-1. X is the private key and is used
|
|||
|
in the final step of public key generation where Y is computed as
|
|||
|
|
|||
|
Y = G**X mod P
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 2536 DSA in the DNS March 1999
|
|||
|
|
|||
|
|
|||
|
3. DSA SIG Resource Records
|
|||
|
|
|||
|
The signature portion of the SIG RR RDATA area, when using the US
|
|||
|
Digital Signature Algorithm, is shown below with fields in the order
|
|||
|
they occur. See [RFC 2535] for fields in the SIG RR RDATA which
|
|||
|
precede the signature itself.
|
|||
|
|
|||
|
Field Size
|
|||
|
----- ----
|
|||
|
T 1 octet
|
|||
|
R 20 octets
|
|||
|
S 20 octets
|
|||
|
|
|||
|
The data signed is determined as specified in [RFC 2535]. Then the
|
|||
|
following steps are taken, as specified in [FIPS 186], where Q, P, G,
|
|||
|
and Y are as specified in the public key [Schneier]:
|
|||
|
|
|||
|
hash = SHA-1 ( data )
|
|||
|
|
|||
|
Generate a random K such that 0 < K < Q.
|
|||
|
|
|||
|
R = ( G**K mod P ) mod Q
|
|||
|
|
|||
|
S = ( K**(-1) * (hash + X*R) ) mod Q
|
|||
|
|
|||
|
Since Q is 160 bits long, R and S can not be larger than 20 octets,
|
|||
|
which is the space allocated.
|
|||
|
|
|||
|
T is copied from the public key. It is not logically necessary in
|
|||
|
the SIG but is present so that values of T > 8 can more conveniently
|
|||
|
be used as an escape for extended versions of DSA or other algorithms
|
|||
|
as later specified.
|
|||
|
|
|||
|
4. Performance Considerations
|
|||
|
|
|||
|
General signature generation speeds are roughly the same for RSA [RFC
|
|||
|
2537] and DSA. With sufficient pre-computation, signature generation
|
|||
|
with DSA is faster than RSA. Key generation is also faster for DSA.
|
|||
|
However, signature verification is an order of magnitude slower than
|
|||
|
RSA when the RSA public exponent is chosen to be small as is
|
|||
|
recommended for KEY RRs used in domain name system (DNS) data
|
|||
|
authentication.
|
|||
|
|
|||
|
Current DNS implementations are optimized for small transfers,
|
|||
|
typically less than 512 bytes including overhead. While larger
|
|||
|
transfers will perform correctly and work is underway to make larger
|
|||
|
transfers more efficient, it is still advisable at this time to make
|
|||
|
reasonable efforts to minimize the size of KEY RR sets stored within
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 2536 DSA in the DNS March 1999
|
|||
|
|
|||
|
|
|||
|
the DNS consistent with adequate security. Keep in mind that in a
|
|||
|
secure zone, at least one authenticating SIG RR will also be
|
|||
|
returned.
|
|||
|
|
|||
|
5. Security Considerations
|
|||
|
|
|||
|
Many of the general security consideration in [RFC 2535] apply. Keys
|
|||
|
retrieved from the DNS should not be trusted unless (1) they have
|
|||
|
been securely obtained from a secure resolver or independently
|
|||
|
verified by the user and (2) this secure resolver and secure
|
|||
|
obtainment or independent verification conform to security policies
|
|||
|
acceptable to the user. As with all cryptographic algorithms,
|
|||
|
evaluating the necessary strength of the key is essential and
|
|||
|
dependent on local policy.
|
|||
|
|
|||
|
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
|
|||
|
current DSA standard may limit the security of DSA. For particularly
|
|||
|
critical applications, implementors are encouraged to consider the
|
|||
|
range of available algorithms and key sizes.
|
|||
|
|
|||
|
DSA assumes the ability to frequently generate high quality random
|
|||
|
numbers. See [RFC 1750] for guidance. DSA is designed so that if
|
|||
|
manipulated rather than random numbers are used, very high bandwidth
|
|||
|
covert channels are possible. See [Schneier] and more recent
|
|||
|
research. The leakage of an entire DSA private key in only two DSA
|
|||
|
signatures has been demonstrated. DSA provides security only if
|
|||
|
trusted implementations, including trusted random number generation,
|
|||
|
are used.
|
|||
|
|
|||
|
6. IANA Considerations
|
|||
|
|
|||
|
Allocation of meaning to values of the T parameter that are not
|
|||
|
defined herein requires an IETF standards actions. It is intended
|
|||
|
that values unallocated herein be used to cover future extensions of
|
|||
|
the DSS standard.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 2536 DSA in the DNS March 1999
|
|||
|
|
|||
|
|
|||
|
References
|
|||
|
|
|||
|
[FIPS 186] U.S. Federal Information Processing Standard: Digital
|
|||
|
Signature Standard.
|
|||
|
|
|||
|
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
|
|||
|
Facilities", STD 13, RFC 1034, November 1987.
|
|||
|
|
|||
|
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
|
|||
|
Specification", STD 13, RFC 1035, November 1987.
|
|||
|
|
|||
|
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
|
|||
|
Recommendations for Security", RFC 1750, December 1994.
|
|||
|
|
|||
|
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
|
|||
|
RFC 2535, March 1999.
|
|||
|
|
|||
|
[RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
|
|||
|
System (DNS)", RFC 2537, March 1999.
|
|||
|
|
|||
|
[Schneier] Schneier, B., "Applied Cryptography Second Edition:
|
|||
|
protocols, algorithms, and source code in C", 1996.
|
|||
|
|
|||
|
Author's Address
|
|||
|
|
|||
|
Donald E. Eastlake 3rd
|
|||
|
IBM
|
|||
|
65 Shindegan Hill Road, RR #1
|
|||
|
Carmel, NY 10512
|
|||
|
|
|||
|
Phone: +1-914-276-2668(h)
|
|||
|
+1-914-784-7913(w)
|
|||
|
Fax: +1-914-784-3833(w)
|
|||
|
EMail: dee3@us.ibm.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 2536 DSA in the DNS March 1999
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implementation may be prepared, copied, published
|
|||
|
and distributed, in whole or in part, without restriction of any
|
|||
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be
|
|||
|
followed, or as required to translate it into languages other than
|
|||
|
English.
|
|||
|
|
|||
|
The limited permissions granted above are perpetual and will not be
|
|||
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|||
|
This document and the information contained herein is provided on an
|
|||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Eastlake Standards Track [Page 6]
|
|||
|
|