One Interaction KEY exchange

[Olaf Kolkman <[e-mail]>]

Ref: draft-ietf-dnsop-parent-sig-00.txt


Using the ideas from draft-ietf-dnsext-parent-stores-zone-keys-00.txt
this is an alternative to the key exchange mechanism described in
section 4 of that draft (which is the same as in
draft-ietf-dnsop-parent-sig-00.txt)

I think one can restrict the parent-child interaction even more. I get
to only 1 child parent interaction and an optional parent child
interaction. During the rollover the parent only needs to sign keys
once instead of twice.

Consider the following

1. To initiate a key rollover the child replaces the KEYold by the
KEYnew, signs KEYnew and the rest of the zone using the old and new KEY.

Then the child signals the parent to initiate the rollover.

2. The parent fetches the new key with the double signature and verifies
the SIG made with the old KEY with the old child KEY that the parent
is authoritative for. If the SIG is correct the Parent publishes the
new KEY with parental signature.

Since all child zone data is already signed with the new key that
data is also validated against the now signed KEYnew.

3. Once the child notices (or receives the optional signal by the parent)
that KEYnew has been signed the child can remove the SIG made with
KEYold. This is not a resigning exercise. A simple 'grep -v' will do.


To put this in a hopefully readable table:     
__________________________________________________
KEYold is  the child's old key RR
KEYnew is  the child's new key RR
SIGparent(RR) is the parental signature over RR
SIGkeyold(RR) is the child  signature over RR using keyold
SIGkeyold(RR) is the child  signature over RR using keynew
(At all times the child has signed the complete zone with the same keys 
as it signed the KEY record with.)
_______________________________________________________________________________
Time               Parent state              Child state         Comment
_______________________________________________________________________________

0                  KEYold                 KEYold            Before key rollover
                   SIGparent(KEYold)      SIGkeyold(KEYold)
            
1                  KEYold                 KEYnew             Shortly before 
                   SIGparent(KEYold)      SIGkeyold(KEYnew)  rollover
                                          SIGkeynew(KEYnew)  This works 
                                                             because parent 
                                                             is authoritative.

2a   SIGNAL to parent parent fetches KEYnew with the two sigs. It can verify
     SIGkeyold(KEYnew) against the data it holds itself. then replaces KEYold 
     by KEYnew and signs
  
2b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeyold(KEYnew)
                                           SIGkeynew(KEYnew)

          
3a  SIGNAL from parent to child. Child checks signature over KEYnew and 
    knows it can dispose of SIGkeyold(KEYnew)

3b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeynew(KEYnew)

_______________________________________________________________________________




In the mentioned draft the child always publishes one KEY RR in its
KEY RRset that is signed by the parent. This is not the case in this
model still all arguments in paragraph 7 apply.

Paragraph 7:

"  There are two reasons to have of the child's zone KEY not only at the
   parent but also in the child's own zonefile: 
	1. to facilitate a key rollover  
	2. to prevent local lookups for local information to suffer 
           from possible loss of access to its outside parent

   To cope with 1, secure aware resolvers MUST be aware that during a
   key-rollover there may be a conflict, and that in that case the
   parent always holds the active KEY set.  To cope with 2, the local
   resolver/caching forwarder should be pre-configured with the zone-KEY
   and thus looks at its own zone as were it a secure entry-point.  For
   both things to work, the zone-KEY set must be selfsigned in the child
   zonefile.
"

As far as I can tell this scheme is still immune for fake signals
since the Parent will only update if it finds another key at the child
then the key in it's own zone. Besides, a spoofed new keyset will not
validate since it is not signed with the verifiable SIG made with the
old key.

To cope with point 2 from par 7 the zone administrator should configure
the local resolvers and forwarding caches with the KEYnew somewhere
between step 1. and step 2a. in the table



I welcome your merciless responses :-)


- --Olaf


- -----------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC 
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   [phone]
  Singel 258           |  Fax:     [phone]
  1016 AB Amsterdam    |  http://www.ripe.net
  The Netherlands      |  [e-mail]