[802SEC] Fwd: [802.1 - 7665] Review of China contribution to ISO/IEC JTC1/SC6 on LAN security
Relevant to the discussion this evening, below is a technical assessment of
the China contribution on LAN security. We discussed this in the closing
802.1 Plenary, and while we didn't vote on the document, there was general
support for what Mick has said.
This could usefully be worked up to form an 802 contribution to SC6.
Regards,
Tony
---------- Forwarded message ----------
From: Mick Seaman <mickseaman@sbcglobal.net>
Date: 11 November 2010 19:47
Subject: [802.1 - 7665] Review of China contribution to ISO/IEC JTC1/SC6 on
LAN security
To: STDS-802-1-L@listserv.ieee.org
Didn't see your contribution? DON'T PANIC. Before sending a duplicate
post, see "Sending->retrying" at
802.1 list help: www.ieee802.org/1/email-pages/actl1109.html
-----
I and one other member of the 802.1 Security Task Group have briefly
reviewed the referenced contribution to ISO/IEC JTC1 SC6. Our (independent)
summary conclusions are that its comments on IEEE Std 802.1AE-2006/IEEE Std
802.1X-2010 in a number of major respects are either inaccurate or could be
very misleading to those who are not familiar with the technology. My
personal review of the document follows, commenting on some of these points:
1) "IEEE 802.1X-2010 doesn’t give a specific authentication mechanism."
IEEE 802.1X fits within the EAP (Extensible Authentication Protocol)
framework, thus allowing (a) the widest possible deployment both in
existing networks that have made particular choices (b) new developments in
the field (pursued by large numbers of well informed engineers) to be taken
advantage of as they occur - very important in security. While it would
indeed be possible to make one definite choice today from that which EAP
provides in an attempt to force all networks (what ever their needs and
existing deployment) to choose between the high quality offering it is
likely such a choice would be an arbitrary commercial decision and not
improve use.
2) "Authentication in 802.1x is just between client and server. The LAN
switch doesn’t have an identity and is not authenticated."
Misleading. The authentication is mutual authentication so that there is no
possibility of a "man in the middle attack" substituting a different switch.
The scenario with regard to the LAN switch's authentication in this respect
is just like that for an 802.11 AP. The authentication server, switch, and
client all participate in the authentication exchange. Of course when a
network administrator is constructing the network he/she will require that
any switch added to the network also authenticate itself as a client (or
some similar procedure) and 802.1X key management for 802.1AE works in such
a way that switches can authenticate each other (neighbour to neighbour at
an appropriate peer level) without loops of mutually dependency and can
quickly recover an existing authentication for a link that has gone down and
come up again so that the network is robust and does not impose an excessive
load on a central server during times of high change.
3) "Hop-by-Hop Encryption." "It requires LAN switch decrypt each received
packet with one key, encrypt with another key, and then transmit it"
a) Encryption is indeed "hop-by-hop" but this neglects the fact that at one
level (a customer C-VLAN level for example) one hop could in fact be across
an entire network of provider bridges or provider backbone bridges.
b) The alternative to "hop-by-hop" is end to end, however the desired "ends"
in a layer 2 network very rarely (from real experience) correspond to the
addressed stations but run the gamut from an access link to across an entire
network (see (a) above). Further end to end in the sense of the source MAC
end-station to the destination MAC end-station would mean that stations
communicating with many others would require a separate cryptographic key
and key schedule for each such pair-wise communication. Ensuring rapid
access to the amount of date required for each key for stations that have a
very large number of such peers would have a very large cost or performance
impact, and would require special key sharing mechanisms for multicast
throughout the entire network (not just on an access LAN). 802.1AE requires
only a pair of keys per port (for non-stop operation even during times of
key refresh/change as required by security policies). If end-to-end (host to
host) encryption is truly desired then the use of IPSEC is strongly
indicated and it is certainly undesirable to attempt to replace IPSEC with
something that is just LAN specific.
4) "High Latency, High cost."
These statements are not substantiated in any way, nor is any alternative
that meets all 802.1AE requirements and goals suggested. The Cipher Suite
specified in IEEE Std 802.1AE (GCM-AES) is the best, most efficient, known
and the only practical NIST approved Cipher Suite for use at these speeds.
Security and performance goals against which these statements could be
evaluated are not provided. No alternate Cipher Suite is suggested.
5) "Flood is more terrible"
A simply unsubstantiated judgment statement about the hop-by-hop vs
"end-to-end" issue. A switch that is built to be able to interoperate with
arbitrary neighbouring switches and end stations (some security capable,
some not) will have to be capable of encrypting/decrypting to the per-port
level/granularity in any case so it is unlikely that there will be
implementation cost saving in a high performance switch by avoiding
encrypt/decrypt at some times.
6) "Flood is more terrible"."If the attacker sends a lot of frames with
unknown MAC_D, it can affect performance of the switch".
This point should not serve as a criticism of 802.1AE but to point out how
important it is that a switch verify the integrity/origin of a frame on
reception (i.e. per port), rather than flooding it through the network so
that a potentially large number of other switches could be affected by that
frame (some of which might in turn further flood the frame). Reducing the
encryption/decryption load on a switch by allowing it to propagate a problem
to other switches in the network is not a positive step. Moreover if the
attacker sends frames with addresses that conflict with properly used
addresses all traffic with those addresses can be affected in a bridged
network. The contribution contains a proposal for a "new" protocol which
appears to suffer from this very significant flaw.
7) The presentation goes onto to propose the "TLSec Protocol". This appears
to be just (or substantially) 802.1A MACsec with communication run over a
VLAN instead of under all VLANs. In particular it appears to be arrangement
of the interface stacks so that the C-VLAN tagging component is positioned
underneath MACsec instead of above it. In this respect it appears almost
entirely equivalent to the arrangement already described in 802.1AE clause
11.7 "MACsec in Provider Bridged Networks", but using the C-VLAN TAG (81-00)
instead of the S-VLAN TAG . So the claimed new "TLSec Protocol" is a really
just a copy of existing IEEE Standards (even down to using the terms/labels
in 802.1AE and 802.1Q). No analysis is presented of the
interworking/interoperability challenges that follow such an interface stack
rearrangement. In particular it is not clear whether the value of the VLAN
identifier (VID) is integrity protected (in which case it cannot be changed
between source and destination) or not (in which case data integrity is
compromised). No analysis is presented of the desirability of having a
network with insecure switches internally at which traffic could be injected
that would appear to peer with secure switches/clients (how is it possible
to manage such switches, what happens to secure multicast addressed to
stations attached to them, and the myriad of issues that require and
through understanding of the bridging standards etc.). No
consideration/acknowledgment is made of the fact that 1AE Clause 11.7
effectively already provides such an arrangement (traffic secured over a
provider network) in a way that either avoids a number of
interoperability/interworking issues or makes it clear how they are to be
addressed.
To conclude, though it is always possible that new interworking arrangements
become desirable as technology and network arrangements change, the
contribution is misleading on a number of issues and neglects issues that
were extensively discussed either before work began on IEEE
802.1AE/802.1X-2010 or during development of those standards. To the extent
that the contribution largely involves rearrangement of elements specified
in IEEE 802.1AE/IEEE 802.1X/IEEE 802.1Q, and the IEEE 802.1 Working Group is
continually in receipt of proposals that add to/extend/rearrange those
elements, all of which need to be considered from the point of view of
mutual interference/interworking/interoperability and has developed
considerable expertise in doing so over a number of years it is not helpful
to have another standards organization undertake an independent
rearrangement of those elements.
Mick Seaman,
Chair IEEE 802.1 Security Task Group
past chair IEEE 802.1 Interworking Task Group
On 11/10/2010 6:55 AM, Tony Jeffree wrote:
> Working Group 802.1 Web pages: www.ieee802.org/1/
> 802.1 list help: www.ieee802.org/1/email-pages/actl1109.html
> -----
>
> I circulated the following document back in September:
>
>
> http://www.ieee802.org/1/files/public/docs2010/liaison-isosc6-n14402-nb-of-china-contribution-tion-on-lan-security-0910.pdf
>
> Paul Nikolich has suggested that it would be good to be able to circulate
> any appropriate refutations of this material to the other national bodies
> in
> SC6 so that they are more fully informed. I will set aside a slot in the
> closing Plenary to discuss what our response might be.
>
> Regards,
> Tony
>
> ===
> Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG
> IEEE. Fostering technological innovation and excellence for the benefit of
> humanity.
>
>
>
===
Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG
IEEE. Fostering technological innovation and excellence for the benefit of
humanity.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.