Good, we seem to be in total agreement.
   
  It 
  may be worth noting that there is no bridging directly to/through the 
  Uncontrolled Port, and that (absence of bridging through) is exactly what we 
  want in this scenario. The roving station should not appear (to the rest of 
  the network) as attached at a new point until it has secured access through 
  the Controlled/Authorized Port.
   
  Mick
   
  
  Mick,
  I 
  think that is exactly what I'm proposing for the Handoff group. 2 entities, 
  one on the controlled port and one on the uncontrolled port. They may actually 
  be the same entity with an attachment to both LSAPs, that is 
  TBD.
   
  The 
  reasoning is that it benefits from all the goodness that EAPoL benefits from. 
  802 Media independence and a clear definition of the security state of the 
  system (port open/ port closed).
   
  In 
  my model, it would be a policy decision as to what information or services 
  were available on which port. Obviously some information would need to be 
  secured and some information, such as say service advertisments ("Come to my 
  base station, Cheap bandwidth here!") would be better unsecured and available 
  expediently.
   
  The 
  answer to the question of whether we can retrofit such a clean architecture 
  into 802[11] is I believe 'yes' and yes its definition should be orthogonal to 
  linksec. If it is not possible, watch the handoff group crash and burn 
  :-).
   
  Regards,
  DJ
   
  David Johnston
Intel Corporation
Chair, IEEE 802 Handoff 
  ECSG
Email : dj.johnston@intel.com
Tel   : 503 380 5578 
  (Mobile)
Tel   : 503 264 3855 (Office) 
  
    
    
    The general solution to this class of issues seems 
    fairly clear. Provide/define a protocol entity that attaches to the/an 
    Uncontrolled Port that is providing the attachment point for the roving 
    station.
     
    Apart from the fact that that entity appears to 
    need to be able to read the current status of the Authorized/Controlled Port 
    (really as an optimization so that it doesn't have to conduct its own 
    further checks to guide its behavior - another and possibly better solution 
    might be to partition the overall functionality between such an entity and a 
    companion one that ataches to the Authorized Port, or to define an entity 
    which attaches to both), its definition ought to be orthogonal to 
    LinkSec.
     
    Clearly with a roving type technology where ports 
    come and go an association (also quite properly known as a Port) needs to be 
    in place for such an entity to communicate with the roving station. That 
    association doesn't have to be secure however.
     
     
    Wired world:
     
    Uncontrolled     
    Authorized
      
    Port  \      /    
    Port (secured association)
             
    \    /
              SecY
               
    |
             Port 
    (lower MSAP)
                          
    |
     
    Unwired world:
     
    
    Uncontrolled     
    Authorized
      
    Port  \      /    
    Port
             
    \    /
              SecY
               
    |
             Association
                          
    |
 
     
     
    Mick
     
    [I'm not saying that one can retrofit such a clean 
    architecture to 802.11 as currently defined.]
     
     
    
    On Behalv of Dave Johnston: