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]