RE: FW: [LinkSec] Requirements
Mick:
Sorry it took so long for me to get back to this thread. I hope this reply
is not too late to be relevant.
> > -----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.
I was looking at IEEE Std 802.1D-1990. Thanks for the tutorial on the
pending update.
> > -----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.
You may want to look at the Multicast Key Center (MKC) stuff in 802.10c. I
do not think that the protocol is the correct one, but I think that he
services you are describing match up.
> > -----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?
> >------------------------------------------------------
>
>Not necessarily IP, but most definitely not MAC control frames, so the
>solution is fairly easy.
Okay. If we want to protect MAC SDUs, the interface should be very
clean. Trying to protect control frames that are internal to the MAC layer
is much more problematic. There is no clear service interface.
Russ