Re: [renum] Key management [draft-liu-6renum-gap-analysis-03]

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Brian E Carpenter writes:
> On 2011-12-10 11:45, Mark Andrews wrote:
> > In message <[e-mail]>, Ran Atkinson write
> > s:
> 
> ...
> >>>> I think the problems with key management deserve their
> >>>> own subsection in Section 10 -- as a category of "gap"
> >>>> that ought to be addressed.  That new subsection ought
> >>>> to note the operational issues with key provisioning
> >>>> and key management for Secure Dynamic DNS Update
> >>>> (at least for non-MS nodes) and equally or more so
> >>>> for Secure DHCPv6 and SEND.  One would hope these
> >>>> would not fall into the "unsolvable gap" category,
> >>>> but in any event these gaps do need to be clearly
> >>>> documented.
> 
> >>> The key management is a complicated issue. It is worth
> >>> a separated draft. It is relevant. However, we don't
> >>> think it is a renumbering specific issue.  We will add
> >>> some new text for it. But we would like to leave it out of scope.
> >> I do not think that ignoring the issue or declaring it
> >> out-of-scope is a legitimate position to take for this
> >> document.
> >>
> >> IETF rules require that ALL documents must fully address
> >> Security Considerations *within their own document*.
> >>
> >> Ignoring that topic -- or shunting it off to other
> >> documents -- will result in a Last Call objection from me 
> >> and possibly others on the very solid technical grounds
> >> that the Security Considerations are known to be deficient.
> 
> Right, but the question is what can we say about key management
> that is specific to enterprise renumbering? We can explain the
> problem, but this is presumably not the WG where a solution should
> be developed.
> 
> > With Windows you add the machine to the domain.  This is a
> > one off procedure and the last time I did it this it needed
> > a domain administrators password if my memory is correct.
> > 
> > Initial registration doesn't necessarially need to be standardised.
> > It can be ad-hoc.  Log into a web page and it can return a TSIG 
> > which is configured into the nameserver and the client machine.
> > 
> > That's done all the time to secure zone transfers.
> > 
> > What need to be standardised is what goes on the wire and that
> > was done years ago.  The rest really is implementation detail.
> 
> Really? It seems to me that the Windows solution will only work for
> a Microsoft shop, not for a heterogeneous enterprise network.

If you really want a mechanism to do this then something like
this will work:

If the machine does not already have a configured TSIG (RFC 2845)
it will generate a one time public/private key pair and send the
public key along with a request for a TSIG to update the forward
zone in a DHCP request.  The DHCP server will make a TKEY (RFC 2930)
request, on behalf of the client, using its credentials to the DNS
server and return the resulting TSIG key to the client encrypting
the TSIG option response using the public key in the request.  The
returned TSIG key should be stored in non-volatile memory.

The DHCP server operates as the secure introducer to the DNS server.

One would probably want to signal if the TSIG request is for globally
or locally unique name and be able to request both.  This will allow
the host to update multiple namespaces by using the different TSIGs
Different DHCP server credentials could be used to signal this or
we could specify a TKEY option.

ULA/RFC 1918 would be private addresses and would only be addded to
the local name space.

We can do something similar for PPP.

Security considerations:

If the DHCP option is responded to by a rogue server the worst is
a denial of service attack.

The DHCP server can pretend to be the DHCP client as it has seen
the TSIG material.

>    Brian
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]