Internet DRAFT - draft-haikuo-ckds
draft-haikuo-ckds
Network Working Group Haikuo. Zhang
Internet-Draft Likun. Zhang
Intended status: Informational CNNIC
Expires: December 8, 2012 June 6, 2012
Compromised-key Digest Signature (CKDS) Introduction and Requirement
draft-haikuo-ckds-01
Abstract
DNS Security Extensions (DNSSEC) is widely deployed at TLD and other
important domain names currently. DNSSEC is an effective method to
provide security protection for end users in the network. DNSSEC
needs a lot of operations to maintain the chain of trust, like DNSKEY
rollover operations periodically. But the chain of trust could be
broken if the operator of domain replaces the old key immediately in
a emergency rollover operation when the key is compromised. The
break will make the domain and his sub-domains invisible in a short
time if the data in the cache of resolver is right, on the contrary,
the fake RR in the cache of resolver may be "valid" if the resolver
is under the attack from hackers. This document introduces the
compromised-key digest signature (CKDS) resource record to mitigate
the impact of invalidation which is due to emergency rollover from
the authoritative name server.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 8, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang & Zhang Expires December 8, 2012 [Page 1]
Internet-Draft CKDS June 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. CKDS Resource Record . . . . . . . . . . . . . . . . . . . 4
3. Services Extension . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Service of CKDS . . . . . . . . . . . . . . . . . . . . . 5
3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 6
4. Authoritative Name server Considerations . . . . . . . . . . . 7
5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 8
6. Emergency rollover with CKDS . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhang & Zhang Expires December 8, 2012 [Page 2]
Internet-Draft CKDS June 2012
1. Introduction
DNS Security Extensions (DNSSEC) is described detailedly in a set of
RFC documents, they are [RFC4033] [RFC4034] [RFC4035] [RFC4641]
[RFC5011] [RFC5155] and so on. Two kinds of keys have been
introduced into signed zone file to help resolvers generate a chain
of trust [RFC4641]. The chain of trust is comprised of some digest
signature (DS) resource records, Key signing Key (KSK) resource
records, Zone signing key (ZSK) resource records and resource record
signatures (RRsig).
If the chain of trust is intact for the queried domain name, the
secure-aware resolver will set the AD flag in the response message to
end users. If the data is altered illegally in authoritative name
server, or the data is polluted by data spoofing at the cache of
resolver side, the secure-aware resolver will mark the response data
"bogus", and then the end user will receive a "server Fail" message.
If the domain name is critical for the Internet security, DNSSEC can
prevent the end user from being cheated by the illegal data from DNS.
Each level of domain names will roll over the DNSKEYs in a certain
period or when the Key was compromised if they support DNSSEC at
authoritative name server side. For instance KSK could roll over
with double-signature algorithm, ZSK could roll over with pre-publish
or some other algorithm.
However, the resolver could not explicitly distinguish the
compromised KSK from the KSKs which are not compromised but will be
replaced in the rolling-over process in the current mechanism of
DNSSEC. If the resolver can identify which KSK is compromised, the
resolver could clean up the related data (e.g. the RRsigs which were
signed by the compromised KSK and all of his sub domain data which
was verified from the compromised KSK) in the cache as soon as
possible to reduce the losses. If the KSK is in the regular rolling
over process and is not compromised, the resolver could only update
the KSK and his RRsig in the cache. The emergency rolling-over for
KSK may lead to more losses at the administrators than hackers if
resolver could not identify which DNSKEY is compromised or which one
is not.
The compromised-key digest signature (CKDS) is introduced to handle
this problem above. This type of resource record can be used to
distinguish the compromised-key from the other KSKs which are roll
over regularly, and help the secure-aware resolver do "the right
things" to reduce the losses.
Zhang & Zhang Expires December 8, 2012 [Page 3]
Internet-Draft CKDS June 2012
2. Terms
This section defines one important term for this document.
2.1. CKDS Resource Record
Compromised-key digest signature (CKDS) is a kind of Resource record
similar to DS RR. CKDS and DS are both stored at the parent zone,
but the CKDS points at the DNSKEY which has been compromised in the
sub domain. If the CKDS RRset exists at the parent zone, this means
the DNSKEY which the CKDS points at has been compromised in the zone.
The CKDS RRset should be submitted from the administrator of sub
domain, and be stored and signed at the parent domain at the zone
cut. The RRsig of CKDS in the parent domain could be used to do the
verification for the CKDS at the secure-aware resolver.
The Type value for the CKDS RR is [TBD].
The format of CKDS looks like DS RR. The CKDS RDATA wire format is
as the followed:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Key Tag Field and the method to compute the key tag in the CKDS
are as the same as the DS [RFC4034]. The algorithm number in the
RDATA is identical to the algorithm number which is used to make
RRsig for the DNSKEY. The Digest Type Field is identical the
algorithm of constructing the digest. The Digest Field is calculated
as the same as the Digest Field of DS resource record [RFC4034]:
Digest = digest_algorithm(DNSKEY owner name | DNSKEY RDATA);
"|" means concatenation, and DNSKEY RDATA = Flags|protocol|Algorithm|
Public Key
It means that the RDATA in the CKDS is as the same as the one in DS
if they all point at the same DNSKEY and use the same digest type.
Zhang & Zhang Expires December 8, 2012 [Page 4]
Internet-Draft CKDS June 2012
3. Services Extension
DNSSEC provides a mechanism to maintain an intact chain of trust to
verify the response data, find out the polluted data and return the
corresponding result to the end users. DNSKEY and this DS Resource
record which is stored at the parent domain zone file combine the
parent domain and child domain in the chain of trust; the DNSKEY and
the RRsig of the RRset in a domain zone file are linked together in
chain of trust to verify the RRset. The private portion of Key pair
for KSK will sign ZSK resource records, and the public portion of key
pair for KSK will be published to validate the ZSK at the resolver
side. The private portion of ZSK will sign the other resource record
sets (RRsets) at the zone file, and resolver will validate the other
RRsets at the zone file by the public portion of ZSK which is
validated by the KSK. The digest signature (DS) of the public
portion for the KSK will be send to his parent zone file, and the
child-domain KSK could be identified with the DS which is stored in
the parent side. The resolver should define some trust anchors as
the start of the chain of trust.
The secure-aware resolver may return "bogus" response message for the
DNSSEC query from end user if the chain of trust breaks because of
administrator's irregular operation in the Authoritative name server.
The phenomenon for the end user is as the same as the data which is
polluted by hacker's attack. The broken of trust chain from the
upper domain would make more domains invisible, and it may be
severely fatal for some important domain name because it will stop
the service from the Internet temporarily.
3.1. Service of CKDS
The administrator of sub-domain should submit a new DS RR which
pointed at a new DNSKEY and the CKDS which pointed at the old
compromised DNSKEY when he found the old private key compromised.
The secure-aware resolver should use other DNSKEY and other DS except
the one which the CKDS points at to verify the RRs in the response
message.
If the CKDS and his RRsig can be verified, all the data (including
the sub-domain-related data ) which is related to the compromised
DNSKEY should be removed from the cache of resolver. The removed
data contains the compromised DNSKEY, the RRsig which is signed by
the DNSKEY, and the sub domain data. Then the related data should be
queried again. The data in the cache should be flush once during the
time of TTL of CKDS.
If the other DNSKEY which is not pointed by CKDSs and his related DS
exist, it means there is another chain of trust to verify the
Zhang & Zhang Expires December 8, 2012 [Page 5]
Internet-Draft CKDS June 2012
response data, then the resolver should mark the data "secure" if the
other chain of trust is intact. If there are other chains of trust,
and all of them could not verify the domain RRsets, the resolver
should return "bogus".
If there is not any chain of trust else, that means all of DNSKEYs
are pointed at by CKDS resource records in the parent domain and
there is no available DNSKEY, and then mark "insecure" to the data.
3.2. Backward Compatibility
The CKDS is extending the current DNSSEC protocols. If CKDS does not
exist in the zone file, there is no difference from the current
DNSSEC. If the CKDS exists in the zone file, it is compatible to the
current DNSSEC when the chain of trust is intact.
When the CKDS exists in the parent domain and the CKDS is verified in
the resolver side, the resolver should disable the DNSKEY which this
CKDS pointed at and the related DS RR.
If the CKDS RR could not be verified by the current DNSSEC protocol,
the CKDS should be disabled in the resolver side.
Zhang & Zhang Expires December 8, 2012 [Page 6]
Internet-Draft CKDS June 2012
4. Authoritative Name server Considerations
If the CKDS RR was inserted into the zone, it should be signed to
create his RR signature. The name server should add CKDS RR and his
RRsig in the additional section in the response message if the
resolver or end user queries any RR of the domain.
There is no difference else to response the query from the name
server side.
Zhang & Zhang Expires December 8, 2012 [Page 7]
Internet-Draft CKDS June 2012
5. Resolver Considerations
If got the CKDS RR, the resolver should verify the CKDS using the
RRsig of the CKDS and the verified DNSKEY which is used to sign the
CKDS at the parent side. If the CKDS is valid, then the resolver
should remove all the data about the domain (including the data of
his sub-domains) which CKDS pointed at from the cache, except the
CKDS. At last, the resolver should make a lookup to the
authoritative name server for getting new data. The DS which point
at the compromised-key should be disable in the verification process.
The resolver should use other DS else and DNSKEY to verify the data
from name server. If the chain of trust is intact by using the other
DS and DNSKEY, the resolver should mark the response data "secure".
If the other DS exists, but all of them verify the relative data
failed, the resolver should return "bogus". If no other DS exists in
the authoritative name server, the resolver should mark the data
"insecure".
Zhang & Zhang Expires December 8, 2012 [Page 8]
Internet-Draft CKDS June 2012
6. Emergency rollover with CKDS
When administrator found his DNSKEY was compromised, he should append
a new KSK to the zone of his domain, and then submit a CKDS which
points at the compromised key and a new DS which points at the new
KSK to this parent domain zone file.
It is after the compromised data is cleaned up in the cache of all of
resolvers (a TTL of the old DS RR later) that the compromised DNSKEY
should be revoked, and then the CKDS and the DS which pointed the
compromised key can be removed in the authoritative name server in a
short future. The KSK emergency rollover process is followed:
----------------------------------------------------------------------------
initial new-DS new-DNSKEY DNSKEY-revocation DS/DNSKEY-removal
----------------------------------------------------------------------------
Parent side:
SOA0 SOA1 ---------------------------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) ---------------------------> RRSIGpar(SOA2)
DS1 DS1 ---------------------------> DS2
DS2
RRSIGpar(DS) RRSIGpar(DS) ---------------------------> RRSIGpar(DS)
CKDS
RRSIGpar(CKDS)
Child side:
SOA0 --------> SOA1 SOA2 SOA3
RRSIG1(SOA0) --------> RRSIG1(SOA1) RRSIG2(SOA2) RRSIG2(SOA3)
--------> RRSIG2(SOA1)
DNSKEY1 --------> DNSKEY1 DNSKEY1-revoked
--------> DNSKEY2 DNSKEY2 DNSKEY2
RRSIG1 (DNSKEY) --------> RRSIG1(DNSKEY) RRSIG2 (DNSKEY) RRSIG2(DNSKEY)
--------> RRSIG2(DNSKEY) RRSIG1-REVOKE(DNSKEY)
----------------------------------------------------------------------------
The "new-DS" step and "new-DNSKEY" step above can be done at the same
time in the above KSK emergency rollover process.
This emergency rollover with CKDS can make sure the chain of trust is
intact in the resolver side. The chain of trust is showed in the
following form.
Zhang & Zhang Expires December 8, 2012 [Page 9]
Internet-Draft CKDS June 2012
---------------------------------------------------------------------------
| Cache data in the resolver | Chain of trust |
--------------------------------------------------------------------------
| Old DS record | compromised KSK which | intact |
| | is not revoked | |
--------------------------------------------------------------------------
|New DS record, old|New KSK and compromised| intact |
|DS record and the |KSK which is not | |
| CKDS |revoked | |
--------------------------------------------------------------------------
| Old DS record |New KSK and compromised| intact |
| |KSK which is not | |
| |revoked | |
--------------------------------------------------------------------------
|New DS record, old|compromised KSK which |Inexistent case, |
|DS record and CKDS|is not revoked |because resolver should flush |
| | |the old data in the cache when|
| | |it got CKDS |
---------------------------------------------------------------------------
Zhang & Zhang Expires December 8, 2012 [Page 10]
Internet-Draft CKDS June 2012
7. Security Considerations
The TTL of CKDS should have a limit at the resolver side. If the
DNSKEY is compromised, and then hackers should create some CKDS RRs
for his sub domain with smaller TTL, then the resolver will refresh
the cache more frequently if there is no the lower limit setting at
the resolver side.
It is only once that the data in the cache should be refreshed in the
TTL of CKDS, and the TTL of CKDS has a minimum at the resolver side.
This method could not remove all the related data in the cache of
resolver immediately, because the resolver could not do a lookup
until the DS which pointed at the compromised key expires at the
cache. But the CKDS could protect the "right" data from being
verified failed, and it could push the resolver to refresh the data
more quickly in the cache in time in the emergency rolling over
process.
The CKDS is useless for the trust anchor whose key pair was
compromised at the resolver side.
Zhang & Zhang Expires December 8, 2012 [Page 11]
Internet-Draft CKDS June 2012
8. Acknowledgements
The author sincerely acknowledges the assistance and help from the
following ones of CNNIC: Wenming Wang, Zhuquan Li and other
colleagues who paid attention to this draft.
The author also wants to thank Shane Kerr who reviewed this draft and
gave profound and valuable feedback.
Zhang & Zhang Expires December 8, 2012 [Page 12]
Internet-Draft CKDS June 2012
9. References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Larson, M., Massey, D., and S. Rose, "Resource
Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC4035] Arends, R., Larson, M., Massey, D., and S. Rose, "Protocol
Modifications for the DNS Security Extensions", RFC 4035,
March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 5011, September 2006.
Zhang & Zhang Expires December 8, 2012 [Page 13]
Internet-Draft CKDS June 2012
Authors' Addresses
Haikuo Zhang
China Internet Network Information Center
4 South 4th Street,Zhongguancun,Haidian District
Beijing, China 100190
Phone: +86 10 5881 3163
Email: zhanghaikuo@cnnic.cn
Likun Zhang
China Internet Network Information Center
4 South 4th Street,Zhongguancun,Haidian District
Beijing, China 100190
Fax: +86 10 5881 3250
Email: zhanglikun@cnnic.cn
Zhang & Zhang Expires December 8, 2012 [Page 14]