I just pushed a new revision of the draft.
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01
Most notable changes:
* Some clarifications to the consensus based trust scheme
* PSK-management now supports key-derivation for different protocols
(IGPs, ...)
* Underlying crypto
1) i was hopeful that this might be a threats kind of draft which is
sorely needed. i was disappointed.
2) there is a huge set of possibilities in between PSK and PKI in
section 6.1 and 6.2. see #1.
Mike
On 10/14/2014 12:37 AM, Steven Barth wrote:
I just pushed a new revision of the draft.
On Fri, 3 Oct 2014, Steven Barth wrote:
Please note that this draft is in a very early stage so please help to
make additions, provide feedback and point out mistakes.
Being a crypto novice, let me write some text and please tell me if it
makes sense in the context of your draft (thanks for
Hi Mikael,
thanks for your feedback.
Being a crypto novice, let me write some text and please tell me if it
makes sense in the context of your draft (thanks for writing it, it
looks like a good summary).
I do not consider myself to be a crypto expert either which is one of
the reasons I'd
On 25.9.2014, at 14.19, Tero Kivinen kivi...@iki.fi wrote:
Markus Stenberg writes:
Is there something else that’ll work as transport layer security
for multicast, or should we send a request for the IETF leadership
to investigate if this is something that needs to be developed?
There is
Hiya,
I've not really been following this discussion sufficient
to comment in general, but just on this part...
On 29/09/14 08:39, Markus Stenberg wrote:
DTLS has rather sad multicast story too
The DICE WG [1] have also been discussing potential issues
with DTLS and multicast. That
Markus Stenberg writes:
There is also ikev2 version of group key management
(draft-yeung-g-ikev2), but the draft seems to have expired some time
ago. I still think it was supposed to be published.
Ah, interesting, did not know about that. Thanks ;)
If homenet needs multicast support
On Sep 29, 2014, at 3:50 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
Sooner would be much better than later for that as the DICE
WG are right now in the process of (re-)considering whether
they can in fact meet their chartered goals on this topic.
Unfortunately I think at this point
On 29/09/14 13:58, Ted Lemon wrote:
On Sep 29, 2014, at 3:50 AM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
Sooner would be much better than later for that as the DICE WG are
right now in the process of (re-)considering whether they can in
fact meet their chartered goals on this
On Sep 29, 2014, at 9:16 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
If, OTOH, you can say that you would in fact also require
origin authentication, then that is also of interest. (It'd
mean that your use case could not be met by the initially
chartered work for DICE, and that
On 09/29/2014 06:24 AM, Ted Lemon wrote:
On Sep 29, 2014, at 9:16 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
If, OTOH, you can say that you would in fact also require
origin authentication, then that is also of interest. (It'd
mean that your use case could not be met by the initially
Ted Lemon mel...@fugue.com wrote:
If, OTOH, you can say that you would in fact also require origin
authentication, then that is also of interest. (It'd mean that your
use case could not be met by the initially chartered work for DICE,
and that factoid could be helpful in
On Wed, 24 Sep 2014, Markus Stenberg wrote:
Big problem with IPsec + ‘any protocol’ is that it does not work _that_
well with multicast. Certainly, you can use manually keyed (static)
IPsec SAs (although in case of Linux, out of the box, it does not work
either but is easy to patch), but they
On 24.9.2014, at 12.07, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 24 Sep 2014, Markus Stenberg wrote:
Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well
with multicast. Certainly, you can use manually keyed (static) IPsec SAs
(although in case of Linux, out
On Sep 23, 2014, at 7:22 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
Mark Townsley m...@townsley.net wrote:
My own experience attempting to use IPsec as an add-on security
solution (a.k.a. pixie dust) for a protocol isn't all that
positive. We tried that with L2TP, and in the
Thank you for all of the discussion on this important topic.
Without declaring consensus on how far we should go scope-wise in terms of
overall homenet security just yet, I'd like to know if, in terms of HNCP itself
from a bits-on-the-wire protocol perspective, can we adopt this proposal
Mark Townsley m...@townsley.net wrote:
Without declaring consensus on how far we should go scope-wise in terms
of overall homenet security just yet, I'd like to know if, in terms of
HNCP itself from a bits-on-the-wire protocol perspective, can we adopt
this proposal proposal
Thank you for all of the discussion on this important topic.
Without declaring consensus on how far we should go scope-wise in
terms of overall homenet security just yet, I'd like to know if, in
terms of HNCP itself from a bits-on-the-wire protocol perspective, can
we adopt this proposal
On Sep 24, 2014, at 10:00 AM, Steven Barth cy...@openwrt.org wrote:
Maybe adding that we should try to use an existing and well-tested mechanism
unless there is a very good reason not to.
I don't think there is one, but if you think there is you should tell us! :)
Michael Thomas m...@mtcc.com wrote:
Michael Thomas m...@mtcc.com wrote:
2) ISP-provided router has to be willing to trust retail purchased
router,
or nothing works.
So what about the other way around? To what degrees should my homenet
trust
ISP-maintained CPE?
Markus Stenberg markus.stenb...@iki.fi wrote:
markus 1) Can we assume secure L2 and/or appropriate device
markus configuration by the manufacturer/ISP(/user)? (This is what I can
markus assume in my own home.)
I think that we can assume that wired links are secure.
The only
Steven Barth cy...@openwrt.org wrote:
And it's extremely unlikely that
DTLS will be a one-sentence solution even if it gets adopted because
DTLS, IPsec, etc say nothing
about enrollment and authorization. Those are by far the hard problems
with
homenent security.
I
On Sep 23, 2014, at 1:23 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
With respect, if you leave the trust scheme out of scope, what you are
really doing is leaving all of the security out of scope, because it won't be
deployable.
+1
___
Randy Turner rtur...@amalfisystems.com wrote:
Are we assuming that the home router is purchased retail, and not
fulfilled or provided by an ISP? The method to establish trust
relationships would hinge on the answer
1) if there only one home router from the ISP, then there is no
On 9/23/14, 10:59 AM, Michael Richardson wrote:
2) ISP-provided router has to be willing to trust retail purchased router,
or nothing works.
So what about the other way around? To what degrees should my homenet trust
ISP-maintained CPE?
Or more succinctly, what are the things the ISP
Michael Thomas m...@mtcc.com wrote:
2) ISP-provided router has to be willing to trust retail purchased
router,
or nothing works.
So what about the other way around? To what degrees should my homenet
trust
ISP-maintained CPE?
That's up to you. Seriously.
Your
On Sep 23, 2014, at 3:39 PM, Michael Thomas m...@mtcc.com wrote:
On 9/23/14, 1:07 PM, Michael Richardson wrote:
Michael Thomas m...@mtcc.com wrote:
2) ISP-provided router has to be willing to trust retail purchased
router,
or nothing works.
So what about the other way
On Sep 23, 2014, at 7:57 PM, Douglas Otis doug.mtv...@gmail.com wrote:
Actually, it is better to assume there is a long list of vulnerable home
routers being p0wned by entities beyond their ISP.
This is to some extent true, but not something we can really address in homenet.
On Fri, 19 Sep 2014, Mark Townsley wrote:
My own experience attempting to use IPsec as an add-on security solution
(a.k.a. pixie dust) for a protocol isn't all that positive. We tried
that with L2TP, and in the process failed to kill off PPTP on windows
clients. I can't tell you how many
I agree with this direction. This will also let the work HCNP and Security
Threats/Requirements to go on in parallel. Of course, HCNP security may
need to be revisited once the latter is agreed upon.
Thanks,
Acee
On 9/21/14, 3:22 PM, Mark Baugher m...@mbaugher.com wrote:
On Sep 20, 2014, at
On Sep 20, 2014, at 12:57 AM, Steven Barth cy...@openwrt.org wrote:
Am 20.09.2014 um 09:17 schrieb Tim Chown:
I think it would be useful to do, and needn't hold up progress. It would
give us a common understanding - hopefully - of which threats are being
covered and which are not. And
On 19 Sep 2014, at 21:59, Ted Lemon mel...@fugue.com wrote:
On Sep 19, 2014, at 4:54 PM, Michael Thomas m...@mtcc.com wrote:
I guess that's kind of what I've been getting at: should we capture all of
this in a threats document?
I'm a little uncomfortable with the formality, but I'm even
Am 20.09.2014 um 09:17 schrieb Tim Chown:
I think it would be useful to do, and needn't hold up progress. It would give
us a common understanding - hopefully - of which threats are being covered and
which are not. And which are handled by layers/protocols outside the scope of
homenet's
On Sep 18, 2014, at 12:34 PM, Ted Lemon mel...@fugue.com wrote:
On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H bs7...@att.com wrote:
UPnP Device Protection uses X.509 certificates (which can be self-signed,
and in order not to assume a WAN connection, really should be self-signed)
and TLS.
On 19.9.2014, at 11.18, Mark Townsley m...@townsley.net wrote:
My own experience attempting to use IPsec as an add-on security solution
(a.k.a. pixie dust) for a protocol isn't all that positive. We tried that
with L2TP, and in the process failed to kill off PPTP on windows clients. I
can't
On Sep 19, 2014, at 3:25 AM, Ted Lemon mel...@fugue.com wrote:
On Sep 18, 2014, at 6:46 PM, Mark Baugher m...@mbaugher.com wrote:
The retail model works here. I can imagine a compliant CPE might allow the
use to take ownership of an interior HNCP interface. That's only if the
provider of
On 09/19/2014 01:18 AM, Mark Townsley wrote:
Another lesson learned was exposing two passwords to the user vs. one.
In a retail/wholesale LAC/LNS deployment model, it made perfect sense
for the L2TP tunnel to have a password separate from the PPP user
password (and L2TP fully supplanted L2F
Am 19.09.2014 um 16:00 schrieb Michael Thomas:
And it's extremely unlikely that
DTLS will be a one-sentence solution even if it gets adopted because
DTLS, IPsec, etc say nothing
about enrollment and authorization. Those are by far the hard problems
with homenent security.
I wouldn't really
On 09/19/2014 07:52 AM, Steven Barth wrote:
Am 19.09.2014 um 16:29 schrieb Michael Thomas:
Punting on one of the hardest problems would be a travesty. There are
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to
do the right thing again if we
On Sep 19, 2014, at 10:52 AM, Steven Barth cy...@openwrt.org wrote:
That was not my point. I'm totally happy with having a standardized way of
doing this but I don't think that HNCP is the place where it should be
defined since we will probably not be the only user.
HNCP won't be the only
On Sep 19, 2014, at 8:54 AM, Ted Lemon mel...@fugue.com wrote:
On Sep 19, 2014, at 10:52 AM, Steven Barth cy...@openwrt.org wrote:
That was not my point. I'm totally happy with having a standardized way of
doing this but I don't think that HNCP is the place where it should be
defined since
On Sep 19, 2014, at 11:59 AM, Mark Baugher m...@mbaugher.com wrote:
How could it happen?
Isn't that what we've been discussing?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Sep 19, 2014, at 7:17 AM, Steven Barth cy...@openwrt.org wrote:
Am 19.09.2014 um 16:00 schrieb Michael Thomas:
And it's extremely unlikely that
DTLS will be a one-sentence solution even if it gets adopted because DTLS,
IPsec, etc say nothing
about enrollment and authorization. Those are
supplicant
knows the private key.
Randy
From: Michael Thomas m...@mtcc.com
Date: Thursday, September 18, 2014 at 3:06 PM
To: David R Oran daveo...@orandom.net, Rene Struik
rstruik@gmail.com
Cc: homenet@ietf.org, Markus Stenberg markus.stenb...@iki.fi
Subject: Re: [homenet] HNCP security
On Sep 19, 2014, at 1:22 PM, Mark Baugher m...@mbaugher.com wrote:
AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion
presumes that you have some way for a CPE from ISP-a to securely accept HNCP
from ISP-b, or the user's new AP/router, and so forth. How does that
On 9/19/14, 12:38 PM, Ted Lemon wrote:
On Sep 19, 2014, at 1:22 PM, Mark Baugher m...@mbaugher.com wrote:
AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion
presumes that you have some way for a CPE from ISP-a to securely accept HNCP
from ISP-b, or the user's new
On Sep 19, 2014, at 4:54 PM, Michael Thomas m...@mtcc.com wrote:
I guess that's kind of what I've been getting at: should we capture all of
this in a threats document?
I'm a little uncomfortable with the formality, but I'm even more
uncomfortable with the seeming desire
by some to sweep
On Wed, 17 Sep 2014, Michael Thomas wrote:
If we were to do that, it might be nice to have a distributed
database of homenet devices such that I only had to enroll it on one
of my homenet devices, and then it's distributed to the rest.
That is exactly what I tried to propose.
I agree,
Just to provide a pointer to a way that another org decided to handle a similar
problem (and I'm not suggesting this is the right approach -- I'm just trying
to provide food for thought):
http://upnp.org/specs/gw/deviceprotection1/
UPnP Device Protection uses X.509 certificates (which can be
UPnP Device Protection uses X.509 certificates (which can be self-signed,
and in order not to assume a WAN connection, really should be self-signed)
and TLS.
I think that something like this, in combination with the promiscuous
registration mechanism that I think Michael described earlier,
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H bs7...@att.com wrote:
X.509 certificates can be self-signed. That is, the device acts as its own
CA. In fact, this is the recommended approach.
Of course. But if there is never going to be a CA-signed key, there is no
reason to have a cert at
On 18.9.2014, at 16.05, Ted Lemon mel...@fugue.com wrote:
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H bs7...@att.com wrote:
X.509 certificates can be self-signed. That is, the device acts as its own
CA. In fact, this is the recommended approach.
Of course. But if there is never going to
On 09/18/2014 08:31 AM, Markus Stenberg wrote:
whether your authorization policy is leap of faithy, or strict ’these are the
authorized CAs/individual certs’, there is no way to express same things with
raw public keys (or you wind up with new X509, which is in nobody’s best
interest).
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and
you don't need CA's. See RFC4871 for an example.
On 9/18/2014 11:36 AM, Michael Thomas wrote:
On 09/18/2014 08:31 AM, Markus Stenberg wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote:
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and you
don't need CA's. See RFC4871 for an example.
I would have thought it
On 9/18/14, 8:57 AM, David R Oran wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote:
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and you don't
need CA's. See RFC4871
Self-signed certs bring only confusion, IMO: they are nothing more than a
raw key with an unsubstantiated claim to another name, along with a whole
lot more ASN.1 baggage beyond what is needed to parse the modulo and
exponent.
And you don't get usage or policy restrictions without a CA that
On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
Self-signed certs bring only confusion, IMO: they are nothing more than a
raw key with an unsubstantiated claim to another name, along with a whole
lot more ASN.1 baggage beyond what is needed to parse the modulo and
exponent.
And you don't get
On Sep 18, 2014, at 8:57 AM, David R Oran daveo...@orandom.net wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote:
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and
And all of this was covered in the design for UPnP Device Protection that you
referred to earlier and its progenitor UPnP Device Security. I consider HNCP
security to be a small subset of the UPnP device requirements.
Mark
On Sep 18, 2014, at 2:10 PM, STARK, BARBARA H bs7...@att.com wrote:
some talk about using web of trust,
but I don't understand how that would work.
Mark
Original message
From: Michael Thomas m...@mtcc.com
Date:09/18/2014 4:17 PM (GMT-06:00)
To: homenet@ietf.org
Cc:
Subject: Re: [homenet] HNCP security?
On 9/18/14, 2:10 PM
On 19/09/2014 09:17, Michael Thomas wrote:
On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
Self-signed certs bring only confusion, IMO: they are nothing more
than a
raw key with an unsubstantiated claim to another name, along with a
whole
lot more ASN.1 baggage beyond what is needed to parse
)
To: Randy Turner rtur...@amalfisystems.com
Cc: homenet@ietf.org Group homenet@ietf.org
Subject: Re: [homenet] HNCP security?
On Sep 18, 2014, at 2:37 PM, Randy Turner rtur...@amalfisystems.com wrote:
How do you bootstrap trust relationships without an initial certificate
(whether installed
On 9/18/14, 3:39 PM, Brian E Carpenter wrote:
Yes, I agree and that's why self-signed and/or manufacturer certs are of
no help.
Surely they are of help for secure *identification* of devices?
No more so than the naked public key.
Authorisation is a separate step.
Yes.
There is no
:12 PM (GMT-06:00)
To: Randy Turner rtur...@amalfisystems.com
Cc: homenet@ietf.org Group homenet@ietf.org
Subject: Re: [homenet] HNCP security?
On Sep 18, 2014, at 2:37 PM, Randy Turner rtur...@amalfisystems.com wrote:
How do you bootstrap trust relationships without an initial
On 9/18/14, 3:43 PM, Randy Turner wrote:
Are we assuming that the home router is purchased retail, and not
fulfilled or provided by an ISP? The method to establish trust
relationships would hinge on the answer
I should be able prepurpose an old PC with linux running homenet
software. We
smartphone
Original message
From: STARK, BARBARA H bs7...@att.com
Date:09/18/2014 5:02 PM (GMT-06:00)
To: Randy Turner rtur...@amalfisystems.com, Michael Thomas m...@mtcc.com,
homenet@ietf.org
Cc:
Subject: RE: [homenet] HNCP security?
How do you bootstrap trust relationships
On Tue, 16 Sep 2014, Tim Chown wrote:
There’s obviously some interesting implications of this. One is that
there are insecure wired links too!
Good point. I believe we're hitting the classic secure or easy tradeoff.
There is no way we automatically can detect what is home and what is not,
Tim Chown t...@ecs.soton.ac.uk wrote:
On 16 Sep 2014, at 14:52, Michael Richardson mcr+i...@sandelman.ca
wrote:
I think that we can assume that wired links are secure. The only time
we care if wireless is secured is when we want to form an adjacency
over the
On 09/17/2014 06:37 AM, Michael Richardson wrote:
Michael Thomas m...@mtcc.com wrote:
I further suggest that if two routers have wireless that they might
well have a WPA2/PSK available to them, and that they can and SHOULD
use something derived from that key to authenticate
On 09/16/2014 11:31 PM, Mikael Abrahamsson wrote:
As was presented in.. err, London?, shared secrets are bad. To really
do this properly, we need device specific keys and some kind of list
of devices that are allowed to connect, perhaps by having their
public keys in HNCP. I don't know. I am
On 9/17/14, 10:24 AM, Michael Richardson wrote:
Michael Thomas m...@mtcc.com wrote:
If I have more than one SSID, which PSK should the router use?
Whichever ones authenticates the message. The PSK is not transmitted.
I'm about to send a routing update, or whatever
On 18/09/2014 02:58, Michael Thomas wrote:
On 09/16/2014 11:31 PM, Mikael Abrahamsson wrote:
As was presented in.. err, London?, shared secrets are bad. To really
do this properly, we need device specific keys and some kind of list
of devices that are allowed to connect, perhaps by having
On Wed, 17 Sep 2014, Michael Thomas wrote:
Global symmetric keys certainly have their problems, but using public
keys have their own. Namely, if I want to enroll a new device each other
currently enrolled device needs to know about the public key of the new
enrollee. For 2 devices, that's
Michael Thomas m...@mtcc.com wrote:
I'm pretty certain that the answer to this is going to be no. does
zigbee even have link layer crypto, for example? and even if it does,
new ones as they come on line are likely to have flaws for a long time
(cf wifi).
zigbeeIP mandates
Markus Stenberg markus.stenb...@iki.fi wrote:
markus What the draft does not cover is what is the assumption about
markus security of protocols within it. If HNCP is run only over either
markus physically or cryptographically secured link layer, there are no
markus real extra
On 16 Sep 2014, at 14:52, Michael Richardson mcr+i...@sandelman.ca wrote:
I think that we can assume that wired links are secure.
The only time we care if wireless is secured is when we want to form an
adjacency over the wireless link. I think it is acceptable to refuse
to form an
On Sep 16, 2014, at 1:29 PM, Tim Chown t...@ecs.soton.ac.uk wrote:
There’s obviously some interesting implications of this. One is that there
are insecure wired links too!
That's a good point. And I wonder about malware on end systems as well.
Mark
Hello everyone,
1) Can we assume secure L2 and/or appropriate device configuration by the
manufacturer/ISP(/user)? (This is what I can assume in my own home.)
I think secure L2 is not enough for HNCP (and routing protocol) security.
*Assuming* we have it, either we allow any connected
On 13.9.2014, at 20.27, Michael Thomas m...@mtcc.com wrote:
I think we should be clear that hijacking router-router traffic brings a whole
new class of breaches that home networks are probably not particularly
susceptible
to today. An active man in the middle is a very bad thing and that
On 13.9.2014, at 23.30, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
On 13/09/2014 17:40, Markus Stenberg wrote:
1) Can we assume secure L2 and/or appropriate device
configuration by the manufacturer/ISP(/user)? (This is what I
can assume in my own home.)
I'm not sure I fully
Brian, et al,
L2 never really was secure, regardless of whether we are talking about
enterprise or home networks, wired or wireless. Sure there was a
firewall in place, but the L2 and the subnet behind the firewall was
only as secure as the least secure device that ever connected to it.
Which
On 14.9.2014, at 17.48, Michael Thomas m...@mtcc.com wrote:
On 09/14/2014 02:04 AM, Markus Stenberg wrote:
On 13.9.2014, at 23.30, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
All true (as are the subsequent comments by Acee and Michael).
But the fact remains that we can't assume
On 09/14/2014 09:38 AM, Markus Stenberg wrote:
Like I stated earlier in my email, if you do not assume secure L2,
just securing router-to-router traffic does little to protect the
homenet.
The subject line says HNCP security, so I naively thought that's what
this was about.
So the real
On 15/09/2014 03:59, Curtis Villamizar wrote:
Brian, et al,
L2 never really was secure, regardless of whether we are talking about
enterprise or home networks, wired or wireless. Sure there was a
firewall in place, but the L2 and the subnet behind the firewall was
only as secure as the
I agree with Markus. The conflicting goals of self-configuration and
security seem to be a recurring theme in homenet. I reread the security
section in the ³Homenet Architecture² and it mainly covers with security
at the edges (which presumes effective edge detection). There is this
statement
On 09/13/2014 10:16 AM, Acee Lindem (acee) wrote:
I agree with Markus. The conflicting goals of self-configuration and
security seem to be a recurring theme in homenet. I reread the security
section in the ³Homenet Architecture² and it mainly covers with security
at the edges (which presumes
87 matches
Mail list logo
