RE: [LinkSec] Consensus on Scope?
This is a very good observation. It is especially important in wireless
environments where physical location may not provide the clue about the
appropriate credentials for a particular authentication exchange.
Russ
At 12:58 PM 4/24/2003 -0700, CONGDON,PAUL (HP-Roseville,ex1) wrote:
>The timing of discovery can be very important in light of security and
>authentication. For example, it might be nice to discover what network
>service is out there in order to select an appropriate identity to
>authenticate. This would imply running some signaling protocols prior to
>authentication protocols.
>
>Paul
>
>-----Original Message-----
>From: Dolors Sala [mailto:dolors@ieee.org]
>Sent: Thursday, April 24, 2003 10:45 AM
>To: Mats Näslund; LinkSec; Russ Housley
>Subject: Re: [LinkSec] Consensus on Scope?
>
>
>
>Russ,
>
>If the only issue is peer discovery, isn't this signaling that can be
>specified (or selected) any time? if so, what is the problem (or your
>concerns) in doing it later and start with a link solution?
>
>Dolors
>
>----- Original Message -----
>From: "Russ Housley" <housley@vigilsec.com>
>To: "Dolors Sala" <dolors@ieee.org>; "Mats Näslund"
><mats.naslund@era.ericsson.se>; "LinkSec" <stds-802-linksec@ieee.org>
>Sent: Thursday, April 24, 2003 10:36 AM
>Subject: Re: [LinkSec] Consensus on Scope?
>
>
>Dolors:
>
>I think that the only contentious issue is peer discovery. Mick and others
>have said that the probe approach specified by 802.10 does not scale. No
>convincing argument has been presented. So far, it is just emphatic
>assertion with the promise of a more complete discussion some time over a
>beer. I observe that the probe approach is not all that different than ARP,
>so it cannot be too badly broken.
>
>The link-by-link approach completely avoids peer discovery. However, I am
>not convinced that this approach really resolves any important problems. It
>seem to me that the device that is implementing the security protocol will
>be placed in the hands of the customer. If the customer messes with it, can
>all traffic be exposed. In an end-to-end scheme, the key needed to expose
>neighbor traffic will not be present, significantly reducing the motive for
>messing with the box.
>
>Russ
>
> At 07:01 AM 4/23/2003 -0400, Dolors Sala wrote:
> >Russ, Mats,
> >
> >I understand your concerns but we need to identify a work plan to make
> >some progress towards the current needs represented by the interests
> >and participation in the group.
> >
> >It seems to me there is significant interest in working on the
> >link-by-link protection, and very little interest on the end-to-end
> >security solution right now. If this interest is correct, we need to
> >work on how we can characterize this first effort so that it addresses
> >the immediate needs and is an step forward towards a unified
> >architecture. It would be great if you can prepare material on the
> >needs imposed by the unified architecture to the link solution.
> >
> >My specific suggestion or question was to explore if it is possible to
> >characterize the unified architecture in a set of requirements that can
> >be imposed to the link solution. Another way to express this could be.
> >
> >Let's say that the unified end-to-end solution defines a complete
> >"link-layer security architecture". A link-layer solution would cover a
> >complete L2 network security solution including the secure bridge
> >network and the single link secure communication. But we would like to
> >focus just on the single link solution component. So we need to define
> >a link security architecture solution with the right hooks so that it
> >is possible to build a complete link-layer solution on top of it. What
> >is the best way to characterize these hooks? Is a list of requirements
> >enough? if so, what are the requirements we would like to impose to the
> >link security architecture?
> >
> >Russ, based on 802.10 and other IEEE security experiences,
> >can you recommend a list of requirements or other form of material to
> >capture this characterization?
> >
> >We need a framework expressing the extendibility needs of the link
>solution.
> >Any material or contribution on this respect will be very helpful.
> >
> >Dolors
> >
> >
> >
> >
> >----- Original Message -----
> >From: "Mats Näslund" <mats.naslund@era.ericsson.se>
> >To: <stds-802-linksec@ieee.org>
> >Sent: Wednesday, April 23, 2003 3:58 AM
> >Subject: Re: [LinkSec] Consensus on Scope?
> >
> >
> > >
> > >
> > > Hi,
> > >
> > > I completely agree. Since the general bridged architecture is
> > > considered difficult to handle, I am slightly worried that corners
> > > will be cut so that later extensions beyond link-by-link protection
> > > becomes cumbersome (or even impossible). It could thus be that we
> > > need to "almost" solve also the general case at the same time to be
> > > future proof.
> > >
> > > Best,
> > >
> > > /Mats
> > >
> > > Russ Housley wrote:
> > > > Dolors:
> > > >
> > > > I do not have any problem with the priorities. However, I do have
>some
> > > > concerns with the "do it later, if needed" tone. If we look at
> > > > 802.1X development, it focused on 802.3 problems. This solved
> > > > real-world problems. Since a 802-wide view was not applied from
> > > > the beginning, significant changes are needed to make it work in
> > > > 802.11, and other wireless technologies.
> > > >
> > > > If we do not start with the big picture, we will inadvertently
> > > > make deployment in other topologies impossible without changes to
> > > > the
> >standard.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 09:10 PM 4/21/2003 -0400, Dolors Sala wrote:
> > > >
> > > >> There seems to be significant consensus in leaving the scenario
> > > >> of untrusted bridges for a later stage (although the final
> > > >> unified architecture should support a complete secure bridge
> > > >> network solution). It seems we may be close to identify the scope
> > > >> of the initial project.
> > > >>
> > > >> In the last call, Bob Moskowitz recommended to initially focus on
> > > >> the link level and leave the entire bridge network definition for
> > > >> a later stage. If I interpret him correctly, he considers that
> > > >> there is
>enough
> > > >> work in defining the provider side of the link security
> > > >> specification because it doesn't exist an specification or
> > > >> example from where we
>can
> > > >> leverage from. This work would involve to specify the
>(bi-directional)
> > > >> authentication and the link protection components of the unified
> > > >> architecture. Bob please clarify or extend as you feel
> > > >> appropriate.
> > > >>
> > > >> We would need to guarantee that the initial effort defines
> > > >> components that fit the unified and general architecture. Could
> > > >> we guarantee
>this
> > > >> by imposing a set of general requirements to an initial link
> > > >> specification?
> > > >>
> > > >> If so we could define a gradual roadmap where we focus first on
> > > >> the link components and later on the bridged network components.
> > > >> We could first focus on capturing a complete set of requirements
> > > >> from the unified architecture and define an initial project to
> > > >> specify a link security for 802.3 links. At a later stage,
> > > >> additional projects would be defined to complete the architecture
> > > >> for bridged networks (and/or other links if needed).
> > > >>
> > > >> I would like to solicit opinions and comments on this roadmap
>approach
> > > >> and recommendations on the specific scope and components of an
>initial
> > > >> project.
> > > >>
> > > >> Dolors
> > > >>
> > >