RE: [LinkSec] teleconf notes 4/15/03
I believe I agree with David, having read his comment a couple of times.
Other approaches (network survivability with untrustworthy intermediate
participants) is or was a resarch topic, possibly solved but not with the
level of implementation experience required for standardization.
I've thought a little about the network survivability/recovery requirements
in scenarios where the points to trust are not clear from the outset, and
for the moment I believe that we will inevitably come back to assuming that
all bridges are adjacent (i.e. they are either physically adjacent or there
is a secure tunnel subject to my next paragraph that has been already setup
and not modified by our efforts) and the bridges are all secured (by the
mechanisms we define). I've heard strong views that no one is going to
sacrifice the recent advances in rapid recovery etc. of layer 2 nets for
security, nor are those who have talked to me happy with the idea that the
customer gets a choice between up-time and security.
It also seems likely that we will make heavy use of tunnels because, in the
absence of the invention of YAPP (yet another policy protocol), most of what
gets said by authorized administrators to any pair of entities that
constitute a temporary network boundary (supplicant authenticator bridge
pairs in the .1X model) to set up the ongoing parameters of the permeable
membrane that boundary will form will be said in existing protocols. In this
context the Housely et al. RFC on the need for secure binding to the tunnel
to avoid the man in the middle attack seems to me to be the defining element
of the overall architecture (I think this was what Paul Congdon's
presentation last meeting was mainly saying). I apologise for not being able
to participate in the architectural telecons so far .. in the absence of
participating in these I so far believe that the setting up and binding to
these tunnels of subsequent conversations is going to be a major part of
"principles of operation" of the eventual solution.
I'd go along with Norm's suggestion that we treat untrusted bridges as
"down" (there are a number of ways of saying the same thing). Of course on
shared media that is not the end of the story, as they may bring the
attached LAN down as well.Some pragmatic drawing of the boundaries of
consideration (or non-consideration) of threats is needed here, particularly
for EPON. On point to point media of course this just the .1X model.
It may be argued that we should accomodate intermediate untrusted bridges
from the outset, taking such steps as putting the .1Q tag in clear as well
as protecting it. This is the standard standards approach and that of the
responsible reasonable engineer. Most of the progress .1 has made in the
past has been (IMHO) due to the ability to identify such never ending cases
of distraction and project enlargement and take an axe to them right from
the start.
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Johnston,
Dj
Sent: Thursday, April 17, 2003 4:28 PM
To: LinkSec
Subject: RE: [LinkSec] teleconf notes 4/15/03
Norm,
My suspicion is that your final model, where untrusted bridges are not used
directly, is the only appropriate one. Here's why, of course with my slant
towards roaming issues being apparent:
1) Either you are within an administrative domain in which you can expect a
trust relationship with bridges to be set up (E.G. a company intranet) or
you are not. E.G. you may be roaming around WiSPs or calling your ISP,
neither of whom you have any reason to trust.
2) An untrusted bridge on a net is no different to any other untrusted node.
Its connected to the net and is free to do whatever you let it get away
with. For a certain class of roaming nodes and some non roaming nodes, these
untrusted nodes will be a fact of life.
3) If you are necessarily communicating over untrusted links (such as via
your ISP), then you should really be doing end to end tunneling or
encryption to a trusted endpoint for any data you feel needs protecting in
some way, since you can't trust the intermediaries. This is accepted
practice at higher layers (SSL). Any attempt to bring untrusted third
parties into a three party trust model is doomed to become complex and
probably broken.
4) If someone sets up L2 tunnels (carrying control, data and all) to build a
single trusted graph out of islands of trusted graphs in an untrusted sea,
then a solution that avoids untrusted nodes isn't going to need to be able
to tell the different between a link to a trusted L2 node and a secure
tunnnel to a trusted node via untrusted nodes. Bringing specification of
those tunnelling methods into the link security solution would unduly limit
the range of L2 tunneling solutions that people might want to invent in the
future. So you may as well just stick with avoiding untrusted nodes and
letting secure L2 tunnels fool you into using them if the network is so
administered.
5) If you expect your L2 links to be trustworthy and someone turns up and
plugs in an untrusted link and no administrative intervention has taken
place to render it trustworthy, then the last thing you want to do is send
your data over it.
6) Whatever a tunneled-over untrusted link wants to do with its 802.1Q tags
is its own business. The tunnel should be protected the 802.1Q tags of the
virtual link and carrying them end to end. Since the link is untrusted, you
can't trust it to perform to any QoS parameters anyway.
I suspect the two common cases are
1) The untrusted network hosting some trusted entities somewhere (like your
bank).
2) The trusted network that is managed within a single administative domain
(like a company intranet).
The world is going to have to deal with case 1 anyway, and commonly does so
with SSL, so why not make your life easy and optimise case 2 for those
situations where it applies in the domain of 802.
The flaws in my thinking will be clear to most people except me.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: Norman Finn [mailto:nfinn@cisco.com]
> Sent: Thursday, April 17, 2003 3:28 PM
> To: Mats Näslund
> Cc: LinkSec
> Subject: Re: [LinkSec] teleconf notes 4/15/03
>
>
>
> Mats,
>
> You raise a very good question -- can bridges create tunnels through
> untrusted bridges in order to keep the network up in the face of
> compromised equipment? Protecting the .1Q tag is necessary, but not
> sufficient, to allow this.
>
> The problem is that 802.10 is *not* a true tunneling technology. In
> particular, the untrustworthy bridge will stop a BPDU whether it is
> encrypted or not, because an encrypted BPDU would still have the
> standard BPDU destination MAC address.
>
> So, the trusted bridges must either allow the untrusted bridges to
> participate in the Layer 2 protocols such as RSTP, GMRP, and GVRP,
> or must somehow discover each others' presence in spite of the
> intervening untrusted bridges, and construct tunnels that will allow
> them to pass their Layer 2 control protocols (and data, of course)
> through the untrusted cloud. The first solution will take some
> considerable effort to analyze, but my first reaction is to dismiss
> it as a possibility. The second solution seems reasonable, but I'm
> not sure how it could be done except by manual configuration, plus
> it requires us to invent a new kind of L2-over-L2 tunneling mechanism.
>
> I have no opinion, yet, on whether the first documents produced by
> the group should or should not be required to accommodate intermediate
> untrusted bridges. Remember that another possibility is to treat the
> untrusted bridge and all the links to it as being down, and relying
> on other paths, which presumably will be present, to carry the data.
>
> -- Norm
>
> Mats Näslund (EAB) wrote:
> >
> > Hi all,
> >
> > I have a question concerning the conclusions (I make) of the meeting
> > notes below. (My apologies for not being able to attend so far; the
> > time of day in combination with day of week makes it very
> difficult.)
> >
> > Allyn Romanow wrote:
> > >
> > > Discussion
> > > Bob - threats only to links themselves, bridges not protected
> > > threats to L2 structure
> > > if bridge is corrupted, it's not considered part of the relevant
> > > architecture
> >
> > I don't get this. If this is the assumption made, then won't it
> > be absolutley *necessary* to be able to "tunnel" the security
> > through such a corrupted bridge? This seems to contradict the
> > conclusion in the summary above (and elsewhere) that: "end to end
> > security through an arbitrary bridged topology is considered not
> > sufficiently understood to be undertaken at the current time".
> >
> > My point is that if there is a case when you might need to tunnel
> > one bridge, you might in other cases need to tunnel through
> N bridges,
> > which asymptotically means e2e.
> >
> > Moreover, refering to Norm's tutorial from Dallas, the last slide
> > states: "end-to-end security associations transported
> through bridges
> > must not authenticate the 802.1Q tag".
> >
> > Now, if there indeed could exist corrupt bridges as mentioned above
> > that are defined "out" of the relevant architecture, I feel very
> > worried about such a bridge messing with my 802.1Q tags... Thus,
> > bridges that *are* part of the relevant arch. SHOULD have the
> > option to e2e protcet 802.1Q tags that are important to them,
> > and could need to pass the corrupt bridge.
> >
> > Again, my aplogies if my confusion is caused by not being able
> > to attend the phone conf.
>