RE: Key Identification RE: [LinkSec] Requirements
> >2) VLANs need to be considered as part of the 'security association'
> >identification.
>
> How is this different than group member/not group member?
Yes ... VLAN usage needs to map to 'group member/not group member' by selecting a different key either by explicit use of vlan or other mechanisms.
> >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?
Don't provide explicit MAC address authentication based on the key establishment mechanism.
> I disagree. The MAC address allows device authentication.
> Something else
> is needed for user authentication, but it can be weaker.
I'm not asking for 'user authentication'. MAC level devices can
have multiple MAC addresses. It's very cumbersome to have to register
every possible interface as a separate entity.
> 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.
Hum, let's repeat it :-) We're at a different layer, with a different set of requirements. Plus I missed that meeting and doubt that it is adiquately documented.
Currently 802.11 (e.g. .1x EAP-TLS is using the MAC level authentication to support user authentication and potentially billing and roaming services. Why would the group want to go the way of IPsec-L2TP just to separate users from devices?
The EPONS requirements would seem to argue for a simple link layer security mechanism that provides direct correlation to the user to support logging and billing.
Paul