Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Exec SG to become an 802.1 SG
- To: <stds-802-sec@ieee.org>
- Subject: Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Exec SG to become an 802.1 SG
- From: "Bob O'Hara" <bob@airespace.com>
- Date: Sun, 23 Feb 2003 11:55:41 -0800
- Sender: owner-stds-802-sec@majordomo.ieee.org
- Thread-Index: AcLbaningR1rdls7TkSv49tR5DLjJAACtWiQ
- Thread-Topic: Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Exec SG to become an 802.1 SG
Forwarded for Russ, who is not subscribed to this list.
-Bob
-----Original Message-----
To: Tony Jeffree <tony@jeffree.co.uk>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the
Link Security Exec SG to become an 802.1 SG
Cc: "Ken Alonge" <kenneth.alonge@verizon.net>, "Dolors Sala"
<dolors@ieee.org>,
"IEEE802" <stds-802-sec@ieee.org>
Tony:
>I think it is high time to inject a bit of reality into this
discussion.
>
>Firstly, it is not at all clear to me what you mean when you describe
>802.1 as a MAC-oriented working group. Our charter is 802's
architecture,
>interworking, and higher (than MAC) layer issues. I would certainly
agree
>that the link security activity should not be buried within one of the
>MAC-specific groups (.3, .11, ...etc.), but I see nothing about the
>existing charter of 802.1 that doesn't make it a good fit for us.
In the old days, when Project 802 was sponsored by the IEEE technical
Committee on Computer Communications (TCCC), the whole activity was
limited
to layers 1 and 2. When 802.10 was formed, there was a strong belief
that
key management would require work outside of layers 1 and 2, and for
this
reason 802.10 had two sponsors TCCC and the Technical Committee on
Security
and Privacy (TCSP). As a result, key management standards at layer 7
were
included in the 802.10 PARs, and in fact 802.10c is an application layer
protocol.
In my opinion, key management cannot be solved in layer 1 and 2.
Several
architecture support this view, including the security work in 802.11
and
IETF IPsec.
In order to solve the key management, 802.1 would need to partner with
another activity, probably the IETF.
>Secondly, you talk about 802.10 and its charter being the best fit for
>this activity. If 802.10 existed in any meaningful way right now, I
would
>perhaps agree with you; however, as you have acknowledged, active
>participation by 802.10 members is a problem for them in these
>funding-challenged times, and they have been conspicuous by their
absence
>at meetings of the link sec study group to date. Having said that, the
>meetings we have held do not seem to have suffered from a lack of
security
>expertise - just not expertise that used to be in 802.10.
802.10 needs to come out of hibernation this year anyway. SDE (802.10b)
is
due for a five year review. Since this LAN/MAN security protocol meets
most of the LinkSec security encapsulation requirements, it is
reasonable
to make modifications to SDE to meet the remainder of the requirements.
>Thirdly, 802.1 is not without its own track record, however small, in
>developing security standards. In fact, it is arguably the case that
802.1
>is, to date, the only 802 working group that has developed a successful
>security standard for LANs; unlike the 802.10 standards, 802.1X has
been
>implemented, and found to be useful, by a significant number of
vendors.
>As a consequence, we now have participants in 802.1 that are there
>specifically to work on security issues; this is, in fact, one of the
>reasons that 802.1 made the offer to host the link sec SG, as these
>particular experts wanted to avoid the potential for conflicting
meeting
>times if the two activities were kept separate.
You are correct that 802.1X is being used by a larger number of
vendors. And, the current work in 802.11 will lead to further
dependencies
in 802.1X.
I know several people, including myself, who did not attend the LinkSec
SG
meeting because of the scheduling. I am sure that there was no date
that
would accommodate everyone's schedule.
>A final point. Strictly speaking, as 802.10 is a hibernating group, the
>charter of 802.10 is restricted to exactly one thing right now;
performing
>any maintenance that is required for the standards that they developed
>when they were an active WG. It has no charter with regard to any new
>work. That being the case, whatever new work comes out of this activity
>will, of necessity, result in the creation of a new charter, either by
>extending the charter of an existing (active) working group, or
>re-chartering hibernating group, or chartering a new working group
>altogether. When making that decision, it would make absolutely no
sense
>to me to place the work within 802 in a way that conflicts with
existing
>non MAC-specific activity in the security area, all of which currently
>resides in 802.1.
The necessary activity is the same in all cases -- write a PAR and get
it
approved.
I favor placing this work in 802.10 for several reasons, and one of them
is
voting rights. It is clear to me that folks who have been participating
in
802.3 and other places will want to become active in this process.
802.1
is an active working group, and this means that these new participants
would need to build voting rights. On the other hand, bringing a group
out
of hibernation seems very similar to starting a new group. So, it is my
assertion that everyone at the initial meeting would be granted voting
rights.
Respectfully,
Russ