RE: Key Identification RE: [LinkSec] Requirements
Mick:
>Russ,
>
>Picking up on your points (in this and a prior email) about the confusion(s)
>between the following concepts:
>
>C1. entities that are given keys
>C2. the MAC addresses associated with the M-SAPs where protocol stacks
>serving those (C1) entities attach to the LAN
>C3. the range of useable identifiers for those M-SAPs in restricted or
>enlarged contexts
>C4. identifier(s) for the key that are included in clear in transmitted
>frames to support verification
>C5. devices that happen to use/own a given MAC address
>
>I would like to put a few more nails in the coffin for the idea that MAC
>addresses should be used for function C4:
First, I never advocated the use of the MAC address for C4. In fact, it
think it is a bad idea. Neither 802.10b SDE nor IPsec use an address to
name a symmetric key used for frame encryption. In 802.11 the MAC address
is combined with a very small key identifier, and I have been arguing that
this is not the best solution.
Second, I have been advocating the use of the MAC address as the identity
of the layer 2 entity that establishes the keys that are named by C4. In
particular, I advocate the use of a certificate with an RSA public key and
the MAC address of the entity with access to the private key.
I hope that misunderstanding is cleared up. Now, on to your other points.
>N1. MAC addresses rarely identify the "end points" of a point to point
>conversation that is to be secured. As has been pointed out these
>conversation usually operate at the IP layer or above, passing through
>routers etc. so if it is a set of end to end conversations that we are
>trying to protect as opposed to the privacy offered by part of the network
>over which those conversations pass we are operating at the wrong layer.
Full agreement. At layer 2, we do not offer end-to-end protection.
>N2. The end points of the MAC addressed communication are rarely aligned
>with the trust/distrust boundaries of the network, they either fall short
>(N1 above) or are overkill (its only a LAN segment that is exposed not the
>entire Bridge Local Area Network).
However, bridges also have MAC addresses. In another note, I pointed out
that we need to support station-to-station, station-to-bridge, and
bridge-to-bridge security associations. In each case, both ends of the
security association have a unique MAC address, otherwise the
communications do not work.
This leads to a philosophical point. In my opinion, security should never
have the role of making the communications work. Rather, security is used
to protect already functioning communications.
>N3. Regrettably the uniqueness of MAC addresses cannot be assumed (local
>addresses, continuing insistence by some that they identify a station not a
>SAP - in clear disregard of the OSI Reference Model which is useful on this
>point, intentional duplication to hack around IP router failure (VRRP, hot
>standby routers etc.)). The best that we are likely to be able to do is that
>a MAC address is unique when qualified by a VLAN ID. This is a problem in
>the following scenario.
>
>A1->B1: B,A{A,data}Ka1b1
>
>received by a VLAN/.1Q bridge that ingresses the frame to a VLAN V, and
>forwards the frame toward V.A, as
>
>VA->VB: V,B,A{A,data}Ka1b1
>
>received by a hypothetical verifier within the VLAN infrastructure who now
>cannot tell which key to use (and with a verification hole) unless more
>parties are involved in handing out the key since:
>
>A2->B2: W,B,A{A,data}Ka2b2
>
>This scenario is not going away any time soon, in fact it is going to get
>more likely.
If two devices have the same MAC address, then these devices better be
providing the same services to the rest of the LAN. Otherwise the
communications is not going to work properly. I must say that I do not
like this approach to "hot backup," but I do understand why someone might
take this approach.
We need to decide if this configuration is something we must support. Is
it a requirement? If so, we must accept the significant complexity that
comes with it. Either, we have to find a way to establish keys with both
devices, or the active device must shadow the established key to the hot
backup device(s).
>To conclude, I continue to favor (1) IPsec for "end to end" protection (2)
>perimeter security for each LAN in a bridged network based on securing
>access points/bridge ports with an appropriate choice for C4 above based on
>C3. Since I believe basing C4 on C1 is too difficult in the absence of a
>universal entity naming and unique identification scheme (not likely to
>arise in my lifetime).
I believe that C3 is dynamic. Depending on the spanning tree, the
crypto-enabled bridge may be protecting traffic for a different set of
stations.
>If 802.1 has to fix IEEE Std 802 (802.1 is responsible for its maintenance)
>to make it more useful/palatable for security I am sure that could be
>seriously considered.
I know that 802.1 has maintenance responsibility for IEEE Std 802. Do you
have a specific change in mind?
Russ