RE: Keys and DS

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

Halloo all.  I'm assuming that Ed's rules are expected to
cover typical cases where:
  A.  There *might* be a human-in-the-loop at both the
	parent and child, but some organizations will want
	everything to work automagically (meaning that
	zone private keys will be online to support signing)
  B.  The only normal communications mode between the
	master servers for the parent and child zones are
	in-band (over the 'Net which cannot be assumed to
	be bad-guy free).
  C.  All cryptography and key storage is done in software
	on typical OSs--meaning that a root compromise on
	the system gives the attacker access to *everything*
	and root compromises have a non-zero probability.

Automagic negotiation/update of DS isn't *quite* like full-up
Over-the-Air Rekeying (OTAR)[1] but I believe the problems
are similar in some important ways.

So, IMHO:

> > First question.  Is there a requirement/need to have a child provide
> > authentication during the sending of material key material 
> to the parent?
> > (By "key material" I am not inferring a KEY set for this question.)
> 
> during normal key rollover this is probably not necessary if 
> the new key
> material is authenticated by the old key material. on initial 
> key exchange
> or at emergency key rollover, authentication is critical.

...and since there's no way /a priori/ to decide whether the "old"
keys have been compromised, every key supercession must be treated
as if it were an emergency supercession.  (Then again, if all the
authenticators are stored online at the parent and child, you're
still screwed.)

For the postulated situation above, I can't come up with a
way to authenticate the child->parent transmission that protects
against a "fully" compromised child *and* still allows automagic
key updates--so I would tend to say "why bother?".  (If someone
knows of a protective measure which I missed, please point it out.)
At some point in the future when sites that need higher assurance
are using hardware cryptographic co-processors, though, I believe
that the authentication piece will be necessary and worthwhile--
so I would ask that it be added/maintained for now.  (Even in
the interim, there are some situations where it would seem to
be a potential benefit to have all such transactions authenticated
by means other than "I have the old key material".)

> > Second question.  Should the child be responsible for 
> sending the generated
> > DS records to the parent?  (This is perhaps a touchy 
> question.)  I won't
> > elaborate further, I would like to hear opinions.
> 
> a signed keyset could be authenticated by itself (together 
> with a previous
> key). a set of ds records sent to the parent need additional
> authentication.

I don't think this is so much an authentication question, I
think it's a policy question.  I believe the child MAY send a
generated (requested) set of DS records to the parent, but the
parent SHOULD verify that those DS records are correct and policy
compliant, and the parent SHOULD (MUST?) verify the authenticity
of the child's request.  If the child does not send a set of DS
records to the parent, then the child MUST send its signed keyset.

Does that make sense?
 
> 
> > Third question.  With the use of DS, if each member of a 
> zone's apex keyset
> > is represented by a (signed) DS record at the parent, 
> is/are SIG(KEY)s
> > necessary?  E.g., If I see this:
> 
> since SIG(DS) at the parent could be used, this doesn't seem 
> necessary.
> but, on the other hand, why bother not having it?

I thought that there was some possibility that the DS record
was going to point to a rarely-changed child keypair that would
itself be used to sign the "real" zone signing keypairs for
for the child.  In that case, not all of the keys at the zone
apex would necessarily have corresponding DS records in the parent.
Did that concept go by the wayside, or am I mis-remembering?

Please feel free to educate me if I missed something in
previous discussions.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com



[1]  For "traditional" OTAR such as is used in military
	SINCGARS radios, the Transmission Encryption Key (TEK)
	for a cryptonet is a symmetric key that can be loaded
	locally or can be sent over the air.  OTAR uses a
	second pre-loaded symmetric Key Encryption Key (KEK)
	to protect the TEK during transmission.  It's great if
	everyone on the cryptonet is a good guy, even if the
	bad guys have cracked/obtained your TEK--OTAR will
	then result (again) in a protected cryptonet that the
	bad guys can't participate in.  But if the bad guys
	have a functional SINCGARS with a valid KEK, then OTAR
	doesn't cut them out of the loop.  You really
	need out-of-band comms to fix such a situation...
	but everyone reading this probably already knows
	that unfortunate truth.