RE: FW: [LinkSec] Requirements
Russ,
Picking up on a couple of points from your reply ...
> -----Cut From Original Message-----
>
> Since each port could be associated with a different Authentication
> Service, I would not expect the bridge to wait for all of the
> ports to be
> authenticated before passing traffic. What state is a port
> that is waiting
> authentication in? Disabled?
> --------------------
The bridge can pass traffic between the ports that are authenticated and
authorised, while waiting for the rest of them to be aa'd. The revision of
.1D now in progress will clean up the description a bit (since we've
stripped out STP it is now possible to be somewhat more definite about Port
States, RSTP is cleaner in its use of them), the net is that while the .1X
status of a bridge is Unauthorized, RSTP selects a port state of Discarding
for the relay function to that port. There is an extensive discussion of
this in Clause 7 of .1D.
> -----Cut From Original Message-----
> >Note that in my models (basic and roaming extended) the end
> station never
> >has the task of finding out which bridge is doing crypto
> after that bridge
> >has begun crypto. The crypto wrapper is removed and
> separately applied hop
> >by hop.
>
> In 802.10, we assumed that some bridges were crypto enabled
> and the some
> were not. You are making the same assumption, but with different
> consequences. If a non-crypto-enabled bridge was between two
> crypto-enabled ones, 802.10 would provide encryption between the two
> crypto-enabled ones, and the non-crypto-enabled bridge would pass
> ciphertext. In your proposal, all of the traffic would be
> plaintext, as
> neither pair of neighbors is capable of doing crypto.
>
> Is this an acceptable constraint?
>------------------------------------------
I think it is an acceptable constraint until such time as we develop a group
key solution for shared media (which is the net effect of having a
non-crypto bridge pass ciphertext in my model). In one group key solution a
key clerk (for want of a better term, don't read any established practice
into the term)is elected in plain view for the shared LAN using multicast
addressed advertisements that are filtered by crypto bridges and passed by
non-cryptos and then each bridge port attached to the shared LAN (whose
scope has been defined by said multicast) petitions the clerk in a three way
exchange involving the authentication server to get the group key, as does
anyone else attached to the LAN who needs to receive frames (inc the
management entities of the non-crypto bridges). Refinements to this scheme
retain connectivity to existing LAN stations by having a crypto LAN and a
plain text LAN overlap on the same media - there are a host of traditional
solutions and pratfalls possible. This sketch of a solution should be enough
to motivate others to explain the better ways of doing this to me.
> -----Cut From Original Message-----
> This is not MAC control frames, right? By control traffic
> you mean SNMP
> and RADIUS and other stuff that is on top of IP, right? If
> so, then I can
> see how such an architecture could be made to work. Are there other
> architectures, with non-crypto-enabled bridges passing
> ciphertext, that we
> need to consider?
>
> Russ
>------------------------------------------------------
Not necessarily IP, but most definitely not MAC control frames, so the
solution is fairly easy.
Mick