Subject: Re: [homenet] homenet hosts security requirements and realm discovery

From: Dmitry Anipko <[email-masked]>
Date: Sun, 5 Aug 2012 00:18:54 +0000

Hi Curtis,

Re terminology, I used the term "realm" as it is defined/used in draft-ietf-homenet-arch-04, and not in some other meaning. I think there are two major points in your email I want to comment on:

1. Whether or not the draft already provides that realm information is available to all participants of the homenet, including hosts.

2. Whether or not security decisions made on hosts can or should use/be based on such realm information.

On the first point, I agree that the text in section 3.3.1 could be understood in a way that the realm information is known to the homenet and hence hosts can access it. However I think the current text is fairly high level and can also be understood differently - that e.g. *routers*, which happened to be on the respective borders, shall be able to discover those borders of the realms and perform filtering correspondingly to the definition of realms. If sharing of the realm information with all participants of the homenet is already implied by 3.3.1, there should be no issue to say that more explicitly.

For the second point:

The current text says in 3.3.1 that " then the borders will include ...that from the homenet to a guest network...for an appropriate default policy to be applied as to what type of traffic/data can flow across such borders" This seems to match the intuitive meaning of "guest" vs "homenet" realms, which implies that "guest" doesn't have exactly the same access as "homenet". The text I'd like to see added would simply provide that hosts, which opted into transparent communication, are able to implement the same richness and easiness of access control as the routers do. 

Also, a typical user can understand that they need provide credentials when they are remote (i.e. coming from the Internet, from outside of "their network"), but they often have hard time to understand why they or their visiting mom who they joined to home WiFi are also asked to provide user creds if they are already connected to their own network either using cable or secure WiFi, and they've chosen previously "share with everyone at home".  For better or worse, today physical proximity matters and layer 2 access control is often perceived as easier to understand and use rather than layer 7 authentication (that of course also means, we have work to do :) ). And section 3.6.3 doesn't prohibit such usage of realm information.

-Dmitry

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2012 2:31 PM
To: Dmitry Anipko
Cc: [email-masked]
Subject: Re: [homenet] homenet hosts security requirements and realm discovery

In message <[email-masked]>
Dmitry Anipko writes:
 
> In draft-ietf-homenet-arch-04, I was looking for and could not find a
> requirement for the network to provide homenet hosts with the
> information about the realms - as a basic example, which prefixes are
> associated with the most trusted homenet realm, as opposed to
> guest/Internet.
>  
> For the hosts, described in section 3.6.3, which opt into transparent
> inbound communication, this capability would be useful to enable on
> the host scenarios such as "share resource A, require user
> authentication for guest/Internet realms and don't require for
> homenet", or "share resource B within the homenet only, while share
> resource C with all realms".
>  
> Is there already a section that implies such requirement, or if not,
> are there concerns with adding such requirement to the draft?
>  
> -Dmitry

Dmitry,

Look at the first sentence in section 3.3.1.  "The homenet will need
to be aware of the extent of its own 'site', which will define the
borders for ULAs, site scope multicast, service discovery and security
policies."

A host gets connected to a realm and the realm simply determines the
boundary of where the ULA, site scope multicast, etc is propogated
beyond the local subnet.  In many cases a realm consists of one local
subnet.  Borders in this case imply a firewall, though the realms
could have a null firewall (pass everything) if security is
accomplished using IPSEC, TLS, or applications layer security.

In a current enterprise, internal WiFi users are connected to a subset
of channels with slightly stronger authentication.  Guest within the
building may use a shared password authentication given to them when
they enter the building or none at all (open WiFi if the building has
RF shielding or the campus is large enough that WiFi range doesn't
extend beyond the campus (or both).

Section 3.6.3 does not imply that host security should be based on the
homenet realm.  A host security using TLS for example should be
applied the same regardless of the homenet realm.  For example, a
connection from a mobile phone (without WiFi) would come from the
external internet homenet realm.

Firewalls should only block access to insecure or very weakly secured
services behind the firewall.  IMHO there should be no insecure or
very weakly secured services anywhere.  If so, there is no need for a
firewall.  (BTW - the 1990s T3-NSFNET infrastructure and NMS had no
firewalls and was quite secure even by today's standards, much more
secure than most enterprises that I have encountered).

This has nothing to do with any notion of domain, realm, etc in
Windows (or krb5/gssapi) if that is the question.

Curtis