On Sep 16, 2014, at 2:12 PM, normen.kowalew...@telekom.de wrote:
> Hi,
>
> Regarding
>
> * draft-mglt-homenet-front-end-naming-delegation
> * draft-mglt-homenet-naming-architecture-dhc-options
>
> I think this is useful work and support its adoption.
>
> However, I’d like to see these d
Yes I was only stating that establishing a root of trust for device
authentication seems to work - as Brian said, authorization is a different
thing. However, authorization might be assisted by an existing trust
relationship for identity.
Randy
Sent from my Verizon Wireless 4G LTE smartphon
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
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 that CPE wanted to be compliant to a future HNCP security standard.
Mark
On Sep 18, 2014, at 3:43 PM, Randy Turner wrote:
> Are we
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 beli
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
Randy
Original message
From: Mark Baugher
Date:09/18/2014 5:12 PM (GMT-06:00)
To: Randy Turner
Cc
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
On Sep 18, 2014, at 2:37 PM, Randy Turner wrote:
> How do you bootstrap trust relationships without an initial certificate
> (whether installed at manufacturing or during a customer fulfillment stage) ?
One way is through a user "security ceremony" (viz. Walker and Ellison) in the
Wi-Fi and U
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 wrote:
>> Self-signed ce
On Sep 18, 2014, at 8:57 AM, David R Oran wrote:
>
> On Sep 18, 2014, at 11:46 AM, Rene Struik 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 R
> How do you bootstrap trust relationships without an initial certificate
> (whether installed at manufacturing or during a customer fulfillment stage) ?
There's a difference between trusting (authenticating) a device when it says
"this is my key; whenever you see this key you can trust that it'
How do you bootstrap trust relationships without an initial certificate
(whether installed at manufacturing or during a customer fulfillment stage) ?
Original message
From: Michael Thomas
Date:09/18/2014 4:17 PM (GMT-06:00)
To: homenet@ietf.org
Cc:
Subject: Re: [homene
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 usage
> 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
On 9/18/14, 8:57 AM, David R Oran wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik 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 wou
On 09/18/2014 08:57 AM, David R Oran wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik 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 w
On Sep 18, 2014, at 11:46 AM, Rene Struik 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 was the opposite
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:
whethe
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).
Anyt
On 09/18/2014 08:24 AM, Markus Stenberg wrote:
With device certificates, you still have the original authz problem. That is,
just because I can identify you
reliably tells me nothing about whether I want to participate with routing
updates with you. So in that
way, they not any more useful th
On 3 Sep 2014, at 14:38, Ray Bellis
mailto:ray.bel...@nominet.org.uk>> wrote:
This email commences a two week period for comments relating to the adoption of
the following drafts by the HOMENET Working Group, as promised during our WG
session in Toronto:
draft-pfister-homenet-prefix-assign
Whether or not you do leap of faith, certificates _do_ provide extra value.
- you can produce them/validate via (local / cloudy) CA (which may also imply
authorization in addition to authentication, or not)
- you can have them from hardware (which makes producing spurious ones much
harder, assu
On 18.9.2014, at 18.17, Michael Thomas wrote:
> On 09/18/2014 06:49 AM, Markus Stenberg wrote:
>> On 18.9.2014, at 16.05, Ted Lemon wrote:
>>> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H wrote:
X.509 certificates can be self-signed. That is, the device acts as its own
CA. In fact, t
On 09/18/2014 06:49 AM, Markus Stenberg wrote:
On 18.9.2014, at 16.05, Ted Lemon wrote:
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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
Hi,
Regarding
* draft-mglt-homenet-front-end-naming-delegation
* draft-mglt-homenet-naming-architecture-dhc-options
I think this is useful work and support its adoption.
However, I'd like to see these drafts generalized so that mechanisms to provide
authorization credentials towards the DNS ar
One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
I guess then you could go all the way and use the whole DTLS for HNCP
unicast traffic (and keep MC unencrypted since its more or less a
signaling channel for UC and doesn't c
On 18.9.2014, at 16.05, Ted Lemon wrote:
> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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 all. Self-sig
On 09/18/2014 04:50 AM, Michael Sweet wrote:
One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
Another is that the same cert can be used for TLS negotiation in embedded web
services, etc. to each device.
And of course if the
Dear colleagues:
I have seen a lot of emails with the "HNCP security" heading. However,
is there a concise technical description of the security services to be
provided, the trust lifecycle of a device and network, including
configuration and authorization model?
The description below seems
One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
Another is that the same cert can be used for TLS negotiation in embedded web
services, etc. to each device.
And of course if the registration mechanism is integrated into clie
> > 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 e
On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H 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.
I think that something like this, in combination with the promiscuous
registr
On 16.9.2014, at 16.52, Michael Richardson 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
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 sel
35 matches
Mail list logo
