Subject: Re: [homenet] Creating a security association via physical link + button

From: Randy Turner <[email-masked]>
Date: Fri, 25 Nov 2011 04:30:08 -0800

I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should "trust" that route updates from router B are correct. That being said, this is just an intuitive feeling regarding security - maybe we need someone to work on a threat analysis and what the implications could be to the types of applications we anticipate

Randy

-------- Original message --------
Subject: Re: [homenet] Creating a security association via physical link +	button 
From: Mark Townsley <[email-masked]> 
To: Ted Lemon <[email-masked]> 
CC: Russ White <[email-masked]>,[email-masked],Lorenzo Colitti <[email-masked]> 

On Nov 25, 2011, at 3:42 AM, Ted Lemon wrote:

On Nov 24, 2011, at 7:46 PM, Lorenzo Colitti wrote:
Ok, so it would seem to me that to support that case then we need to either a) support multiple simultaneous keys in the IGP or b) provide a mechanism to tell a number of homenet routers that "the key to the IGP is changing". Both are non-trivial. Any other ideas?

I think a security model that doesn't have each router generating its own keys, and using public key cryptography, is doomed.   If you use a shared secret, it's too easy to pwn your network because it has to be exchanged in the clear.   If the IGP protocol we want doesn't support this, then it pretty much has to be fixed, or we just can't do this.

In the email I just sent, I'm making an argument for why this is not the case. An IGP in a homenet setting needs crypto security no more than DHCP, ND or mDNS would. It's just another configuration protocol within the home. 

Yes, this means that we need to trust L2 or physical security. But that's already very much the case today. If we add keys and crypto at every layer we are doomed before we start on usability alone. 

- Mark

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Nov 2011 12:28:01 -0500

On Nov 25, 2011, at 7:30 AM, Randy Turner wrote:
> I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should "trust" that route updates from router B are correct.

Exactly.

> That being said, this is just an intuitive feeling regarding security - maybe we need someone to work on a threat analysis and what the implications could be to the types of applications we anticipate

Yes, I think this would be worthwhile.   I'm certainly arguing based on intuition at the moment.

---

From: Mark Townsley <[email-masked]>
Date: Sat, 26 Nov 2011 02:17:36 +0100

>> I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should "trust" tha…

I see no difference really between the difficulty between an integrity-only solution and a confidentiality solution. Both require keys. It's the keys that are the real problem, not the work done on the packets.

And, yes, key exchange being hard is based on a certain amount of intuition for my part as well. 

- Mark

---

From: Randy Turner <[email-masked]>
Date: Fri, 25 Nov 2011 22:18:05 -0800

You maybe right about the equivalent key-management scope, however, I believe any work in the key distribution area applied to the "integrity of routing updates" would pay off more than expending this effort on the "confidentiality of routing update" problem.  One of the devices we are considering as a "router" in the Homenet is a Windows machine where the end user has simply turned on internet connection sharing (ICS).  Assuming this machine is their home PC, we're talking about the target of practically every attack profile on the internet, so I think it's worth the effort to establish a trust model.  Even an android-based phone could inject false (untrusted) routes into the Homenet, but then again I'm getting ahead of myself in pre-supposing attack vectors on the Homenet.  I'm keeping an open mind on all of this until we have a document or other work that performs the due diligence on threats to the Homenet.

Randy

---

From: Robert Cragie <[email-masked]>
Date: Sat, 26 Nov 2011 09:52:44 +0000

I've been following this thread with interest. Some points (from someone 
who has a particular 802.15.4-based mesh networking viewpoint):

  * There probably isn't any need to specify cryptographic security for
    an IGP on the basis that the packets are link-local and can
    therefore be protected at L2.
  * Network access control can set up secure channels to deliver keying
    information. Therefore in theory this can be used to deliver keying
    information for any protocols, although in practice it is often just
    L2 keying information. The focus then turns to which credentials are
    used for network access control. Whilst I support the use of public
    key crypto., it is not essential for homenet and there are solutions
    (not perfect, IMHO, but adequate) which exist now for easy joining
    (e.g. WPS) based on a pre-shared key/passphrase. Having said that,
    the burden and complexity of using public key crypto. for network
    access and mutual authentication is perhaps not as great as one may
    think.
  * The original question was about merging networks in the home. Again,
    I don't think it is that complex if dealt with from a network access
    point of view. Whether one becomes secondary and assumes the keying
    information from the primary network (probably preferable if the
    topology is a mesh) or the two simply join at a common router and
    retain their own keying information, either is possible and not
    difficult.

Robert

On 26/11/2011 6:18 AM, Randy Turner wrote:
>
> You maybe right about the equivalent key-management scope, however, I 
> believe any work in the key distribution area applied to the 
> "integrity of routing updates" would pay off more than expending this 
> effort on the "confidentiality of routing update" problem.  One of the 
> devices we are considering as a "router" in the Homenet is a Windows 
> machine where the end user has simply turned on internet connection 
> sharing (ICS).  Assuming this machine is their home PC, we're talking 
> about the target of practically every attack profile on the internet, 
> so I think it's worth the effort to establish a trust model.  Even an 
> android-based phone could inject false (untrusted) routes into the 
> Homenet, but then again I'm getting ahead of myself in pre-supposing 
> attack vectors on the Homenet.  I'm keeping an open mind on all of 
> this until we have a document or other work that performs the due 
> diligence on threats to the Homenet.
>
> Randy
>
>>>> I think I agree that confidentiality of routing traffic is probably 
>>>> not an issue for Homenet - however, I do think we should consider 
>>>> integrity of routing traffic - ie, router A should "trust" that 
>>>> route updates from router B are correct.
>>>
>>> Exactly.
>>
>> I see no difference really between the difficulty between an 
>> integrity-only solution and a confidentiality solution. Both require 
>> keys. It's the keys that are the real problem, not the work done on 
>> the packets.
>>
>>>> That being said, this is just an intuitive feeling regarding 
>>>> security - maybe we need someone to work on a threat analysis and 
>>>> what the implications could be to the types of applications we 
>>>> anticipate
>>>
>>> [email-masked] <mailto:[email-masked]>

---

From: Acee Lindem <[email-masked]>
Date: Sat, 26 Nov 2011 07:05:54 -0500

I agree - once we have a threat document, this should one of the security models on which we map the threats. 
Thanks,
Acee
On Nov 26, 2011, at 4:52 AM, Robert Cragie wrote:

> I've been following this thread with interest. Some points (from someone who has a particular 802.15.4-based mesh networking viewpoint):
> 
> There probably isn't any need to specify cryptographic security for an IGP on the basis that the packets are link-local and can therefore be protected at L2.
> Network access control can set up secure channels to deliver keying information. Therefore in theory this can be used to deliver keying information for any protocols, although in practice it is often just L2 keying information. The focus then turns to which credentials are used for network access control. Whilst I support the use of public key crypto., it is not essential for homenet and there are solutions (not perfect, IMHO, but adequate) which exist now for easy joining (e.g. WPS) based on a pre-shared key/passphrase. Having said that, the burden and complexity of using public key crypto. for network access and mutual authentication is perhaps not as great as one may think.
> The original question was about merging networks in the home. Again, I don't think it is that complex if dealt with from a network access point of view. Whether one becomes secondary and assumes the keying information from the primary network (probably preferable if the topology is a mesh) or the two simply join at a common router and retain their own keying information, either is possible and not difficult.
> Robert
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 26 Nov 2011 13:24:03 -0500

On Nov 26, 2011, at 4:52 AM, Robert Cragie wrote:
> Network access control can set up secure channels to deliver keying information.

It sounds like you're talking about some kind of central management software/protocol here.

---

From: Robert Cragie <[email-masked]>
Date: Mon, 28 Nov 2011 22:12:03 +0000

Not necessarily. It could centralized, it could be distributed or 
collaborative. Generally most edge networks have an access policy; it is 
rare to find a true open access network these days. If there is a 
network access policy, a single node generally has to act as 
authenticator for the purposes of network access (e.g. 802.1X/PANA/EAP 
model). However, the capability to authenticate and authorize could be 
distributed. Considering a ubiquitous model in the home now, there is an 
access point which acts as authenticator based on nodes joining with a 
pre-shared key/passphrase, so that is a centralized function. Consider 
how to extend that model to other networks in the home; if the homeowner 
essentially manages all the networks then other networks could simply 
become subordinate and assume security parameters of the primary 
network. If there is a need for another peer network, these could keep 
their own security parameters and a common node would need to be 
authenticated on both. When it comes to actual packet security, there 
are also a number of possibilities, including group keying, network-wide 
keying or, depending on the network topology, node to access point keying.

Robert

---

From: Mark Baugher <[email-masked]>
Date: Mon, 28 Nov 2011 15:57:32 -0800

In my experience, there is no single mechanism for establishing what is alternatively called 'pairing,' 'introduction,'  'enrollment,' on in the case of the WiFi Protected Setup a 'mental model.'  The techniques have been called "ceremonies" by Carl Ellison and Jesse Walker, and they serve as a replacement for a system administrator in an unmanaged network by automating the process of adding an authorization, such as to a public key, username/password or other credential.  The security rests on showing locality and control of the device, which doesn't work well if the gateway or device is in some publicly-accessible location, which is usually not the case in a home.  The efficacy of any particular technique depends on the capabilities of the devices that are being paired.  Some research at UC-Irvine, for example, suggests that a short authentication string is the most usable method for most people in cases where there is a keypad or display.  In other cases, the USB key and push-button configuration techniques may be suitable.   I am not aware of any studies that push button is a particularly intuitive HCI for most people.   PBC uses weak identification and has a lot of vulnerabilities that require various mechanisms such as "walk time" in the WPS specification.

For homenet, I would expect that we would use or adapt the 'mental models' of the WiFi Alliance for our purposes.   Or at least we should consider this course.  In the case of the NFC mental model, I believe that particular method has been withdrawn by the WFA due to a dearth of shipped implementations that use it.  I am also not aware of interoperable implementations of the USB key WPS technique.  As I understand it, new techniques can be introduced or deprecated techniques can be re-introduced at the behest of interested parties.

Mark