Subject: Re: [Netconf] Netconf Digest, Vol 69, Issue 9

From: "Ibrahim A. Lawal" <[email-masked]>
Date: Fri, 8 Nov 2013 14:44:40 +0800 (MYT)

Thanks

----- Original Message -----
From: [email-masked]
To: [email-masked]
Sent: Wednesday, November 6, 2013 9:53:01 AM
Subject: Netconf Digest, Vol 69, Issue 9

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/netconf

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Netconf mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/netconf
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netconf digest..."

Today's Topics:

   1. Re: Why bother with DNSSEC for ZeroTouch? (Ladislav Lhotka)
   2. Re: Why bother with DNSSEC for ZeroTouch? (Ralf Skyper Kaiser)
   3. Re: I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt (Kent Watsen)
   4. Re: Why bother with DNSSEC for ZeroTouch? (Kent Watsen)
   5. Re: Reverse TLS and reverse SSH: Why support both? (Kent Watsen)

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

Message: 1
Date: Tue, 5 Nov 2013 12:10:31 -0800
From: Ladislav Lhotka <[email-masked]>
To: Ralf Skyper Kaiser <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <[email-masked]> wrote:

> Hi,
> 
> .
> 
> 
> On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka <[email-masked]> wrote:
> 
> On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser <[email-masked]> wrote:
> 
> I don?t agree. The attacker has an open TCP session and can use it for other attacks, not only DoS. Already the information about the existence and address of the device might be a problem.
> 
> 
> Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device??

With DNSSEC this becomes considerably harder.

>  
> Other that that, DNSSEC can be useful in connection with DANE (RFC 6698), so that a certificate of a DNSSEC root (public or private) is all that?s needed - NMS certificate can thrn be obtained from DNS.
> 
> In ZeroTouch the CA bundle is pre-programmed into the device. So DANE is not required. (And it DANE would be required than the CA key to verify the DNSSEC request would need to be preprogrammed into the device - nothing is gained beside making it complex?).

The device can only be pre-programmed with DNSSEC trust anchor, and that?s all. I don?t call it complex.

Lada

> regards,
> ralf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Message: 2
Date: Tue, 5 Nov 2013 20:18:55 +0000
From: Ralf Skyper Kaiser <[email-masked]>
To: Ladislav Lhotka <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?
Message-ID:
	<CA+BZK2oj5Wc92QT6_Vm52iMXss5NB4rN=[email-masked]>
Content-Type: text/plain; charset="windows-1252"

Hi,

On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka <[email-masked]> wrote:

>
> On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <[email-masked]> wrote:
>
> >
> > Even with DNSSEC an attacker can make the device to connect to a bogus
> NMS and thus giving the attacker an open TCP session to the device??
>
> With DNSSEC this becomes considerably harder.
>
>
No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse
SSH traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any method
between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS
poisoning. Not more.

regards,

ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/netconf/attachments/20131105/228d19d6/attachment.htm>

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

Message: 3
Date: Wed, 6 Nov 2013 00:30:21 +0000
From: Kent Watsen <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] I-D
	ACTION:draft-ietf-netconf-reverse-ssh-02.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Joe,

This issue was discussed in the NETCONF WG meeting.  Specifically, the
choices of:

  - having a default port
  - not having a default port (port has to be explicitly configured)
  - try to update the TLS and SSH protocols to support reversal

There was unanimous support in the room to have a default port (around 30
people).  No one raised their hand to support any other option.

Playing devil's advocate, I made a case for having NO default port.  That
is, for the ZeroTouch solution, the device is already learning so much
NMS-specific information, learning a port number also is easy.
Unfortunately, reverse-SSH and reverse-TLS can be used outside of
ZeroTouch and, for those cases, the port would then need to be manually
configured, which people didn't like.

As a quick recap, we initially took Reverse SSH to the SSH list, but it
died there due to this port issue.  Reverse SSH was resurrected after
receiving a lot of operator demand for it.  We decided to bring Reverse
SSH to NETCONF WG specifically to end the discussion of if it uses an
in-band or out-of-band mechanism to trigger the reversal.  The NETCONF WG
consensus was at that time and is still to use a port.

Thanks,
Kent

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

Message: 4
Date: Wed, 6 Nov 2013 01:14:18 +0000
From: Kent Watsen <[email-masked]>
To: Ralf Skyper Kaiser <[email-masked]>, Ladislav Lhotka
	<[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Ralf,

Please explain the specific attack you're envisioning.  I agree that the device's call-home connection could be steered to another system and I'll agree that that system could blindly authenticate the device's public key.   But in order for security to be compromised, that system needs to be able to authenticate itself to the device, which is where it will fail because it will not know the real NMS's auth credentials (e.g. private key).

Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to configure the device with the NMS it's to connect to and 2) to configure the device with information it can use to authenticate the NMS with.  It is this 2nd piece of information that prevents the spoofer from succeeding.  Critical to this is that the device can verify the authenticity of the information it downloads from the network, which is where using DNSSEC plays a role.  Makes sense?

PS: I also agree with your premise that unnecessary code leads to a larger attack surface, but devices should already have support for DNSSEC.  It is not envisioned that this solution introduces new code to the device but, if it does, it is a good thing.

Thanks,
Kent

From: Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 12:18 PM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?

Hi,

On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>> wrote:

>
> Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device......

With DNSSEC this becomes considerably harder.

No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SSH traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any method between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poisoning. Not more.

regards,

ralf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/netconf/attachments/20131106/1bfc3f7d/attachment.htm>

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

Message: 5
Date: Wed, 6 Nov 2013 01:51:48 +0000
From: Kent Watsen <[email-masked]>
To: Ralf Skyper Kaiser <[email-masked]>, "[email-masked]"
	<[email-masked]>
Subject: Re: [Netconf] Reverse TLS and reverse SSH: Why support both?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

> Why support SSH and TLS? Either protocol establishes a secure tunnel by
>exchanging 1?s and 0?s.

NETCONF supports both transports for good reasons.

> Why leave the decision which protocol to use to the manufacture? If the
>WG can?t decide if TLS or SSH is more secure then the manufacture won?t
>be able to decide either.

It isn't left to the manufacturer, each specific deployment chooses it for
themselves.

> Removing one of them from the implementation halves the possibilities
>for an attacker to find vulnerabilities, enables the developer to spend
>2x the time (and care) on one protocol and removes complexity in general.

> Focusing on one protocol and give that one protocol all attention
>(review, testing, audit ...) could have some advantages.

Noted.  Each manufacturer can choose what they want to implement and
support.

> My gut feeling is that reverse SSH should be dropped unless there is a
>functionality or security benefit that cannot be achieved with reverse
>TLS.

SSH is NETCONF's mandatory transport, as such, supporting Call Home with
SSH is a given.  

> Trusting a manufacture to generate secure X.509 certificates, having a
>secure RNG and running a CA securely gives me a funny feeling. But hey,
>what can possibly go wrong....:>

Your concern is unwarranted.  The spec clearly states that the
manufacturer should use a TPM.  These chips are typically awarded the
highest security certifications (FIPS, CC, etc.).   Also, this proposal
has been reviewed by multiple security experts with no concern raised.
But, really, what option is there, given the use-cases ZeroTouch tries to
solve?

Thanks,
Kent

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

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

End of Netconf Digest, Vol 69, Issue 9
**************************************