RE: Key Identification RE: [LinkSec] Requirements
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:
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.
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).
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.
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).
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.
Mick
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> Housley
> Sent: Monday, December 16, 2002 1:05 PM
> To: Paul Lambert
> Cc: stds-802-linksec@ieee.org
> Subject: RE: Key Identification RE: [LinkSec] Requirements
>
>
>
> Paul:
>
> >Identifing the security association with the MAC address is
> not the same
> >as authenticating the MAC address or using the MAC address
> as the peer
> >identity. So ... I sort-of agree with some of your points.
> >
> >However:
> >1) MAC addresses are not adiquate for identification of broadcast
> >'security associations'.
>
> Agree. The MAC address identifies the entities that are given the
> broadcast key, not the key itself. This confusion is one of
> the things I
> really dislike about the current 802.11 solution. SAIDs
> should identify
> the keys and their context, not the addresses of the entities
> that know the
> key.
>
> >2) VLANs need to be considered as part of the 'security association'
> >identification.
>
> How is this different than group member/not group member?
>
> >3) Bridges may play tricks with MAC addresses (yes in a 'pure'
> >architecture they
> > should not). ARP proxies are an example ...
>
> How does this impact the architecture?
>
> >MAC addresses should not be used in certificates (if we get
> around to
> >using certificates). This degree of MAC address
> binding/authentication is
> >inappropriate. Useful devices may have many MAC addresses,
> it limits user
> >mobility, etc...
>
> I disagree. The MAC address allows device authentication.
> Something else
> is needed for user authentication, but it can be weaker. We
> need to be
> careful not to repeat the tunneled authentication issues that
> were a major
> discussion topic at the last IETF, but we can authenticate
> the user after
> authenticating the device, binding the two together for the
> duration of the
> session.
>
> Russ
>
>