Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 01 Nov 2013 13:58:19 -0400

On 10/31/13, 8:41 AM, Kent Watsen wrote:
>
> Hi Joe,
>
>> why would the device need the FQDN of the vendor's DNS
>> server?  Couldn't it use the domain name with an NS query to get this?
>> I'm trying to think of something that may be more scalable over time
>> (i.e., if an older device is deployed that may have an old FQDN).
>
> Because we need to support devices connected to ISP networks (think
> McDonalds, Radio Shack, etc.), we cannot assume the presence of any
> locally-administered server (DHCP, DNS, LDAP, etc.) that a device could
> extract deployment-specific information from.  From the device's
> perspective, its local DHCP and DNS servers are administered by the ISP,
> who is disinclined to allow its customers to insert customer-specific
> information into them.

Sorry, I think I was unclear.  I meant why can't we lookup the NS record 
in the ISP's DNS?  Meaning, why should I statically configure 
"n1.cisco.com" in all my devices?  Why not just configure cisco.com, and 
have the device do the equivalent "host -t NS cisco.com" to find the 
nameservers?

>
>
>> What type of DNS queries will be used to get the NMS name and
>> credentials?  It would be helpful to see a query flow diagram in this
>> draft.
>
> I guess it would be the 'A' record for the
> <sha1-of-device-pub-key>.<vendor-zone> entry.  As pointed out in the Open
> Issues section, already we need to extend DNS to accommodate some data, so
> including this data in that analysis as well makes sense.  Being a -00
> with no implementation as of yet, we're really just fishing to see if the
> IETF has interest.  If so, then we'd be sure to lock down all the unknowns
> at that time.

Okay.

>> In the security considerations, you mention the potential threat in a
>> malicious party learning the NMS FQDN, but I think the NMS authn
>> parameters are more sensitive.  Additionally, there may be hesitance of
>> customers to store authn parameters within a vendor database.  One
>> potential workaround of this might be an alternate DNS address that the
>> new device can query in the customer's network that would provide these
>> bits of info.  This would maintain the ability to support
>> customer-unconfigurable DHCP servers while still allowing things like
>> the NMS parameters to be maintained within the customer's network.
>
> Regarding auth parameters, we'd only support storing public keys or hashed
> passwords.  As such, the concern for who has access to them is essentially
> eliminated.  With large enough keys lengths, even a brute force attack
> would be acceptably unlikely.

I still think we'd see some reluctance here.  Even usernames might be 
revealing.  But I get your point.  Perhaps it's worth clarifying that in 
the document's text.

One other comment comes to mind...

Should the document state that a device can be put back into an initial 
state to reinitiate Zero-Touch?  This may be obvious, but I think it's 
worth noting that this need not only apply to new devices.

Joe
-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Nov 2013 19:46:48 +0000

>have the device do the equivalent "host -t NS cisco.com" to find the

I see, thanks for the clarification.  This approach sounds good.  The only
caution might be that Cisco might want to use a nameserver other than it's
standard nameservers for this purpose, so the request might need to go to
something other than what the NS record for "cisco.com" returns - what do
you think?

>revealing.  But I get your point.  Perhaps it's worth clarifying that in

Absolutely needs to be cleaned up.  We also have your idea to have the
lookup in the vendor's DNS server be a redirection to a
deployment-specific server.  We should settle that first.

Having a username in the clear may or may not be OK.  A couple reasons for
why it might be OK are 1) the username itself would likely be something
generic (e.g. "admin"), not personally-identifiying and 2) security it's
bound to the username, its the key that matters.  We'll need to ask the
Sec folks what they think about it.

>worth noting that this need not only apply to new devices.

It should say something, but there is a disagreement as to which way it
should go.  At least one Security person mentioned that all bets are off
on a resale of the device.  That is, the previous owner could potentially
compromise its crypto chip such that it could no longer be assured to be
secure solution.  I'm on the fence because 1) it seems unlikely and 2) it
should be up to the customer to choose.

Thanks,
Kent

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sat, 02 Nov 2013 18:00:32 -0400

> something other than what the NS record for "cisco.com" returns - what do

That did occur to me, so perhaps this can be a vendor-selectable thing. 
  It wouldn't matter much to the end consumer, and might scale better 
for vendors that might see a change to external NSes.

> Sec folks what they think about it.

You're right there.  My overall point was that the security 
considerations should mention the fact that the end consumer may not 
feel comfortable sharing these credentials with the vendor.  Even with a 
hash, an attacker could get it and try and brute force the value.

> should be up to the customer to choose.

I meant that I as a consumer (and owner) of the device might want to 
reset the device to factory default to trigger another Zero Touch bootstrap.

Joe