WO2004095800A1 - Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide - Google Patents

Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide Download PDF

Info

Publication number
WO2004095800A1
WO2004095800A1 PCT/US2004/011880 US2004011880W WO2004095800A1 WO 2004095800 A1 WO2004095800 A1 WO 2004095800A1 US 2004011880 W US2004011880 W US 2004011880W WO 2004095800 A1 WO2004095800 A1 WO 2004095800A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
scm
request
message
node
Prior art date
Application number
PCT/US2004/011880
Other languages
English (en)
Inventor
Robert Meier
Richard D. Rebo
Victor J. Griswold
Douglas Smith
Nancy Cam Winget
Original Assignee
Cisco Technology, Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/417,653 external-priority patent/US7350077B2/en
Application filed by Cisco Technology, Inc filed Critical Cisco Technology, Inc
Priority to AU2004231612A priority Critical patent/AU2004231612C1/en
Priority to EP04759954A priority patent/EP1614273A1/fr
Priority to CA002520494A priority patent/CA2520494A1/fr
Publication of WO2004095800A1 publication Critical patent/WO2004095800A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the present invention is generally related to wireless networking, more specifically to methods and systems for authenticating and provisioning wireless devices as the devices roam among access points.
  • 802.11 network-level authentication protocols require a substantial amount of time to re-establish a wireless station's connectivity to the network after that station roams from one access point (AP) to another access point.
  • AP access point
  • a station associates with a first access point it has to be authenticated through a central authentication server.
  • the station loses the session to the network and must again authenticate itself with the authentication server which typically involves a full challenge request and response.
  • a new accounting session is then established.
  • This method introduces a new key hierarchy that commences on the initial authentication and allows for the authentication key to persist across the duration of a session to the network versus an 802.11 link.
  • this new key hierarchy is based on counter mode key generation to allow the precomputation of the 802.11 key obviating the need for unnecessary session teardown and restart.
  • This'delay in re-establishing connectivity greatly impacts 802.11 service to the point that some upper-level protocols, such as Voice-over-IP (VoIP), actually fail.
  • VoIP Voice-over-IP
  • each roam commonly necessitates interaction with a site's Authentication, Accounting, and Authorization (AAA) servers, resulting in a significant increase in server load, to the point at which some servers fail to provide the necessary rate of authentications requests for the 802.11 stations.
  • AAA Authentication, Accounting, and Authorization
  • the 802.11 station must then use the key provisioned at authentication to establish a fresh key used to secure the 802.11 link with the access point.
  • the handoff mechanism is based on key management and thus is independent of the authentication mechanism. Note however that any key management mechanism must be aware of chosen authenti cation type as it must know how to properly retrieve and interpret the NSK. 7) The handoff mechanism relies on a centralized service to provide secure key distribution services
  • PEAP Current authentication protocols such as PEAP or TLS require interaction with the authentication state.
  • PEAP touts the ability to shorten roam time by allowing a MN to bypass a full challenge-response authentication exchange by affecting a resume operation.
  • IEEE 802.11 security task group 'i' e.g. TGi have accommodated for the means of pre- authenticating.
  • NSK network session key
  • PTK pairwise transient key
  • TGi also alludes to the ability of transferring the NSK from one AP to another.
  • CCKM defines an initial authenticated key exchange by which the MN and first associated AP contribute material for deriving fresh keys for authenticating key requests, KRK, and a base transient key, BTK for deriving PTKs.
  • KRK key requests
  • BTK base transient key
  • IEEE 802.11 - The 802.11 protocol and 802.11 tenns are defined in IEEE Std 802.11, 1999 Edition IEEE 802.11 TGi - a task group in IEEE 802.11 currently focused in addressing
  • 802 address A canonical IEEE 48 bit "Ethernef'address. 802.11 and Ethernet addresses are 802 addresses.
  • An 802.11 bridge is a transparent bridge with an Ethernet bridge port and one or more 802.11 bridge ports.
  • a parent 802.11 bridge has a secondary 802.11 port which links to a primary 802.11 port in a child 802.11 bridge.
  • 802.11 station - A MN or AP 802.11 station - A MN or AP.
  • 802.1X The IEEE 802.1X protocol and 802.1X tenns are defined in []. 802.1X defines a protocol where an 802. IX Supplicant mutually authenticates with an 802. IX Authenticator via an Authentication Server.
  • AAA - Authentication Authorization Accounting A node will request network access by executing a protocol to a (typically) Authentication Server that provides protocols and services for providing authentication, authorization and session accounting.
  • AKM - Authenticated Key Management New selector in both the SSN and TGi negotiated element present in beacons, probe response and reassociation request/response messages. This selector allows for definition of authentication type and key management.
  • Association Message An 802.11 station sends an Association Request message to initially associate with a parent AP. The parent AP replies with an Association Response message.
  • AS - Authentication Server A node that provides AAA (specifically authentication) service.
  • BDPU an 802.1D Bridge Protocol Data Unit.
  • BSS An 802.11 Basic Service Set.
  • a BSS is the set of 802.11 stations associated with a single 802.11 AP.
  • a logical "BSS port" in an AP is used to access stations in the BSS.
  • Base Transient Key (BTK) - the base transient key that is mutually derived between MN and SCM to serve as the key for generating PTKs.
  • Campus Netowkr an aggregate "seamless roaming domain" which implies a geographic locality which may include one or more 802.11 Extended Service Sets.
  • a physical campus network may contain multiple "campus networks.”
  • Central Key Management (CCKM)- the key management scheme ofthe present invention. It utilizes a central node, an AP, as the key distributor to enable protected communications between a link (e.g. an AP and MN).
  • CTK Context Transfer Key
  • Correspondent Host (CH) - A mobile or non-mobile node that is actively communicating with a MN.
  • a DRR contains state information for descendant nodes.
  • An MN-DRR is a DRR for a mobile node.
  • An AP-DRR is a DRR for an AP.
  • DPR Descendant Path Record
  • Downlink The logical radio path from an 802.11 AP radio to a child 802.11 station.
  • ESS An 802.11 Extended Service Set.
  • An ESS includes one or more BSSes and may span one or more subnets. MNs can roam between APs in the ESS.
  • a SWAN Campus Network may include multiple ESSes.
  • GTK Group Transient Key
  • Hopwise Routing "Hopwise routing" is used when an inbound or outbound WLCCP message must be forwarded to intermediate APs on the path from the Originator to the Responder.
  • IA Infrastructure Node Authenticator. In standalone mode, the SCM is the IA; in a full SWAN configuration, the CCM is the IA.
  • IGMP Internet Group Management Protocol.
  • IGMP is used to determine IP multicast group membership.
  • IGMP Snooping - Switches and APs "snoop" IGMP messages, received on a port, to determine which IP multicast addresses must be transmitted on the port.
  • Inbound - An "inbound frame" is forwarded toward the CCM, in the SWAN Topology Tree.
  • An "inbound node” is accessed via the "primary port”. (An "inbound node” is not necessarily an "ancestor node”.)
  • An IN is an AP, SCM, LCM, or CCM.
  • KDC - Key Distribution Center This is a service provided by the IN Authenticator to distribute CTKs to be consumed by registered infrastructure nodes.
  • KRK Key Request Key
  • Layer 2 The data link layer, as defined in the ISO 7-layer model.
  • Link State Each SWAN node is responsible for monitoring the link to each of its immediate neighbors.
  • the Link State can be "Connected” or "Disconnected”.
  • MN-ID - 802.11 Mobile Node identifier represented as the node's MAC address
  • NSK Network Session Key
  • CCM being the authenticator for all infrastructure nodes
  • LCM being the authenticator for all MNs.
  • SCM is the authenticator for all nodes.
  • MNR Mobile Node Record.
  • a Mobile Node Record contains state information for MNs.
  • Mobility bindings The "mobility bindings" for a station are used to determine the current path to the station.
  • APs, context managers, and MIP agents maintain mobility bindings for 802.11 stations.
  • Native VLAN ID A switch port and or AP can be configured with a "native VLAN ID”. Untagged or priority-tagged frames are implicitly associated with the native VLAN ID.
  • Network Access Identifier (NAT) An NAI is used to identify a user within a network domain. For example, "joe@cisco.com” is a typical NAI.
  • NSK Network Session Key.
  • An NSK is the key established by a successful authentication between a node and its "authenticator”.
  • the CCM is the authenticator for all infrastructure nodes and the LCM is the authenticator for all MNs, in a campus network.
  • the SCM is the authenticator for all nodes in the subnet.
  • Originator - The node that "originates" a WLCCP "request” message.
  • Outbound - An "outbound frame" is forwarded away from the CCM, in the SWAN Topology Tree.
  • An "outbound node” is a "descendant” node that is relatively furtlier from the CCM in the SWAN Topology Tree.
  • Pairwise Master Key (PMK) - the key established by a successful authentication. This is the term used in both the TGi and SSN draft specification and is a key used to derive PTKs.
  • PTK Pairwise Transient Key
  • CM mutually authenticates and establishes a path CTK with each of its ancestors.
  • Path- t and (optionally) intial Registration messages are used for path authentication.
  • Port - The logical entity that provides access to a SWAN Topology Tree "link". Multiple logical ports may exist on a single hardware interface.
  • the primary LAN may include multiple Ethernet segments and wired transparent bridges/switches.
  • An AP primary port can be an Ethernet or 10 802.11 port. The AP primary port is the "default port” for unicast flooding purposes. [If an AP is co-located with an SCM, then a logical internal link exists between the AP and SCM. A logical AP "internal primary port" provides access to the SCM; however, the Ethernet port is still the "primary port” for frame forwarding purposes.]
  • PTK- Pairwise Transient Key This key is used to protect 802. IX and 802.11 data is packets between a MN and AP. PTKs are mutually derived by each node in the link based on a predefined strong pseudorandom function, BSSID, RN and BTK.
  • Reassociation Message An 802.11 station sends an 802.11 Reassociation Request message to associate with a new parent AP after it roams.
  • the parent AP replies with a Reassociation Response message.
  • 20 Rekey Request Number (RN) the counter used to protect PTK key refreshes from replay attacks. The counter is also used as part of the PTK key generator.
  • Repeater - A repeater is a "wireless AP" that is attached to a parent AP on an 802.11 primary port.
  • RN - Request Number A sequence value used to rotate PTKs used between an authenticated MN and Root AP.
  • Root AP - A "root AP" is directly attached to the primary LAN on its primary Ethernet port.
  • Root CM The CM that is at the root ofthe active SWAN Topology Tree.
  • the CCM is the root CM in a campus network.
  • the SCM is the root CM in a "stand-alone" subnet control domain.
  • SCM - Subnet Context Manager An SCM provides a central control point for each subnet. The SCM establishes the "primary LAN" for each subnet. From the perspective of a MN, a home SCM is the SCM ofthe home subnet for the MN and a foreign SCM is an SCM on any other "foreign subnet".
  • a MN is said to roam “seamlessly” if it roams between APs in different subnets without changing its "home IP address”.
  • a secondary LAN Any wired Ethernet LAN that is attached to the Primary Ethernet LAN by a wireless link.
  • a secondary LAN may include multiple Ethernet segments and wired transparent bridges/switches.
  • Secondary Port - A secondary port is any active AP or CM port other than the primary port.
  • SSN Simple Security Network
  • STP - IEEE 802.1D Spanning Tree Protocol An "STP AP" executes the 802.1D STP and the 802. ID STP is operated on an "STP link”. A "non-STP AP” does not execute the 802. ID STP.
  • a MN is associated with a single “home subnet” at any given time. Any other subnet is a “foreign subnet", from the perspective ofthe MN.
  • Supplicant - The IEEE 802. IX standard defines the term "supplicant".
  • a supplicant is a node that is mutually authenticating with an "802. IX authenticator" via an authentication server, SWAN - Smart Wireless Architecture for Networking, an architecture for radio, network and mobility management within a secure environment.
  • SWAN Topology Tree The logical structure of a SWAN netowrk as determined by the SWAN parent/child relationships.
  • the SWAN CCM is at the root ofthe topology tree.
  • VLAN - A "Virtual LAN", as defined in the IEEE 802.1Q standard.
  • TLV - Type, Length, Value "TLV's" contain optional parameters in WLCCP messages.
  • Uplink - The logical radio path from an 802.11 child station to its parent AP radio.
  • VLAN - A "Virtual LAN" as defined in the IEEE 802.1Q standard. VLAN tagged frames are transmitted on a VLAN Trunk link.
  • Wireless station - A MN, repeater, WGB, or child 802.11 bridge Wireless station - A MN, repeater, WGB, or child 802.11 bridge.
  • WGB - A work-group bridge is a non-STP AP with an 802.11 primary port and a secondary Ethernet port that provides access to a non-STP secondary Ethenet LAN segment.
  • the invention contemplates a design that reduces both message and computational burdens by employing a key hierarchy that decouples authentication session time from key management.
  • Current 802.11 implementations tightly bind authentication and key management and enforce full backend (re)authentications because they are bound to the cipher suite selection.
  • Wired Equivalent Privacy WEP
  • this can result in very frequent (re)authentications due to WEPs rekey requirements.
  • current implementations also enforce a full (re)authentication.
  • the key hierarchy defines keys established on a successful authentication as network session keys (NSKs), which are independent of the 802.11 cipher suite selection.
  • NSK is used to generate a key refresh key (KRK) to authenticate key refresh requests and a base transient key (BTK) which serves as the base key from which pairwise transient keys (PTK) are derived.
  • KRK key refresh key
  • BTK base transient key
  • the longevity of the NSK is defined by the Authentication Server (AS) as a session timeout which can now be defined as a function ofthe NSK entropy versus the 802.11 negotiated cipher suite. It is desired is to strongly encourage the use of authentication types that result in generation of dynamic NSK with more good entropy.
  • AS Authentication Server
  • SCM subnet context management
  • the SCM is the 802. IX authenticator for all MNs and APs enforcing all MN nodes to implicitly register.
  • the registration process ensures that all nodes in the registry have successfully associated, authenticated and have security credentials cached.
  • the mechanisms described in this proposal are defined as Central Key Management (CCKM) and negotiated as a proprietary value in the Authenticated Key Management (AKM) infonnation element as defined in SSN/TGi's drafts.
  • CCKM Central Key Management
  • ALM Authenticated Key Management
  • One aspect ofthe present invention is a method for authenticating a mobile node with a network, the steps comprising associating with an access point, authenticating the mobile node using an extensible authentication protocol by the access point, and establishing a network session key and registering the mobile node into the network infrastructure.
  • the network session key is used to establish a key request key and a base transient key.
  • the network session key is sent to a Subnet Context Manager.
  • the present invention further contemplates authenticating key refreshes using the network session key. It is further contemplated that pairwise transient keys are derived using the network session key.
  • Another aspect of the present invention is a method of re-association by a mobile node, the steps comprising sending a re-association request from a mobile node to an access point, the re-association request comprising a mobile node identification, a rekey request number, and an authentication element, validating the re-association request, the validating step comprising computing a new pairwise transient key, sending a response, the response comprising an authentication element, to the mobile node, the authentication element comprising the new pairwise transit key and an extensible authentication protocol over local area network key; and confirming the response by verifying the new pairwise transit key to a second computed pairwise transit key.
  • the response is validated by verifying the new pairwise transient key.
  • the response may also be verified by verifying a timestamp included in the response.
  • the authentication element preferably uses a current pairwise transient key.
  • the validating step is perfonned by either a subnet context manager (SCM), an authentication server (AS), or the access server (AAA server).
  • Other methods for validating the request include but are not limited to verifying that the timestamp ofthe re-association request is within a configurable value, verifying the sequence number is greater than a previous value, sending to a query to a subnet context manager to validate the re-association request, wherein the access point (AP) receives a rekey request number and a base transient key from the subnet context manager and generates
  • Another aspect ofthe present invention is a rekey sequence, the steps comprising: computing an authentication element, the authentication element comprising a rekey request number and a new pair transient key, transmitting to a responder a call for a new pair transient key, receiving an response authentication element from the responder; and verifying the response authentication element, the response authentication element comprising the new pair transient key.
  • the rekey sequence may further comprise sending an extensible authentication protocol over local area network key confirm message. Prior to computing the authentication element, the rekey request number is incremented.
  • Another aspect ofthe present invention is a rekey sequence, the steps comprising: receiving a rekey request, the rekey request comprising a rekey request number and an authentication element, computing a new pair transient key; and sending a ready to transmit and receive with the new pair transient key message.
  • the rekey sequence may further comprise receiving an extensible authentication protocol over local area network key confirm message, verifying the rekey request number is greater than a cached rekey request number, verifying all attributes of an extensible authentication protocol over local area network key request, updating a cached rekey request number, or a combination thereof.
  • the authentication element may comprise a new initiator pair transient key and the steps may further comprise comparing the new pair transient key with the new initiator pair transient key.
  • FIG 1 is a block diagram illustrating a key hierarchy as contemplated by the present invention
  • FIG 2 is a table of Subnet Context Manager acquisition of network session keys
  • FIG 3 is a table illustrating authenticated key management selector values
  • FIG 4 is a table illustrating a Subnet Context Manager's cached credentials
  • FIG 5 is a table illustrating the credentials cached by an Access Point
  • FIG 6 is a block diagram illustrating the keys used to secure messages between links
  • FIG 7 is a flow diagram showing the steps for AP registration to an SCM
  • FIG 8 shows an example of a successful mobile node Lightweight Extensible Authentication Protocol Authentication and Registration
  • FIG 9 shows an example of a successful mobile node non-Lightweight Extensible
  • FIG 10 is a flow diagram illustrating the sequence triggered to complete a key establishment after a successful authentication
  • FIG 11 is an example key descriptor for a rekey sequence
  • FIG 12 is a block diagram showing a rekey sequence
  • FIG 13 is an example ofthe authenticating element included in a re-association request sent by a mobile node
  • FIG 14 is an example ofthe format ofthe response to the re-association request by the access point
  • FIG 15 is a block diagram illustrating the communications that take place between the various network components for a successful mobile node reassocation to a new access point
  • FIG 16 is a block diagram showing a method for propagating keys for legacy or SSN mobile nodes
  • FIG 17 is a block diagram exemplifying a topology tree for a full implementation of one aspect ofthe present invention.
  • FIG 18 is a table illustrating the format of a WLCCP Node ID.
  • FIG 19 is block diagram showing the internal bridging structure in an access point;
  • FIG 20 is an example of an Ethernet-encapsulated WLCCP Context Management frame
  • FIG 21 is an example of a WLCCP Message Header
  • FIG 22 is an example of a TLV format
  • FIG 23 is a block diagram showing how hopwise routing is used
  • FIG 24 is a block diagram illustrating a handoff from a first access point to a second access point for a mobile node on a campus topology
  • FIG 25a is an example ofthe message sequences for initial mobile node association
  • FIG 26b is an example ofthe message sequences for a mobile node roaming from a first access point to a second access point;
  • FIG 27 is a block diagram illustrating a handoff of a repeater access point from a first access point to a second access point
  • FIG 28a is an example of the message sequences for initial repeater access point association
  • FIG 28b is an example ofthe message sequences for a repeater access point roaming from a first access point to a second access point
  • FIG 29 is an example of a root access point authentication
  • FIG 30 is a block diagram illustrating defined CTK's
  • FIG 31 is an example block diagram of an AP authenticating and registering to the infrastructure
  • FIG 32 is an example block diagram of an alternate sequence used for a path update requiring no registration
  • FIG 33 is an example of an Establish (refresh) CTK's between an access point and a subnet context manager;
  • FIG 34 is a block diagram illustrating an example message sequence for a successful mobile node authentication and registration to full topology
  • FIG 35 is a block diagram of a WLAN spanning tree for a single subnet
  • the present invention reduces both message and computational burdens by employing a key hierarchy that decouples authentication session time from key management.
  • Current 802.11 implementations tightly bound authentication and key management and enforce full backend (re)authentications because they are bound to the cipher suite selection. For WEP, this can result in very frequent (re)authentications due to WEPs rekey requirements. For roaming, cunent implementations also enforce a full (re)authentication.
  • the key hierarchy defines keys established on a successful authentication as network session keys (NSKs), which are independent of the 802.11 cipher suite selection.
  • NSKs network session keys
  • the NSK is used to generate a key refresh key (KRK) to authenticate key refresh requests and a base transient key (BTK) which serves as the base key from which pairwise transient keys (PTK) are derived.
  • KRK key refresh key
  • BTK base transient key
  • PTKs are bound to the selected 802.11 cipher suite and thus must be managed based on the cipher suite security policies.
  • the longevity of the NSK is defined by the Authentication Server (AS) as a session timeout which can now be defined as a function ofthe NSK entropy versus the 802.11 negotiated cipher suite.
  • the goal is to strongly encourage the use of authentication types that result in generation of dynamic NSK with more good entropy.
  • the new key hierarchy 100 is depicted in Figure 1.
  • SCM subnet context management
  • the SCM is the 802. IX authenticator for all MNs and APs enforcing all MN nodes to implicitly register.
  • the registration process ensures that all nodes in the registry have successfully associated, authenticated and have security credentials cached.
  • the mechanisms described in this proposal are defined as Central Key Management (CCKM) and negotiated as a proprietary value in the Authenticated Key Management (AKM) information element as defined in cunent SSN and TGi's drafts.
  • CCKM Central Key Management
  • ALM Authenticated Key Management
  • the top ofthe hierarchy 100 is the NSK 102.
  • the NSK 102 is implicitly derived as a result of a successful EAP authentication.
  • the KRK and BTK are generated using a PRF with the NSK, BSSID, STA-ID, NoncesT A and Noncesc M as parameters.
  • the 128 bit KRK 106a and 256 bit BTK 106b are derived from the NSK.
  • From the BTK 106b is generated the PTK SN using a PRF with the BTK, RN and BSSID as parameters.
  • From the PTK are derived the 802.1X Encrypt Key 110 (16 bytes), the 802.1X MIC key 112 (16 bytes), the 802.11 Encrypt Key 114 (16 byes) and the AP MIC Keys 116 (TKIP only).
  • the AP MIC Keys 116 further comprise a Tx Key 118a, 8 bytes, and a Rx Key 118b, also 8 bytes. While the authentication mechanism remains unchanged, e.g. 802. IX EAP authentication, the present invention introduces a new key management scheme: CCKM. This new capability is advertised and negotiated using SSN's IE or RSN's IE, described herein infra.
  • NSK pre-shared key
  • Figure 2 is a table 200 that describes how the NSK is derived and retrieved by the SCM.
  • Column 202 describes the 802. IX Authentication type.
  • Column 204 describes the NSK computation.
  • Column 206 shows the length ofthe NSK in bytes, and column 208 describes how the SCM acquires the NSK.
  • Authentication types that do not mutually derive dynamic keys such as EAP-MD5 rely on having a static key to be configured similar to how legacy systems support pre-shared key authentication. These static configurations are traditionally managed at the AP. To allow for backward compatibility, these configurations must persist. Thus, CCKM will request these NSK types from the first associated AP as the session NSK.
  • the present invention contemplates a fast handoff system and method (herein refened to as CCKM) that is based on a centralized service, a Subnet Context Manager (SCM) to enable a seamless secure context transfer required to transition a MN from one AP to a new one.
  • SCM Subnet Context Manager
  • the SCM relies on each node both APs and MNs to mutually authenticate with the SCM.
  • a shared secret must be established: a network session key (NSK).
  • NSK network session key
  • the use of the NSK deviates from IEEE 802.11 TGi ' s (as well as S SN) use of the key established at authentication.
  • TGi/SSN refers to this key as a PMK which in turn is used as key material to derive both the 802. IX and 802.11 pairwise transient keys (PTKs). While CCKM also derives further key material from the NSK, the derived keys are used to authenticate transient key requests and to derive the PTKs.
  • the key hierarchy is depicted in Figure 1.
  • CCKM allows the MN to derive the new PTK before reassociation.
  • the MN may derive the PTK for the new AP once it determines the new BSSID it is roaming to and before the reassociation request is transmitted.
  • the MN can be ready to protect unicast communications to the new AP but must await the AP's reassociation response as acknowledgement that both parties can now secure unicast communications.
  • the AP's reassociation response also includes delivery of he broadcast keys (GTK) to enable full protected communications.
  • GTK broadcast keys
  • CCKM introduces EAPOL key descriptor enhancements similar to those defined in SSN/TGi to affect a CCKM rekey.
  • SSN or TGi's information elements SSN IE and RSN IE respectively.
  • CCKM capabilities can be negotiated. Currently both specifications allow the negotiation for an authenticated key management suite.
  • the suite selector encapsulates both an authentication and a key management mechanism, the assigned values are described in table 300 in Figure 3.
  • Column 302 is the Organization Unique Identifier (OUT)
  • column 304 is the type conesponding to the OUI in column 302
  • column 306 is the description for the OUI in column 302.
  • Both AP and MN must support CCKM for interoperability. The AP must advertise
  • CCKM capability must be advertised in beacons and negotiated during probe response and association request. Successful negotiation of CCKM enables the centralized key management defined in this specification. Enabling CCKM also implies activation ofthe
  • the SCM is designed to provide context control for a subnet and affect client context transfers upon a roam.
  • the SCM is a module that can coexist in an AP, be a standalone server, or coexist in an AS. While the SCM is designed to affect full inter-subnet mobility, this design only employs the components required to affect intra-subnet mobility. These elements include:
  • an MN's security credentials include an NSK, SSID, VLAN, session timeout, associated BSSID and possibly also authentication mechanism, key management mechanism and cipher suite negotiated at association.
  • the credentials are used to validate the session before a context transfer and PTK can be delivered.
  • an AP's security credentials include an NSK, session timeout and list of associated MNs
  • the SCM maintains a cache of all registered MN contexts within a given subnet including the MNs' NSKs (shown in Figure 4).
  • the cached credentials for an AP are slightly 5 different and are described in Figure 5.
  • column 402 lists the SCAM cache of MN credentials, comprising the fields State 408, STA Addr 410, Authentication type 412, Key Management Type 414, Session Timeout 416, KRK 418, BTK 420, RN 422, SSID 424, VLAN ID 426, BSSID 428, Cipher 430, NSK Key length 432, NSK 434, Tx Key Length 436 and Tx Key 438.
  • the length in bytes and a description of these fields are provided in lo columns 404 and 406 respectively.
  • the AP's cached credentials comprise the state 508, Node-H) 510, NSK 512, Session Timeout 514, CTK 516 and key sequence counter 518 as shown in column 502.
  • the length and description of these fields are provided in columns 504 and 506 respectively.
  • the SCM establishes shared secrets with both the MN and APs. It uses the Key 15 Request Key (KRK) as the shared secret with MNs to authenticate key requests.
  • KRK Key 15 Request Key
  • CTK Context Transfer Key
  • CTKs are distributed by the SCM to the AP for protecting link communications . Note that while it has been suggested that NSKs be used to protect AP to SCM 20 communications, this would enforce a shorter session timeout and full reauthentications to tlie AS when link keys need updating.
  • Figure 6 shows the keys used to protect communication between assigned links. Note that BTKs are not used to protect messages directly, rather, it is used to derive PTKs used to protect communications between AP and MN.
  • the AS 602 uses NSK0 25 606 to communicate with the SCM 604.
  • the SCM 604 communicates with AP! 608 and AP2 610 using keys CTK1 612 and CTK2 614 respectively.
  • API 608 communicates with MN3 616 and MN4 618 using PTK3 622 and PTK4 624 respectively, while AP2 610 communicates with MN5 with PTK5 628.
  • the SCM 604 may also directly communicate with the mobile nodes, MN3 616, MN4 618 and MN5 620 using KRK6 630, KRK7 632 and KRK8 634 respectively.
  • PTKs are derived and refreshed based on a Rekey sequence counter and BTKs as defined or refreshed based on the NSK as decribed herein infra.
  • the fast handoff design provides a scalable infrastructure that is required to provide inter-subnet roaming in a subsequent release.
  • the SCM services coexist in any AP and thus an election mechanism may be defined to allow for the selection of an AP as the SCM provider, While there will be no initial support for SCM to SCM (e.g. lateral) communication to enable warm restarts, the election mechanism still enables cold standby.
  • the AP To secure communications with MNs, the AP must first authenticate and register with its SCM. Authentication is required to establish an NSK and registration allows secure communications between the SCM and the AP.
  • the AP's NSK is derived by the AP as a result of a successful 802. IX LEAP authentication with the SCM; the authentication server delivers the NSK to the SCM via the Radius MS-MPPE attribute also as a result of a successful authentication.
  • the AP identifies its SCM by listening to the SCM advertisement messages.
  • the AP Upon successful authentication with the SCM, the AP must then register itself with the SCM as a valid AP. Upon pre-registration, the SCM delivers a set of CTKs to the AP that is used to both encrypt and authenticate WLCCP messages between the SCM and the AP.
  • a message depiction of how an AP establishes the required NSK and CTKs is shown in Figure 7.
  • the AP must also establish the CTK to ensure that no rogue AP is introduced and compromise either NSK or CTK.
  • the authentication mechanism is similar to that used for bridges, where tl e configure LEAP username and password are used to authenticate with the AS.
  • Tasks performed by the AP are in column 702
  • tasks performed by the SCM are listed in column 704
  • tasks performed by the AS are in column 704.
  • the SCM is the 802. IX Authenticator for all nodes.
  • CTK establishment between the AP and SCM must be mutually derived.
  • a MN To secure communications, a MN must first authenticate with the network via 802. IX EAP authentication. The result of a successful authentication establishes a NSK that is used to establish the KRK and BTK used to respectively authenticate key refreshes and derive PTKs.
  • CCKM Like SSN, CCKM also initiates a session with a 4-way handshake to establish the KRK and BTK, for enabling protection of unicast traffic These handshakes are only required after successful authentication. Rekey requests either upon re-association or due to general key management rekeying (like cipher suite countermeasures) only require an authenticated 3- way handshake.
  • Figure 8 depicts a successful MN LEAP Authentication and registration with the SCM.
  • a mechanism is needed to pass the NSK from EAP supplicants which are independent of the CCKM module.
  • the MN's NSK is usually generated in the EAP supplicant and passed to the EAP framework.
  • the EAP framework will then pass the NSK to the CCKM module. Since the current SSN-capable EAP framework treats CCKM as non-SSN compliant, it will just process the 802.1X EAP authentication and send down the NSK after an EAP authentication success. Similarly, non-SSN EAP supplicants will simply process the 802. IX EAP authentication and send down the NSK after an EAP authentication success.
  • the AP needs to send an additional 802. IX EAPOL key message with a dummy group key right after sending an EAP-Success message to the station. It is up to the implementation in the CCKM module to indicate to the AP that it needs to send an additional EAPOL key message. This information could be negotiated during the association request RSNIE. An alternate solution is to always send the dummy EAPOL key message after EAP Success message. The CCKM module can ignore the dummy key if it already has the NSK and establish the real keys post the four-way handshake.
  • association exchanges will always trigger a full authentication and 4-way handshake. Receipt ofthe CCKM rekey elements will be ignored. An additional 2-way handshake is used to rekey the multicast/broadcast keys (GTK).
  • GTK multicast/broadcast keys
  • the rekey protocol for GTK management is the same as specified in TGi and SSN.
  • the 2- message handshake is initiated by the AP to deliver the GTK over and encrypted EAPOL Key message.
  • the cunent PTK is used to protect these EAPOL Key messages.
  • an AP will always request the SCM for security credentials during a pre-registration request/reply. Associations imply session initiation and thus, upon an association if security credentials are valid in an SCM and CCKM is negotiated then 802. IX authentication can be bypassed. However fresh KRK and BTKs must be established. If no security credentials exist, then the AP must expect full authentication between MN and AS. After a successful authentication, the sequence shown in Figure 10 is triggered to complete the key establishment and result in the necessary PTKs used to protect packets between AP and MN.
  • APs can trigger (re)authentications before the session timeout expires and can also manage the update ofthe KRK and BTK refreshment as defined herein.
  • Either MN or AP can trigger a PTK rekey.
  • Conditions in which either node may request a rekey include: TKCP failures, particularly in Michael countenneasures; Exhaustion of TV (mainly for WEP) and Countermeasures if the node feels the PTK has been compromised.
  • the rekey exchange is a 3-message EAPOL Key handshake. A new key descriptor is defined to allow for a secure rekey exchange, which is shown in Figure 11. The fields are defined as follows: Key Information 1102: designates whether it is a request (0) , response (1) or confirm
  • Status 1104 is used by the responder and confirmer. A zero value means success; non-zero means the rekey failed and either a full KRK, BTK or deauthentication must be invoked;
  • EAPOL Replay Counter 1106 is the EAPOL Key message counter also used to protect from message replays
  • Reserved field 1108 an extra byte is added to better align the element
  • Key-ID 1110 1 byte field that stored the key identifier (0, 1, 2 or 3) assignment, it must match the currently assigned key ID;
  • MN-ID 1112 the client's MAC address
  • BSSID 1114 the AP's MAC address
  • RN 1116 the rekey request number
  • MIC 1118 authentication element using the cunent PTK.
  • the rekey sequence 1200 is shown in Figure 12.
  • the left column 1202 shows tasks performed by the initiator while the right column 1204 shows tasks perfonned by the responder.
  • the State transition calls for a new PTK.
  • t Transmission to responder is halted until a valid response or timeout is reached. Reception with PTK RN must be allowed. Request use of PTK RN in Key ID is sent. The responder receives the request.
  • the responder does not update PTK or send a response with non zero status.
  • the responder will update RN and compute PTK RN+1 , flush MN transmit queue, install PTK RN+1 and Respond ready to xmit and rev with PTK RN+1 (once response is sent, rcvd packets from MN using PTK RN will not decrypt properly).
  • the initiator then receives the responder's response. As shown in block 1212, if the MIC respon s e or any EAPOL Key attribute is invalid, the rekey is aborted and the initiator will try again. However, if as shown at block 1204 the MIC reSp0nse and EAPOL Key attributes are valid, then the initiator installs PTK KN+1 and is ready to xmit and rev with PTK RN + I . The initiator then sends an EAPOL Key confirm message.
  • the responder then receives the EAPOL confinn message.
  • the responder will either trigger another rekey, determine it's a spoof and disassociate or deauthenticate.
  • the link is now protected using PTK RN + I
  • the AP On a successful rekey, the AP must synchronize the SCM's RN value for the MN. It is recommended that the synchronization be made at every rekey.
  • a WLCCP_CONTEXT message with a WTLV_UPDATE_RN is sent to the SCM.
  • the protocol ofthe present invention allows for this function and thus facilitate a smoother transition during a rekey operation. That is, the requestor can install PTK RN + I into a new KeylD and thus enable reception of packets under either PTK RN or PTK RN + I . Similarly, the responder could plumb the key in the alternate specified Key ID and also allow transmission and reception under either key. The final confirmation is to halt transmission and reception under the cunent (old) PTK RN -
  • CCKM uses the SSN and TGi style of rekeying for updating multicast (GTK) keys and is thus not defined in this specification.
  • GTK multicast
  • a new proprietary element 1300 is introduced to facilitate the handoff in the re-association messages.
  • the element in the re-association request includes the rekey request number (RN) and an authenticated element .
  • RN rekey request number
  • MIC MN 1314 HMAC-MD5(KRK, MN-ID
  • Element ID 1302 is a Cisco defined element whose value is 0x9c Length 1304 should be the length ofthe CCKM element request (e.g. 24 bytes)
  • OUI 1306 should be 00:40:96
  • OUI 1308 Type should be 0
  • MN-ID (not shown) is the MN's MAC address
  • Timestamp 1310 is the cunent TSF timer value
  • RN 1312 is the rekey request number
  • RSNIE MN (not shown) is the MN's requesting security policy (e.g. AKM and cipher suite negotiation);
  • CCKM (now shown)must be specified in the AKM selector of RSNIE MN
  • the re-association response includes a new element authenticating 1400 the request, confinning use of PTK R N and delivering the multicast key as shown in FIG 14.
  • EGTK RC4(RN
  • MIC AP 1402 HMAC-MD5(PTK RN , MN-ID
  • the handoff occurs in the re-associate request/response exchange.
  • the MN 1502 must include CCKM 1528 in the RSNIE 1530 to employ the fast handoff. More importantly, the security policy negotiated by the MN 1502at reassociation must match to the one specified at initial association.
  • the SCM 1506 must validate that the requesting RN 1532 value is greater than the previous one.
  • the timestamp provided in the request must also be within a configurable value ofthe AP's TSF timer (not shown); the timestamp is included to ensure that this request is fresh.
  • the AP 1504 On a response, the AP 1504 must also provide it's TSF timer value in tlie CCKM response element to assure the MN 1502 that the response is also fresh.
  • the AP 1504 When the AP 1504 receives a re-association request and CCKM is negotiated, it must query the SCM 1506 for validation of security credentials and acquire the RN and BTK before it can generate PTK RN . The request is made using a WTLV_SECURE_CONTEXT request to the SCM 1506. If the SCM 1506 cannot validate credentials, then it will not deliver anything and provide a non-zero status indicating failure. On a successful transfer, the SCM 1506 will deliver the RN and BTK in an encrypted and authenticated WTLV_SECURE_CONTEXT reply. The validation of security credentials prevents an insider from fast reassociation with a different SSID.
  • the AP 1504 proceeds to generate the PTK as described herein infa. It will then use the PTK to encrypt and authenticate the new information element to affirm PTK and securely deliver the multicast key, GTK. If CCKM is negotiated but no proprietary element is provided, the AP 1504 can still request for security credentials. If credentials are valid then a full WTLV_INIT_SESSION establishment of fresh KRK and BTK is triggered and upon a successful 4-way exchange, KRK and BTK are mutually derived by SCM 1506 and MN 1502 and RN is reset to 1. If there are no credentials or the request to the SCM fails, the AP may choose to enforce a full (re)authentication.
  • the client station is ready to decrypt unicast packets before the client initiates the re-association request.
  • the client confirms its identity in the re- association request by using an incrementing authenticator (request number) and conesponding authentication (MIC).
  • the AP 1504 uses the re-association response to confirm its identity and to piggyback the multicast key infonnation (GTK) to the client STA.
  • GTK multicast key infonnation
  • RN unique request number
  • the client will increment the RN.
  • the SCM prevents replay of a fast re-association request by caching the last RN used by the client, and rejecting any request for which the RN is less than or equal to the cached last RN.
  • the derivation ofthe credentials and keying information includes the BSSID to prevent replay attempts across different APs. For example, without the BSSID, a hacker could attempt to reuse a fast-reassociation request for one AP to associate to a second AP. Which attempt will reach the SCM first - the hacker or the true client - depends on the delays through the network.
  • the SCM 1506 information can also be cached at the AP 1504. h this case, the AP 1504 could perform all ofthe calculations that would normally be done at the SCM 1506.
  • the AP 1504 can verify the authentication of a client, without having to query the SCM 1506 to obtain the latest RN, as the last RN used for a particular BSSID is sufficient to prevent replay.
  • the AP 1504 should send an update to the SCM 1506 to ensure that the SCM 1506 has the latest RN information - this is particularly important if the AP should stale the information and request the information from the SCM later.
  • the process for the reassociatoin starts at 1510 wherein a MN 1502 advances RN and generates a new PTK RN • As shown at 1512, the MN 1502 sends the Re-Assoc Request to the AP 1512 which includes RN 1532, RSNIE MN 1530 with CCKM 1528 as the negotiated key management value.
  • the AP 1504 then sends a WLCCP(MN, Pre-Reg Req, WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, MIC KRK ) to the SCM 1506 as shown by 1514.
  • the SCM 1506 responds with WLCCP(MN Pre-Req Reply, WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, BTK) as shown by 1516.
  • the AP 1504 authenticates and decrypts the BTK for the MN 1502 using it's AP's CTK and derives PTK RN -
  • the AP 1504 sends Re-Assoc Resp(RN, RSNE AP Nonceo TK E(PTK, GTK), MIC(PTK, MN-ID, BSSID, RN, RSNIEAP, Nonce GTK , E(PTK,GTK)) which completes the liveness of PTKR N and delivery ofthe GTK.
  • the MN 1502 authenticates and decrypts the GTK for this STA using PTK.
  • the AP 1504 registers the MN 1502 as being active with the AP 1504. This is accomplished by steps 1524 and 1526.
  • a WLCCP(MN, REg Req) is sent from AP 1504 to SCM 1506 and the reply is sent at step 1526 as WLCCP(MN Reg Reply). While this design promotes the use of CCKM, other Authenticated Key Management
  • CCKM-capable MNs are the only MN types that have their credentials cached at the SCM and thus require registration. However, in order to properly propagate credentials to the AP, all MNs require pre-registration. Whether supporting a legacy or SSN-capable client the credential propagation and pre-registration is the same, as shown in Figure 16.
  • a key hierarchy is defined to allow for stretching keys as well as derivation of fresh keys. This section describes the functions used to derive the keys. A comment must be made though, to address the issue of key entropy.
  • CCKM ensures key freshness but relies on the provisioning of strong keys; e.g. having good entropy. If implementations like LEAP which are password based are believed to have low entropy then further crypto tools can be used to improve the key's entropy.
  • TGi has already adopted a variation of PKCS#5 as a means of improving key entropy which this design can easily adopt. Note however, that this requires far more computation that some NICs can provide.
  • the AP and MN engage in a 4-way handshake to provide key material required for deriving KRK and BTK.
  • Each node must provide 16byte nonces that are subsequently used with the NSK to derive the required keys.
  • the function is defined as follows:
  • GK PRF-384(NSK, "Cisco Key Management Base Key Generator”
  • PRF-384 is defined in Section 0.
  • WLCCP messages are encrypted using RC4 and authenticated using HMAC-MD5.
  • An AP establishes a CTK with the SCM during pre-registration so that it can commence protection of WLCCP messages.
  • the CTK is a 256bit key that is used to protect WLCCP messages as follows: • The low order 128bits of CTK is used as the RC4 key. • The high order 128bits of CTK is used as the HMAC-MD5 key CTK Key Derivation:
  • Context transfer keys used between the AP and SCM are generated and distributed by the SCM. Each node in the link must provide an 16 byte nonce to assure a fresh key:
  • CTK PRF-256( NSK, "SWAN IN - IA link Context Transfer Key Derivation"
  • the CTK is computed by the SCM and delivered to the AP for protecting subsequent WLCCP messages. Delivery ofthe CTK is done by encrypting and authenticating the key using the NSK.
  • PTKs are a maximum of 512 bytes as they are used to protect both 802. IX and 802.11 communications. Its length is dependent on the 802.11 cipher suite negotiation established at association.
  • PTKs are derived by use of a one way hash function: SHA-1 and is based on the BTK, RN and BSSID:
  • PTK PRF-Len(BTK, RN
  • BSSID) where Len 384 for WRAP or CCMP, 512 for TKJJP or CKTP
  • EAPOL-Key MIC Key PTK[0 127]
  • EAPOL-Key ENC Key PTK[ 128 255]
  • H-SHA-1(K, A, B, X) HMAC-SHA-1(K, A
  • X) where Y is a single octet containing 0x00 (zero) PRF-384(K, A, B) PRF(K, A, B, 384)
  • PRF-512(K, A, B) PRF(K, A, B, 512) PRF(K, A, B, Len)
  • A_SHA_CTX context unsigned char k_ipad[65]; /* inner padding - key XORd with ipad */ unsigned char k_opad[65]; /* outer padding - key XORd with opad */ int i;
  • * opad is the byte 0x5 c repeated 64 times
  • HMAC-SHAl Test vectors (extracted from the SSN draft): The test vectors for HMAC_SHA1 are from rfc2202 and have been checked against the reference code above. The PRF test vectors have been checked against two other implementations.
  • PRF 0x51f4de5b33f249adf81aeb713a3c20f4fe631446fabdfa58 244759ae58ef9009a99abf4eac2ca5fa87e692c440eb40023e
  • PRF 0xelac546ec4cb636f9976487be5c86bel7a0252ca5d8d8dfl2c
  • WLCCP Wireless LAN Context Control Protocol
  • SWAN Session Management Networking
  • a WLCCP registration protocol a) automatically creates and deletes links in the SWAN topology, b) securely distributes operational context, and c) (optionally) reliably s establishes Layer 2 forwarding paths on wireless links.
  • a WLCCP SCM advertisement/election protocol automatically establishes a single SCM as the central control point for each subnet, and enables APs and MNs to select the parent node that provides the "least-cost path" to a backbone LAN.
  • WLCCP "Context” messages provide a general-pu ⁇ ose transport for context o and management information.
  • WLCCP "Trace” messages facilitate network diagnostic tools.
  • WLCCP is a transaction-oriented "request/reply" protocol. All WLCCP request and reply messages have a fixed-length header that contains message-type-dependent fields. Optional Type-Length- Value pairs follow the fixed length header; therefore, WLCCP is extensible. 5 Ethernet or UDP/IP encapsulation can be used for WLCCP messages. Ethernet encapsulation is restricted to intra-subnet (e.g. AP-to-AP or AP-to-SCM) WLCCP messages. IP encapsulation must be used for inter-subnet WLCCP messages and may also be used for intra-subnet WLCCP messages. As those skilled in the art can readily appreciate, a specific WLCCP implementation may not include all ofthe components described herein.
  • a “distributed” context transfer protocol can be used to directly transfer context from an "old AP" to a "new AP", when a MN roams.
  • the IEEE 802.1 If draft protocol for example, defines a distributed context transfer protocol.
  • the SWAN network disclosed herein is organized as a hierarchical "Topology Tree".
  • a station roams from an "old AP" to a "new AP
  • context is generally transfened via the "nearest common ancestor", in the Topology Tree, of both the old and new APs.
  • WLCCP registration includes the necessary routing logic to automatically find the nearest common ancestor.
  • Cached configuration and context infonnation is stored in the network infrastructure.
  • the common ancestor securely forwards the cached information on the new Topology Tree branch for a station that has roamed. Therefore, context transfer is automatically "localized” and context information is not lost if the link to an old AP is lost.
  • the common ancestor also forwards the "old AP bindings" to the new AP.
  • a many-to-many security relationship between 802.11 APs is not needed for secure context transfer in a SWAN network. Instead, a trust hierarchy is established that conesponds to the SWAN Topology Tree. Operational context is generally forwarded on Topology Tree branches; therefore, WLCCP context transfer keys are pre-established between all SWAN nodes on the same topology tree branch. If it necessary to transfer context "laterally" between 2 nodes on different topology tree branches, then the nearest common ancestor ofthe 2 nodes can function as a trusted third party to quickly establish mutual authentication and a transient context transfer key.
  • the hierarchical Topology Tree facilitates central management and control points. For example, network-wide parameters can be centrally configured and distributed.
  • a central WLCCP control point establishes and deletes topology links; therefore, it is possible to maintain a consistent network topology even if hand-off messages for rapidly roaming stations arrive out-of-order.
  • a locally or globally administered 48-bit IEEE 802 address is used as an internal WLCCP network Node Address.
  • An IP address is not used as a Node Address because: a) A node may change its IP address, b) WLCCP is used to manage Layer 2 mobility; it should generally be independent of any network layer protocol.
  • a WLCCP Node Address is an internal WLCCP node identifier and should NOT be used to identify APs and CMs to users in network management applications. Instead, a Network Access Identifier (NAT) or domain name can be used as a user WLCCP node identifier.
  • NAT Network Access Identifier
  • the target environment is an ente ⁇ rise "campus network”.
  • 802.11 is an Ethernet access technology, which is used to extend wired Ethernet backbone LANs to Mobile Nodes and select "secondary LANs".
  • An 802.11 AP is, effectively, a Layer 2 "Ethernet" bridge.
  • An 802.11 Mobile Node is, effectively, a mobile "Ethernet” node.
  • WLCCP is generally independent ofthe underlying radio technology.
  • a MN should be able to roam seamlessly within a single subnet or between subnets within a "campus network" and operate as if attached to an Ethernet switch port; therefore, is necessary to transfer location-specific operational context when a MN roams.
  • Non- WLCCP Ethernet bridges and switches must support backward-learning, as defined in the 802. ID standard. 9) WLCCP must provide context management services for an integrated Proxy-
  • the seamless mobility solution must support both IP and non-EP applications; it must not require client support; and it must not require users to significantly change their existing wired topologies.
  • WLCCP does NOT facilitate (or preclude) seamless roaming between subnets in different geographic locales.
  • a campus network may include a large population of stations that roam frequently; therefore, the overhead for roaming must be minimal.
  • WLCCP must support very fast roaming for QoS applications.
  • WLCCP must support existing WLAN features, include wireless (i.e. repeater) APs, wireless bridges, and mobile APs and bridges.
  • WLCCP must support fast, secure context transfer, without introducing a need for many-to-many security relationships between APs.
  • WLCCP must operate independently of any underlying Spanning Tree Protocol.
  • WLCCP must not significantly increase user configuration requirements; therefore, the underlying topology must be largely self-configuring.
  • WLCCP must not introduce single points of failure.
  • the network must continue to operate, possibly with reduced features, if a SWAN node or link fails.
  • WLCCP must leverage existing standards, as much as possible.
  • WLCCP must not interfere with existing protocols. In particular, WLCCP must not preclude standard Mobile IP clients. 21) Client MNs must NOT be required to directly support WLCCP. Instead, MNs can indirectly support WLCCP via 802.11 elements.
  • WLCCP must provide building blocks for WLAN management and diagnostic tools.
  • the radio coverage of APs on different subnets may overlap.
  • WLCCP secure context transfer and message authentication is independent of the underlying security infrastructure, except that it must be possible to mutually authenticate SWAN nodes and establish secret session keys.
  • WLCCP does NOT provide MN authentication; however, it must facilitate fast lo re-authentication by securely transfening dynamic MN security credentials.
  • a SWAN network is a "tree topology" rooted at a SWAN CM.
  • WLCCP is used to establish and maintain the Topology Tree.
  • An example Topology Tree for a full WLCCP implementation is shown in figure 17.
  • Figure 17 shows a "campus topology” with two local control domains (LCM) 1706 and 1706 and three subnet control domains (SCM) is 1708, 1710 and 1712 .
  • the example network includes a Work-group Bridge (WGB-1) 1714 and its attached Ethernet Nodes (EN-1 and EN-2, 1716 and 1718 respectively).
  • Topology branches that exist over 802.11 links are shown as dashed lines 1720a - f.
  • Possible subnet topology components are specific to the WLCCP implementation.
  • SWAN CMs and APs are interior nodes (INs) and MNs and secondary Ethernet Nodes (ENs) are leaves in the SWAN Topology Tree.
  • the SWAN CCM 1702 is at the root ofthe campus Topology Tree.
  • the CCM 1702 is the root CM, in a campus network.
  • An LCM 1704, 1706 is at the root of the sub tree contained in a Local Control Domain.
  • a WLCCP Node ID is shown in table 1800 of FIG 18.
  • a 64-bit WLCCP Node ID identifies each node in a SWAN network.
  • a Node ID is a concatenated 16- bit WLCCP Node Type 1802 and a 48-bit WLCCP Node Address 1804.
  • the Node Address 1804 for a MN, EN, AP, or SCM is a global 48-bit IEEE 802 address.
  • the Node Address 1804 for an LCM or CCM can be a global or locally-administered 48-bit IEEE 802 address. It is contemplated in one embodiment, the CCM can automatically assign "local" 48-bit addresses to itself and other LCMs.
  • a Node Address of 'all zeros' is used to identify the "local WLCCP node" in a WLCCP CM or AP.
  • the Node Type is CCM, LCM, SCM, AP, MN, or EN.
  • Each physical AP (e.g. Ethernet and 802.11) communications interface is identified by a 48-bit IEEE 802 port address.
  • An SCM's LAN communications interface is also identified by a 48-bit IEEE 802 port address.
  • An 802 port address can be re-used as the WLCCP Node Address.
  • Each WLCCP CM must have an IP communications interface, which is identified by an IP port address.
  • An IP port address is not used as a CM node address because a CM's IP address may change.
  • AP communications interfaces generally operate in "promiscuous mode"; therefore, an AP can receive WLCCP frames destined to its Node Address on any physical interface, a simple implementation, the AP Node Address can be used to identify an "internal WLCCP interface" in an AP.
  • Figure 19 shows the internal bridging structure in an AP.
  • the Ethernet 802 port address is also the WLCCP Node Address.
  • a frame, which is destined to the Node Address and received on either the Ethernet or 802.11 interface, is "bridged" internally to the WLCCP protocol interface; therefore, the Node Address' can also be used as the WLCCP "Hop Address" on any AP port.
  • WLCCP and DDP are shown together because they share the same Ethernet DIX type.
  • Each WLCCP AP and CM should be configured with a permanent "node name" [e.g. Network Access Identifier (NAI) or a DNS domain name].
  • NAI Network Access Identifier
  • An LCM must be configured with a node name to request a locally administered Node Address from the CCM.
  • a Node ID is NOT a permanent node identifier and should not be used as such.
  • An NAI can be used to represent network nodes to users.
  • An Instance Identifier and its Node ID identify each "instance" of an "Attached" AP or CM.
  • an Instance Age is used as the instance identifier, as described below.
  • Each WLCCP CM must maintain cross-referenced tables that are used to map a WLCCP Node ID to a node name or EP address, or vice-versa.
  • each SWAN AP 1722, 1724, 1726, and 1728 CM 1704, 1706, 1708, 1710, 1712 other than the SWAN CCM 1702 is bound to a single "parent node" and to a single "parent CM".
  • the parent CM for an LCM is the CCM.
  • the parent CM for an SCM is an LCM.
  • a single device may include multiple logical CMs. The device that contains the CCM always contains a logical LCM.] h figure 17, the parent node and parent CM, for AP 1720 ,are AP 1728 and SCM 1712, respectively.
  • the SCM for each subnet is the parent CM for all APs on its subnet and for all MNs that are associated with those APs.
  • a MN is a child ofthe SCM for the parent AP's "native" subnet even if the MN is bound to a different "home subnet" via VLAN trunking or Proxy MIP tunneling.
  • SCM 1708, AP 1722 and AP 1724 all belong to the same subnet.
  • MN 1730 is a child of AP 1722; therefore, it is a child of SCM 1708. However, MN 1730 may belong to a different subnet if AP-1 is attached on a VLAN trunk link.
  • the "parent node” for an LCM or SCM is the parent CM.
  • the parent node for a MN is the 802.11 parent AP.
  • the parent node for a "root AP” is an SCM.
  • the parent node for a non-root AP is the 802.11 parent AP.
  • a node is considered a "child” of its parent.
  • a “neighbor” is a parent or child node.
  • a logical "link” exists between a node and each of its neighbors.
  • a "port” is the logical entity that provides access to a link.
  • Each CM and AP has a single primary port and one or more secondary ports.
  • a node attaches to the network on its primary port. Multiple logical ports may exist on top of a single physical communications interface. For example, in figure 17, AP 1728 may use the same physical 802.11 interface to access the link to AP 1736 and AP 1738; however, AP 1728 has a separate logical port for
  • a "branch" ofthe Topology Tree is comprised of a set of nodes and links that provide the shortest path between an "ancestor" node and a "descendant" node.
  • An inbound node is an ancestor and an outbound node is a descendant. All nodes are descendants ofthe root CM 1702.
  • An outbound path originates from an ancestor node and terminates at a descendant node.
  • An inbound path originates at a descendant node.
  • SWAN CMs are NOT in the forwarding path for non- WLCCP messages; therefore, a node's SWAN "path instance" is NOT the same as the node's data forwarding path.
  • a Topology Tree "link” exists between each SWAN node and each of its neighbors.
  • a link is established when a "child node” selects a "parent node” and registers with the SWAN infrastructure via its parent node.
  • An SCM-to-AP link is always an Ethernet link.
  • An AP-to- AP link can be an Ethernet or 802.11 link.
  • An AP-to-MN link is (cunently) always an 802.11 link.
  • a CM-to-CM link can, conceptually, be any link that supports IP.
  • a node is responsible for maintaining the "link state" for each of its neighbors.
  • An active link is in a "connected” state.
  • a link transitions to a "disconnected” state if the underlying physical communications link is lost or if a child roams to a different parent node.
  • a node must be able to detect link state changes in its neighbors; otherwise, links may exist in a "half-connected” state.
  • AP-to-AP 802.11 link state is transparent to WLCCP implemations where WLCCP is not used for Layer 2 path updates.
  • the CCM's IP address or domain name must be statically configured in each LCM and in each SCM candidate. It is contemplated that in one embodiment an LCM or SCM can automatically discover the CCM, via a CCM Advertisement Protocol.
  • the list of subnets that are bound to each LCM is configured in the CCM.
  • An SCM sends a request message to the CCM, initially and whenever any parent LCM is lost, to obtain its parent LCM assignment.
  • An SCM is automatically elected for each subnet.
  • An AP automatically discovers its parent SCM, via an SCM Advertisement Protocol.
  • a non-root "child AP” is also bound to a "parent AP”, as described below.
  • a MN is bound to a parent AP via the 802.11 association protocol.
  • a node is either in an "Attached" or "Unattached” state.
  • a node is initially in the Unattached state.
  • a CCM candidate transitions to the Attached state when it becomes the active CCM.
  • a CCM transitions to the Unattached state when it relinquishes the CCM role.
  • a non-CCM node transitions to the Attached state when it initially registers with the SWAN infrastructure.
  • An Attached non-CCM node transitions to the Unattached state if a) it detects that is parent node is unattached, or b) it is unable to communicate with its parent node.
  • Each CM must maintain an internal Instance Age that contains the elapsed time, in seconds, since the node last transitioned to the Attached state.
  • the Instance Age is initialized to 0 and is reset to 0 each time the node initially registers with a new parent CM.
  • the Instance Age of an SCM is copied into the Instance Age field in SCM- Advertisement Reply messages, so that a child AP can detect a new instance of its parent SCM.
  • a child AP becomes Unattached if it receives an advertisement message with a lower Instance Age.
  • an AP does not need to maintain an Instance Age if WLCCP is not used for Layer 2 path updates.
  • a SWAN network generally operates in "campus infrastructure mode" with a single CCM and conesponding Campus Control Domain.
  • An LCM and its corresponding Local Control Domain must operate in "local stand-alone mode” if the LCM cannot communicate with the CCM.
  • An LCM must also operate in stand-alone mode if it is not assigned to a CCM.
  • each SCM and conesponding subnet must operate in "subnet stand-alone mode", if the SCM is not assigned to a parent LCM.
  • h stand-alone mode a Local Control Domain or Subnet Control Domain operates much like a SWAN campus network.
  • An LCM operating in local stand-alone mode assumes CCM functions.
  • the LCM or SCM at the root of a stand-alone domain functions as the 802. IX authenticator for both infrastructure nodes and MNs.
  • a Local or Subnet Control Domain must be able to transition smoothly between infrastructure mode and stand-alone mode.
  • An LCM is configured with the IP address ofthe CCM, to operate in infrastructure mode. If an LCM is operating in stand-alone mode because it lost the link to its assigned CCM, then it must periodically attempt to re-establish communications with the CCM.
  • An SCM is configured with the IP address or domain name of the CCM, to operate in infrastructure mode.
  • the CCM is responsible for assigning each SCM to an LCM, as described below in the section entitled "W2 - Parent LCM Assignment".
  • An AP must operate in a fallback "distributed mode" if it cannot discover an SCM for its subnet.
  • An AP must be able to transition smoothly between infrastructure mode and distributed mode. For example, an AP can use the existing Cisco Datagram Delivery Protocol in distributed mode. Note that a user can force APs to operate in distributed mode by simply not configuring any SCM candidates.
  • an LCM or SCM can transition smoothly from infrastructure mode to stand-alone (i.e. when the link to its parent is lost) mode without disconnecting nodes in its sub tree. Nodes in a "new" stand-alone domain can continue to use existing registration information and security credentials, which were previously established in infrastructure mode.
  • the sub tree rooted at an LCM or SCM must be rebuilt when the LCM or SCM transitions from stand-alone mode to infrastructure mode.
  • An SCM or LCM establishes a new Instance ID when it transitions from stand-alone to infrastructure mode.
  • An SCM also establishes a new Instance ID if its parent LCM changes.
  • the sub tree rooted at the SCM or LCM is automatically deleted as nodes in the sub tree detect the new SCM or LCM instance.
  • WLCCP "Context Management" message types are listed below.
  • a "request” and "reply” subtype is defined for each message type.
  • An optional “confirm” and "ack” subtype is defined for select message types that require additional handshaking.
  • a "Response-Req" Flag is set ON in a Request message to solicit a Reply message.
  • a reply message is used to acknowledge a request message and to return status and/or context information to the Originator.
  • a request "message identifier" is copied into the conesponding reply message to "match" request/reply pairs. The same message identifier is used in retransmitted request messages, to identify all request/reply messages that belong to a single transaction.
  • An optional "Confirm” message can be used to acknowledge a Reply message and return status and/or context infonnation to the Responder.
  • the Response-Req Flag is set ON in a Reply message to solicit a Confirm message.
  • An optional "Ack" message can be used to acknowledge a Confirm message and return status and/or context information to the Originator.
  • the Response-Req Flag is set ON in a Confirm message to solicit an Ack message.
  • WLCCP messages contained a fixed-length header, followed by optional, variable- length TLVs.
  • An SCM sends periodic SCM-Advertisement-Reply messages to advertise network parameters and availability and to facilitate the SCM election protocol, on each AP "native" subnet.
  • APs automatically discover the active SCM for the local subnet by monitoring SCM advertisements.
  • APs receive SCM advertisements on a "primary port” and forward SCM advertisements on "secondary ports” to propagate SCM and subnet information to descendent nodes in the SWAN topology.
  • a node can send an SCM-Advertisement-Request message to solicit an SCM- Advertisement-Reply message (e.g. to shorten the discovery period).
  • a CCM can, optionally, send periodic CCM- Advertisement-Reply messages to advertise network parameters and availability and to facilitate a CCM election protocol.
  • LCMs and SCMs can automatically discover the active CCM by monitoring CCM advertisements.
  • CCM-Advertisement Request and Reply messages are sent to an IP multicast address.
  • a node can send a CCM- Advertisement-Request message to solicit a CCM- Advertisement-Reply message.
  • a Registration-Request message is used to request registration for a MN, AP, or CM with the SWAN infrastructure.
  • a SWAN node is always registered with the CCM and each LCM, SCM, and AP on the path to the CCM.
  • a Registration-Request is always forwarded inbound on a single branch in the SWAN topology.
  • An "update" Registration Request is used to refresh a Path Instance and to update cached dynamic context information.
  • a CM returns a Registration-Reply to acknowledge receipt of a registration request, establish a "path instance", and to return context information, including any "old mobility bindings".
  • Registration-Reply messages establish the Layer 2 forwarding path on wireless links.
  • a Registration-Reply is always forwarded outbound on the reverse path ofthe conesponding request.
  • Preregistration Request and Preregistration Reply messages are used to obtain security credentials and establish the authentication state for an 802.11 MN or child AP prior to registration.
  • a CM sends a Deregistration-Request message to request deletion an old path instance when a station roams.
  • a Deregistration-Request is always generated by a CM (SCM, LCM, or CCM) and is always forwarded outbound on a single branch in the SWAN topology.
  • An AP or CM returns a Deregistration-Reply to acknowledge receipt of a Deregistration Request, delete the respective path instance, and (optionally) to return context and status information. Transient accounting statistics and an activity timestamp are (optionally) returned in the Deregistration Reply.
  • An AP or CM sends a Detach-Request message to its parent CM to indicate that a "detached" child station should be “deregistered”.
  • a Detach-Request message is forwarded inbound until it reaches either a CM with a "newer" registration record or the CCM.
  • a CM can send a Detach-Reply message to acknowledge a Detach-Request.
  • a Context-Request message is used to get or set context, configuration, or management infonnation. Context messages provide a general-pu ⁇ ose transport for exchanging information.
  • a Context-Request can be used, for example, to initiate a lateral handoff when a station roams from an old LCM to a new LCM.
  • the new LCM or the old LCM may send the Context-Request.
  • a Context-Request that is generated by the old LCM may contain context and configuration information.
  • a Context-Request message can also be used to predictively forward mobility context for a MN to SCMs or APs. [A Context-Request that is used to "get" information contains one or more "request” TLVs.]
  • a Context-Reply message is used to acknowledge a Context-Request message. It is also used to return status information (e.g. for a "set” request) or context, configuration, or management information (e.g. for a "get” request) for a corresponding Context-Request message.
  • a Path-Update-Request message is used to re-establish tl e backward-learned path between a wireless station and each conespondent host, when the wireless station roams from an old AP to a new AP within a single subnet.
  • the Path-Update-Request is sent from the new AP to the old AP, with the source 802 address ofthe station that roamed.
  • a Path-Update-Reply message is, optionally, used to acknowledge a Path-Update- Request message and it is used to transfer transient context information directly from an "old AP" to a "new AP”.
  • a Path-Check message is used to implement a Reliable Path Update mechanism (i.e. to recover from lost Path-Update-Request messages).
  • a Trace-Request message is used for SWAN path testing, response time analysis, and station tracking.
  • a Trace-Reply is used to acknowledge a Trace Request.
  • AAA messages are encapsulated 802. IX EAPOL messages typically used for authentication. Alternately, AAA messages could also be typed to designate the beginning (START) or end (SUCCESS) of an AAA message exchange. Finally, AAA messages are also encapsulated Cisco accounting messages typically used by the AP to update the session accounting maintained by the AS.
  • CCKM Cisco's Central Key Management
  • initial key establishment between the MN and MN Authenticator is triggered by the MN Authenticator initiating a 4-way handshake by sending the MN an EAPOL Key message with a 16byte nonce. To achieve this, a nonce is passed from the MN Authenticator to the AP using an AAA Success message. Details ofthe key establishment is described in the Fast Handoff Protocol Specification [8]. This is the only EAPOL Key message generated by the SWAN Topology, all others are results of 802. IX EAP Authentication.
  • AAA messages are WLCCP encapsulations of 802. IX EAPOL or Cisco session accounting messages and thus do not follow the Request-Reply nonn. However, since Authenticators can detect authentication failures, the Status field provided in the outbound messages can provide more information to reflect authentication status.
  • Path-Init Request, Reply, Confirm, Ack are used for IN path authentication, where an IN mutually authenticates and establishes a path CTK with each of its ancestors.
  • the necessary path authentication 4-way handshake may consist of 1) a Path-Init Request/Reply exchange followed by an initial Registration Request/Reply exchange, or 2) a Path-Init Request/Reply/Confirm/Ack exchange. (The second sequence is used to refresh path CTKs for a registered IN.)
  • WLCCP fields are defined in network byte and bit order (i.e. big endian). The bits in each field are numbered from left to right starting with '0' (i.e. the high-order bit is bit '0').
  • WLCCP messages can be encapsulated in Ethernet frames or UDP/TCP/IP packets, Ethernet encapsulation can be used for intra-subnet messages sent between two APs or an AP and SCM, which are on the same subnet. IP encapsulation must be used for inter-subnet messages.
  • the WLCCP Ethernet DIX type is 0x872d.
  • the WLCCP UDP/TCP protocol port is decimal 2887. It is a "well-known" protocol port that is registered with the Internet Assigned Number Authority, A single WLCCP message format is used for both Ethernet and IP encapsulation. All
  • WLCCP messages share a common header format, which is defined below.
  • the header format is defined so that it is unambiguous with existing Ethernet and IP DDP message formats.
  • the WLCCP message body which follows the common header, contains SAP- specific message types. This document defines message formats for the WLCCP "Context Management" SAP, which is '0'.
  • the frame 2000 comprises the destination MAC address 2002, the source MAC address 2004, the DIX Type (0x872D for this example) 2006, WLCCP Common Header 2008, WLCCP Context management header 2010, Type-specific fields 2012, and Optional TLVs 2014.
  • Ethernet encapsulation can be used for WLCCP messages that are limited to a single subnet.
  • IP encapsulation is required for all inter-subnet messages.
  • Ethernet encapsulation is used for SCM-Advertisement messages and intra-subnet Registration, Deregistration, Detach, Path-Update, and Path Check messages.
  • UDP/IP encapsulation is used for CCM Advertisement messages and inter-subnet Registration, Deregistration, and Detach messages. Either Etliemet or UDP/IP encapsulation can be used for Trace messages.
  • Ethernet, UDP/IP, or TCP/IP encapsulation can be used for Context messages.
  • An "internal port” is a logical port that exists between an AP and SCM that are co- located in the same device.
  • FIG 21 there is a table illustrating the fields for a WLCCP Message Header 2100.
  • the columns comprise the Field Name 2102, Offset 2104, Size 2106 and a Description 2108 of each field ofthe message header 2100.
  • the length ofthe fixed WLCCP header 2100 is 28 bytes.
  • the fields Protocol ID/Version 2110, WLCCP SAP 2112 and Destination Node type 2114 are common to all WLCCP SAPs.
  • the remaining fixed fields are common to all Context Management frames (i.e. all frames defined in this document). If the Relay Flag is set ON, then the header is immediately followed by an 8-byte Relay Node ID field.
  • WLCCP_PROTO ID OxCO The WLCCP Protocol ID 2110, OxCO, is defined so that WLCCP and DDP messages can share the same DLX Ethernet type and UDP protocol port.
  • the DDP message header is defined in Appendix B.
  • the Destination Node Type 2114 and WLCCP SAP 2112 fields are used to select the internal destination within the device identified by the Ethernet or IP destination address.
  • the sender must set the Destination Node Type 2114 to the node type ofthe immediate receiver, before sending a WLCCP message.
  • T e Destination Node Type lllA can be '0' if the SAP uniquely identifies the internal destination.
  • the Hop Count 2116 field contains the number of WLCCP hops (minus one) between the Originator and Responder.
  • the Originator or Responder must initialize the Hop Count to '0'.
  • the Hop Count is incremented by each intermediate node on the path to the Originator or Responder. A message is discarded if the Hop Count exceeds WLCCP_MAX_HOP_COUNT.
  • WLCCP message Type 2118 definitions #defme WLCCP_TYPE_SCM_ADVERTISE 1
  • WLCCP "Reply" message types are equal to the conesponding request type ORed with WLCCP_TYPE_REPLY_MASK.
  • the Flags field 2120 is used as follows:
  • the Retry flag is set ON in retransmitted Request or Confirm messages.
  • the Message ID in a retransmitted message is the same as in the original message.
  • the Retry flag is set ON in a Reply or Ack message if it is set ON in the conesponding request message.
  • the Response-Req Flag is set ON in a request message to solicit a reply.
  • the TLV flag is set ON to indicate that optional TLVs follow the fixed fields.
  • the Inbound Flag, Outbound Flag, and Hopwise-Routing Flag determine how a WLCCP message is forwarded (as described below).
  • Root CM Flag is set ON in an inbound message, then the message is always forwarded to the CM at the root ofthe entire Topology Tree - the "root CM". If the Root CM Flag is set ON in an outbound message, then the message originated at the root CM.
  • the Relay Flag is set ON, then the WLCCP header is immediately followed by a 64- bit Relay Node ID field (a 16-bit Node Type followed by a 48-bit Node Address).
  • the MIC flag is set ON to in a message that must be authenticated and contains a WTLV_MIC TLV.
  • the Responder Node Type bits contain the Node Type ofthe WLCCP node that generated the original reply message.
  • the Originator Node ID 2122 generally, identifies the node that originated a request message.
  • the Responder Node ID 2124 generally identifies the target of a request message and the source ofthe conesponding reply message, h a WLCCP Registration message for a MN, the Originator Node ID is the 802 address ofthe MN.
  • the Responder Node ID may be '0' in Registration Request, Advertisement Request, or Detach Request messages.
  • the Responder Node ID may be '0' in any IP-encapsulated Request message.
  • the Responder Node ID identifies the source of a solicited or unsolicited Advertisement Reply message.
  • the Hop Source Node ID contains the WLCCP Node ID ofthe hop source of a request or reply message.
  • Optional parameters may follow the fixed fields in any WLCCP message.
  • Optional parameters are in the "TLV" fonnat as shown in FIG 22.
  • the TLV "Type” 2210 field contains a Container Flag, an Encrypted Flag, a Request Flag, a Group ID and a Type ID.
  • a "request TLV” has the Request Flag set ON in the Type ID field.
  • TLV Group IDs are used to group TLVs hierarchically.
  • a Group ID can be used to identify the software module in the target node that must process the respective TLV type.
  • the Request Flag is set on in a TLV in a WLCCP request message to "request" information from the target WLCCP node.
  • a "request TLV” has the Request Flag set ON.
  • the TLV Container Flag can be used to group fixed attributes and other optional TLVs into a single "container TLV”. The Container Flag should only be set ON in a TLV if any required TLV fields are followed by other optional TLVs.
  • Container TLVs can be nested.
  • WLCCP TLV formats are defined in the tables below.
  • the first row in each table contains the TLV name, TLV ID, and TLV description.
  • the description includes a list of message types that may contain the respective TLV.
  • the Type and Length fields are not included in the field definitions.
  • any parameters that are not contained in the WTLVJvIN_REG TLV are taken from the Registration message or the encapsulating WTLV_MN_REG_LIST TLV.
  • the table below shows the fields for an SCM Advertisement Reply Message.
  • a parent node sends an SCM Advertisement Request with the Unattached Flag set ON to quickly notify child nodes that it has become “unattached”. If it is unattached because the active SCM was lost, then it must also set the SCM Node ID to '0'.
  • the Instance Age field contains the "age” ofthe instance ofthe node that transmits an SCM- Advertisement Reply message, in seconds. (See the section entitled “Topology State Information" for a description of an "Instance Number”.)
  • An SCM Advertisement Reply message must include a WTLV_SUBNETJD TLV, which contains the IP address and subnet mask ofthe SCM.
  • An SCM Advertisement Reply message must include a WTLV_ROOT_CM_INFO
  • TLV which contains the IPv4 address of the root CM (which is also the 802. IX IN Authenticator).
  • An SCM Advertisement Reply message sent by an AP can include a WTLVJPV4_HOP_ADDRESS TLV, which contains the AP's IP address. #defme SCM_ADVERTISE_TNTERVAL 5 /* The default SCM advertisement interval is 5 seconds. */
  • the below table shows the fields for an SCM-Advertisement Request Message.
  • the Status field contains the registration status in a Reply message. Values from 0 to 126 are used to indicate a "good" status. The high-order bit is set ON to indicate an enor status. Values from 128 to 254 are used to return an enor status. A value of 255 is used to indicate that an extended enor status code is contained in a WTLV_STATUS TLV. Registration Reply status codes: 0 - General good status 0x80 - General enor status
  • 0x82 - Path Enor A path error was detected. The error will occur, for example, if a parent or relay node is not registered. 0x83 - Invalid Update. An update Registration Request did not match the current path instance or a path instance did not exist.
  • 0x86 Admin. Disabled.
  • the Requester node is administratively disabled.
  • 0x87 Max. Nodes.
  • the registration was rejected because the max. number of registered nodes was exceeded.
  • the Authenticated Flag is set ON in a Request for a MN, to indicate that the MN has been authenticated by the parent AP.
  • the flag is used to register authenticated MNs when an AP transitions from distributed to infrastructure mode. It is also set on for a MN where authentication is not required (i.e. open authentication).
  • the Proxy MIP Flag is set ON in a Registration message for a proxy MD? MN.
  • the L2 Path Update Flag is set ON if WLCCP layer 2 path updates are enabled.
  • the VLAN ID in an initial Registration Request for a MN is set to the default VLAN ID for the MN's SSED.
  • the VLAN ID in an initial Reply message for a MN contains an assigned VLAN ID, if the Assigned VLAN ID Flag is set ON.
  • the VLAN ID in a Request for a child AP is always '0'.
  • the VLAN ID in an initial Reply for a child AP is the AP native VLAN ID. (A child AP inherits its native VLAN TD from its parent AP.)
  • the VLAN ED in an update Request or Reply can be '0' or the cunent VLAN ED for the Requester node.
  • a WTLV_B?V4_ADDRESS TLV always contains the EP address ofthe Requester
  • the D? address is included in a Request to register it with the WLCCP infrastructure.
  • the B? address is included in a Reply for a MN to transfer it to the new parent AP.
  • An initial Registration Request for a MN must include a WTLV_AUTH_METHOD TLV that contains the MN authentication type.
  • An initial Registration Request for an 802.11 station (MN or child AP) must include a WTLV_SSB3 TLV, which contains the SSID from the station's 802.11 (Re)Association Request message.
  • An initial Registration Request for an 802.11 station must include a WTLV_PARENT_AP_BSSID TLV, which contains the BSSID ofthe stations parent AP.
  • An initial Registration Request for an 802.11 station, which has "reassociated" must include a WTLV_OLD_AP_BSSID TLV, which contains the BSSID from the "Old AP" field in the respective 802.11 Reassociation Request message.
  • a Registration Request for an AP must include a WTLV_AP_PORT_LIST container TLV, which contains a list of one or more WTLV_AP_PORT JNFO TLVs.
  • a Registration Reply for an 802.11 station must include a WTLV_OLD_AP_BINDINGS TLV, if the station was previously associated with an "old AP”.
  • the table below shows the format of tlie Preregistration Request/Reply Message.
  • the VLAN ID in a Preregistration Request for a MN is set to tl e default VLAN BD for the MN's SSID.
  • the VLAN ID in a Reply message for a MN contains an assigned VLAN ED, if the Assigned VLAN ID Flag is set ON.
  • the VLAN ID in a Request for a child AP is always '0'.
  • the VLAN ID in a Reply for a child AP is the AP native VLAN BD. (A child AP inherits its native VLAN ED from its parent AP.)
  • a Preregistration Request for an 802.11 station must include a WTLV_SSID TLV, which contains the SSID from the station's 802.11 (Re)Association Request message
  • a Preregistration Request for an 802.11 station, which has "reassociated” must include a WTLV_OLD_AP_BSSED TLV, which contains the BSSID from the "Old AP" field in the respective 802.11 Reassociation Request message.
  • a Preregistration Reply for an 802.11 station must include a WTLV_OLD_AP_BBNDINGS TLV, if the station was previously associated with an "old AP".
  • Path check usage is defined infra.
  • Disassociation Notification messages may be used in lieu of Path Update messages, if it is not necessary to transfer context information directly from an old AP to a new J?.
  • WLCCP AAA messages are used to encapsulate EAPOL and proprietary, e.g. Cisco, accounting messages, so that messages can be forwarded to/from the WLCCP Security SAP in the WLCCP MN or IN Authenticator. For instance, a repeater AP's or MN's EAPOL message will be WLCCP encapsulated by it's parent AP. Additionally, an AP may update the
  • AAA messages need not be encrypted as they are typically either already protected by the original protocol (e.g. EAPOL or Cisco accounting) nor do they need to be authenticated. However, it is good security practice to authenticate (MIC) authentication messages.
  • MN's EAPOL messages should include a WTLVJVIIC. If a WTLVJV ⁇ C TLV is included, the contained MIC authenticates the entire WLCCP message using the link's CTK. For instance, if the message is transmitted by an AP to the SCM, the shared CTK between the AP and SCM shall be used. Each hop in the inbound (or outbound) path must authenticate and recompute the MIC, if it is enabled.
  • AAA messages must also indicate whether the state machine has entered into a AAA message as well as when it has completed. To provision these states, the AAA message is further typed accordingly.
  • the WLCCP AAA messages serve several pu ⁇ oses: 1. Distinguish entry and exit ofthe AAA state 2. Encapsulate Cisco accounting messages sent from an AP to the AS to report accounting information.
  • the first WLCCP (request) message must define the Key Management Type to trigger session key action by the MN authenticator. If CCKM is defined, then the MN authenticator will trigger a EAPOL
  • the MN authenticator will temporarily hold the NSK to forward to the AP (but will remove the MN's entry upon a pre-registration request).
  • AAA Finish (reply) message must be issued to terminate the AAA state.
  • the AAA Finish is also used to indicate an AAA success (e.g. EAP or accounting success). If AAA Finish is successful and CCKM is defined as the Key Management, then the Finish message also includes a nonce.
  • the AAA Finish message format is as follows:
  • the Requester Node must include a Secure Context TLV within the Init Session TLV to ensure that a CTK is mutually derived between the Requester Node and its IA. i the
  • the Requester Node must provide it's nonce and CTK Sequence counter to allow the IA to derive a CTK and be assured the request is not a reply, h initial releases, the rekeys can be discarded if a replay has been detected; the sequence counter is sufficiently large that rekeys should never be exhausted.
  • the IN must re-authenticate.
  • the following 802.11 elements are used to support the operation of WLCCP.
  • IPv4_SUBNET JD #define MULTICAST_802_ADDRESS LIST #define DOTlD_PATH_COST
  • a WLCCP inter- AP SS D is contained in a standard 802.11 SSBD element.
  • the general operation ofthe architecture will now be disclosed.
  • a Request message is always forwarded from the Originator to the Responder.
  • a Reply message is always forwarded from the Responder to the Originator.
  • the Inbound and Outbound flags determine how a message is forwarded. If both the Inbound and Outbound flags are set OFF, then a message is forwarded via EP routing and/or transparent bridging to the target destination (i.e. to the "Responder" in a Request message).
  • the Inbound Flag or Outbound Flag is set ON in a message to indicate that the message is being forwarded inbound or outbound, respectively, on a branch ofthe Topology Tree. It is an error if a node receives an "inbound" message from a node that is not a descendant. It is also an enor if a node receives an "outbound" message from a node that is not an ancestor.
  • the Hopwise-Routing Flag is set ON in an inbound or outbound message to force intermediate APs to process the message, where an "intermediate AP" is any AP on the topology tree branch between the Originator and the Responder of the message.
  • a "hopwise- routed" inbound message is forwarded to the hop address of the parent node; an outbound message is forwarded to tlie "Next Hop” on the path to the target node.
  • a hopwise-routed message is processed by each node on the inbound or outbound path. It is an error if a node receives a hopwise-routed message from a Hop Source that is not a neighbor.
  • the Hopwise-Routing Flag can be used in a registration message, for example, to update Layer 2 path information in each AP on the path to a MN.
  • the Responder is always tlie SCM in a Proxy Registration message generated by an AP.
  • FIG 23 illustrates how hopwise routing is used. If Layer 2 path updating is enabled (as in the W2 implementation), then Registration messages are forwarded with Hopwise-Routing set ON. If Layer 2 path updating is not enabled (as in the Wl implementation) then Registration messages are forwarded with the Hopwise-Routing Flag set OFF.
  • Relay Flag is set ON, in a WLCCP message, then the general WLCCP header is immediately followed by a Relay Node ID field. If the Relay Node ID field is non-zero, then it contains the Node BD of any intermediate node that "relayed" the respective message. The Relay Node ID is initialized to all zeroes by both the Originator and Responder. As shown in FIG 23, AP 2304 is the relay node for a hopwise-routed message sent from AP 2306 to the SCM 2302; therefore, AP 2304 must set the Relay Flag ON and enter its Node DD in the Relay Node ID field before forwarding the message inbound to the SCM.
  • Root CM Flag is set ON in an inbound request message, then the message is always forwarded inbound to the CM at the root ofthe entire Topology Tree - the root CM. h a campus network, for example, the message is forwarded to the CCM.
  • an AP can use the Root CM Flag to forward a MN's B? address to the CCM. The AP can simply send a request message to its parent SCM that contains the MN's B? address and has the Root CM Flag set ON.
  • an SCM In many cases the original Responder of a request message must forward the message on the path to the final destination. For example, an SCM must forward an inbound Registration Request to its parent LCM if the SCM is not the "nearest common ancestor" or if the Root CM Flag is set ON. Likewise, an LCM must forward an outbound Deregistration Request to the parent SCM of the Target Node.
  • the Responder forwards such a message as follows: a) The Responder field is updated with the Node ED ofthe next-hop CM, b) The relay Responder enters its Node BD in the Relay Node ID field, c) The Originator and Message ID fields are unchanged. The relay Responder does not update the Responder field in any conesponding Reply message; therefore, the Responder field in the Reply message will contain tlie Node BD ofthe "final Responder" when it is received by the Originator.
  • the Originator of a Request message sets the Response-Req Flag ON to solicit a conesponding Reply message.
  • the Originator is always responsible for enor recovery if an expected Reply message is not received.
  • An Originator must start a "retry timer" for each outstanding Request message that requires a Reply.
  • a Request message is retransmitted, with the Retry Flag set ON and the original Message ID, if an expected Reply message is not received before the respective timer expires.
  • a retry timer is not needed in an intermediate "relay Responder", which forwards a Request message on tl e path to the final Responder.
  • An Originator or relay node can include a Reply_State TLV in a Request message, to reduce the amount of state infomiation that must be kept in memory.
  • a Reply _State TLV contains information that is necessary to process (e.g. forward) a Reply message.
  • AP message forwarding logic is generally independent ofthe network infrastructure.
  • the parent SCM is the Responder in messages generated by an AP, with one exception. [If Layer 2 path updating is enabled, then the Responder in an initial Registration Request generated by a non-root AP is the parent AP.] In a local or campus infrastructure, the SCM forwards AP messages to the root CM as required. Likewise, SCM message forwarding logic is the same in a standalone local infrastructure or a campus infrastructure. The parent LCM is always the Responder in messages generated by the SCM. In a campus network, the LCM forwards SCM messages to the CCM, as required.
  • a WLCCP node only accepts "valid" WLCCP messages transmitted on its native VLAN. All other messages are discarded. A message is invalid if it fails a Message Integrity Check or if the message type is unknown.
  • the SCM Election and Advertisement Protocol is used to elect a single active SCM for each subnet and to advertise network availability and network parameters.
  • a registered, active SCM sends periodic SCM Advertisement Reply messages, with the "SCM Active" flag set ON, to a WLCCP "all nodes" 802 group address.
  • An AP selects its "primary port” and registers with the active SCM whenever the SCM instance changes.
  • SCM election and advertisement are as follows: 1) One or more "SCM candidates" are configured with a non-zero SCM priority value, on each subnet.
  • each SCM candidate can authenticate with tlie root CM to establish a shared WLCCP multicast key.
  • the multicast key is used to optionally authenticate multicast SCM Advertisement messages. [If SCM Advertisement messages are not authenticated, then authentication is defened until an active SCM is elected.]
  • Each SCM candidate sends a Context Mgmt Request message to the CCM.
  • the CCM assigns the SCM candidate to a parent LCM or directs it to operate in standalone mode in the Context Reply message.
  • each SCM candidate initiates Path Authentication with its assigned LCM and the CCM.
  • Steps 3-5 are repeated if an active SCM becomes unattached.
  • the active SCM begins generating "active" SCM Advertisements (i.e. advertisements with the Active flag set ON) only after it has successfully registered with the root CM.
  • Root APs must register with the active SCM and propagate active SCM Advertisements.
  • SCM Advertisement messages contain an IPv4_SUBNET_ID TLV, which uniquely identifies the local subnet, and "Path Cost” and "Hop Count” fields.
  • the Path Cost is used to convey the path cost to the primary LAN for the respective subnet.
  • the Hop Count field is used for backward-compatibility with existing APs and radio firmware and contains the number of wireless hops to the primary LAN.
  • An active SCM sends SCM Advertisement Reply messages with the Path Cost and Hop Count fields set to '0'.
  • SCM advertisement messages must contain a Root CM IP Address TLV, which is used to advertise the IP address ofthe root CM in the SWAN Topology Tree.
  • the SCM is the Root CM if the SCM is operating in stand-alone mode. If the SCM is operating in infrastructure mode, then the IP address ofthe LCM or CCM that is at the root ofthe entire Topology Tree.
  • the Root CM is the default 802. IX authenticator for infrastmcture nodes.
  • SCM advertisment messages contain a Root CM field, which contains the Node BD of the Root CM.
  • An AP can determine if the Root CM changes by monitoring the Root CM field in SCM advertisements.
  • An AP or SCM candidate can send a multicast SCM-Advertisement Request to solicit an "unscheduled" SCM-Advertisement Reply message.
  • the active SCM must send a unicast unscheduled Reply if it receives a Request on its Ethernet port.
  • An "Attached" AP must send a unicast unscheduled Reply if it receives a Request on a secondary port from a child AP.
  • the unicast MAC destination address in the unscheduled Reply is taken from the Hop Address in the conesponding Request and is the same as the MAC source address in the Request.
  • An AP must NOT forward an SCM-Advertisement Request.
  • Attached AP must maintain the state information that is necessary to generate an unscheduled SCM-Advertisement Reply (i.e. the infonnation used to generate the last scheduled advertisement message).
  • An SCM Candidate or AP can set the Responder Node BD to '0' in an SCM- Advertisement Request (i.e. if it does not know the Node BD of the active SCM or parent AP).
  • the actual responder i.e. the active SCM or a parent AP
  • a non-root AP should set the Responder Node BD, in an SCM-Advertisement Request, to the Node BD of its parent AP, if it is known.
  • Initial Authentication is used to fully authenticate a node when it first enters the network.
  • a MN initially authenticates with the MN 802. IX Authenticator; an infrastructure node (AP or CM) initially authenticates with the IN 802. IX Authenticator in the root CM.
  • Initial Authentication messages are encapsulated in 802. IX EAPOL messages on an 802.11 link between a child and parent 802.11 station.
  • Initial Authentication messages are encapsulated in WLCCP AAA messages on all other links.
  • An AP or child CM uses "Path Authentication" messages to mutually authenticate and establish a CTK with each of its ancestors.
  • An AP or child CM initiates Path Authentication after it initially authenticates and whenever it path changes.
  • Fast Reauthentication is used to quickly "reauthenticate an 802.11 station (MN or child AP) when it roams to a new parent AP.
  • a parent AP uses "Preregistration” messages to fetch the necessary security context for Fast Reauthentication when an 802.11 station reassociates. Preregistration messages do NOT update the forwarding path.
  • the WLCCP Registration and Handoff Protocol is used to establish, maintain, and delete branches and path instances in the SWAN Topology Tree. Registration (and deregistration) messages are also use to transfer context information when a node roams.
  • Each authenticated child CM, AP, and MN in a SWAN network is registered with the root of the SWAN Topology Tree - the root CM.
  • each CM, AP, and MN in a sub tree is reliably registered with the CM at the root ofthe sub tree.
  • Example registration and handoff message sequences are shown in following sections.
  • the Registration and Handoff Protocol is implemented with three message types -
  • Each MN, AP, and child CM must successfully authenticate (or reauthenticate) before it is registered with the SWAN infrastmcture.
  • An inbound "initial" Registration Request is generated to initially register a node with the root CM after it has successfully (re)authenticated.
  • a Registration Request is acknowledged by a Registration Reply that contains a matching Message ID.
  • An outbound initial Registration Reply establishes a Path Instance, which is (optionally) identified by a Path BD.
  • An "update Registration Request” is used to refresh the registration state of an Attached station.
  • An update Registration Request is also used to update the context information cached in ancestor nodes.
  • a Registration message contains an Initial Flag, which is set ON in an "initial” Registration message and OFF in an “update” Registration message.
  • a Registration message has a Proxy Flag, which is set on in a "proxy” Registration message generated “in proxy” by a parent AP for a non- WLCCP MN.
  • An “initial, proxy” Registration message for example, has both the Initial Flag and the Proxy Flag set ON.
  • a Registration Request for a node, which has roamed, is forwarded inbound until it reaches the "nearest common ancestor CM".
  • the "nearest common ancestor CM” is the CM that is at the root ofthe smallest sub tree that includes the CM and both the old and new parent nodes.
  • the SCM is the nearest common ancestor when a MN roams within a single subnet.
  • An LCM is the nearest common ancestor when a MN roams between subnets in the same Local Control Domain.
  • the nearest common ancestor CM is refened to as the "common CM".
  • the common CM returns a Registration Reply outbound to acknowledge the Registration Request and to establish a new path instance for the "Requester Node".
  • the common CM (optionally) "deregisters" any old path instance, when it establishes the new path instance for the node.
  • a non-parent CM or AP must forward an "initial” or "proxy” Registration Reply to the "parent" ofthe Requester Node, identified by the Requester Node ID field. Therefore, the parent node is the Originator of any "initial” or "proxy” Registration Request that it forwards inbound for a child Requestor Node.
  • the Root CM Flag is set ON in a Registration Request to force a "full path update".
  • Registration Request is always forwarded to the root CM if the Root CM Flag is set ON.
  • the Path ID field in an "initial" Registration Request is always set to '0'.
  • the parent CM (optionally) establishes the path BD, for a path instance, by entering a path BD value into the Path ID field of an initial Registration Reply.
  • the Path ID field in an "update" Registration Request is set to the path BD for the path instance.
  • a Registration Request is always transmitted with the Response-Req Flag set ON, to solicit a Reply.
  • a Registration Request message is retransmitted if an expected matching Reply is not received, until a REGISTRATION_RETRY_MAX limit is exceeded.
  • the same Message BD is used for the original Registration Request and all retransmissions, In general, received Registration Requests are ordered by time-of-arrival.
  • Registration Delay field is, optionally, used to order received Proxy Registration Requests that are generated by a parent AP for a child node.
  • the Delay field contains the elapsed time, in hundredths of seconds, since the respective child node last transmitted an uplink frame.
  • a Registration Record in a CM must contain a timestamp field that contains the "time-of- anival" of the last Registration Request. The time-of-arrival is calculated by subtracting the Delay value from the cunent time.
  • a parent AP or SCM forwards a Registration Reply to a child AP by sending it to the port MAC address contained in the Hop Source field in the original Registration Request.
  • a parent CCM or LCM forwards a message to a child CM by sending it to the hop EP address of the child CM.
  • Inbound Deregistration Reply and Detach Request messages are optionally used to delete old path instances.
  • a Deregistration Request is generated by a "common CM" to delete any old path instance when a new path instance is established.
  • an "administrative" Deregistration Request can be generated by the Root CM to administratively disconnect a node.
  • a parent AP generates a Detach Request, when a child node is disassociated. If the child node is an AP, then the sub tree rooted at the AP is deleted. Deregistration and Detach logic is described in more detail below.
  • Each AP in a subnet, and any MNs associated with the AP, are registered with the active SCM for the subnet.
  • An AP discovers the "active SCM" via the SCM advertisement protocol, as described above.
  • Each MN is registered with the SCM for its parent AP, even if the MN belongs to a different subnet.
  • Intra-subnet registration logic is implementation-specific, hi tlie simple Wl implementation, WLCCP registration is used to establish and distribute context information between the SCM and child APs. It is NOT used to establish the Layer 2 forwarding path.
  • the L2-Path-Update Flag is set OFF and the Hopwise-Routing Flag is set OFF in
  • a Registration Reply for example, is forwarded outbound, with hopwise routing, by sending it to the MAC or B? destination address ofthe "next hop" on tl e path to the target node.
  • a Deregistration Reply or Detach Request is forwarded inbound, with hopwise routing, by sending it to the MAC or EP destination address ofthe parent node identified in the "Parent Node Record”.
  • Non- WLCCP bridges and switches transparently forward registration messages.
  • FIG 24 there is shown a block diagram illustrating a mobile node 2412 roaming from a first access point 2408 to a second access point 2410 on a campus network 2400.
  • the network 2400 comprises a CCM 2402 which is an IN 802.1X Authenticator, an LCM 2404 which is a MN 802. IX authenticator, an SCM 2406, a first access point 2408, second access point 2410, and the mobile node 2412.
  • FIGs 25a and 25b The message sequences for registering and deregistring mobile node 2412 are shown in FIGs 25a and 25b.
  • FIG 25a shows the message sequences for the mobile node 2412 as it first associates and authenticates with access point 2408
  • FIG 25b shows the message sequences as the mobile node 2412 roams to the second access point 2410.
  • the arrows indicate the direction ofthe message (source -> destination or bi-directional ⁇ ->) and the vertical bars indicate the network component.
  • the mobile node 2412 associates with the first access point 2408.
  • the steps comprise sending the assocation request 2502 from the mobile node 2412 to the first access point 2408 and the first access point 2408 sending an association response 2504.
  • the mobile node 2412 then authenticates with LCM 2404 (the MN 802. IX authenticator) and the first access point 2408.
  • LCM 2404 the MN 802. IX authenticator
  • the mobile node 2412 performs an initial authentication 2506 with the first access point 2408, an EAP authentication 2508 is then perfomied between the first access point 2408 and the SCM 2406, and a AAA request 2510 is performed between SCM 2406 and LCM 2404.
  • preregistration is required.
  • the preregistration starts by the firs access point 2408 sending an initial proxy registration request 2512 to SCM 2406.
  • SCM 2406 then forwards the initial registration request 2514 to LCM 2404
  • the CCKM preregistration reply 2418 is sent from LCM 2404 to SCM 2406, then as shown by 2516 from SCM 2406 to the first access point 2408, and the first access point 2408 sends the CCKM keying 2530 to the mobile node 2412.
  • the mobile node 2412 can communicate after initial authentication and keying is complete.
  • the first access point then sends an initial proxy registration request 2520 to the SCM 2406
  • the SCM 2406 then forwards the initial proxy registration request request 2522 to the LCM 2404 with the LCM 2404 as the responder
  • LCM 2404 forwards the initial registration request 2532 to the CCM 2402 with the CCM as the responder.
  • the CCM 2402 then sends an initial registration reply 2528 to LCM 2404.
  • LCM 2404 then forwards the initial registration reply as shown by 2526 to the SCM 2406.
  • the SCM 2406 then forwards the initial registration reply to the first access point 2408 as shown by 2524.
  • FIG 25b there is illustrated the messaging sequence when the mobile node roams from the first access point 2408 to the second access point 2410.
  • Mobile node 2412 reassociates with the second access point 2410 by sending a reassociton request 2552. access point 2410.
  • the second access point 2410 then sends a preregistratio erquest 2554 to SCM 2406 to obtain the dynamic credentials for the mobile node 2410.
  • SCM 2406 then sends a preregistration reply 2558 to the second access point 2410.
  • the second access point 2412 then sends a reassociation response 2556 to the mobile node 2412.
  • the mobile node 2412 then re-authenticates with the second access point 2410 using its dynamic credentials by fast reauthentication 2560.
  • the mobile node can communicate after reauthentication is complete.
  • the second access point 2410 then sends an initial proxy registration request 2562 to SCM 2406 for the mobile node 2412.
  • SCM 2406 then sends a deregistration request 2564 to the first access point 2408.
  • SCM 2406 then sends a initial registration reply 2566 to the second access point 2410.
  • the first access point 2408 sends a deregistration reply 2568 to SCM
  • the second access point 2410 sends a path update request 2570 to the first access point 2408.
  • FIG 27 a block diagram illustrating a repeater access point 2712 roaming from a first access point 2708 to a second access point 2710 on a campus network 2700.
  • the network 2700 comprises a CCM 2702 which is an IN 802. IX
  • FIGs 28a and 28b show the message sequences for the repeater access point 2712 as it first associates and authenticates with access point 2708
  • FIG 25b shows the message sequences as the repeater access point 2712 roams to the second access point 2710.
  • the anows indicate the direction ofthe message (source -> destination) and the vertical bars indicate the network component.
  • the repeater AP 2712 associates with the first access point 2708 (AP 2708). This process comprises AP 2712 sending an association request 2802 to AP 2708 and AP 2708 responding with an association response 2804. AP 2712 then authenticates with CCM 2702, the IN 802. IX Authenticator, and AP 2708 via initial authentication 2806 and AAA 2808.
  • AP 2712 then sends a Path-hrit request to AP 2708 with AP 2708 as the responder.
  • AP 2708 then sends the Path-hrit Request to SCM 2706 as shown by 2812 with SCM 2706 as the responder.
  • SCM 2706 forwards the Path-Init Request to LCM 2704 as shown by 2814 with LCM 2704 as the ersponder.
  • LCM then forwards the Path-Init request to CCM 2702 as shown by 2816 with CCM as the responder.
  • CCM 2702 then sends a Path-Init Reply to the LCM 2704 with AP 2708 as the originator.
  • the LCM 2704 sends th Path-hiit reply to SCM 2706 with AP 2708 as the originator as shown by 2822.
  • SCM 2706 sends the Path-Init reply to AP 2708 as shown by 2820.
  • AP 2708 sends the Path-Init reply to AP 2712 as shown by 2818.
  • AP 2712 then sends an Initial Registration Request 2826 to AP 2708 with AP 2712 as the Responder.
  • AP 2708 sends the Initial Registration Request to SCM 2706 for AP 2712 with SCM 2706 as the Responder at 2828.
  • SCM 2706 forwards the Initial Registration Request to LCM 2704 with LCM 2704 as the Responder.
  • LCM 2704 forwards the Initial Registration request to CCM 2702 with CCM 2702 as the
  • CCM 2702 sends an Initial Registration Request Reply to LCM 2704.
  • LCM 2704 then forwards the Initial Registration Request Reply to SCM 2706.
  • SCM 2706 forwards the Initial Registration Request Reply to AP2708, which then at 2834 foiwards the Initial Registration Request Reply to AP 2712.
  • FIG 28b there is shown the sequence of messages that occurs when the repeater AP (AP 2712) roams from the first access point 2708 (AP 2708) to a second access point 2710 (AP 2710).
  • the process begins at 2850 when AP 2712 sends a reassocation request to AP 2760 and indicates a "fast reauthentication" capability.
  • AP 2710 then sends a Preregistration Request to SCM 2706 to obtain the dynamic credentials for AP 2712.
  • SCM 2706 sends a Preregistration reply to AP 2710 at 2856.
  • AP 2720 then sends a reassociation response to AP 2712 at 2854.
  • AP 2712 reauthenticates with AP 2710 using its dynamic credentials.
  • AP 2712 then sends a Path-Init Request to AP 2710 at 2860 with AP 2710 as the Responder.
  • AP 2710 sends a Path-Init reuest to SCM 2706 for AP 2712 with SCM 2706 as the Responder.
  • SCM 2706 sends a Path-Init Reply to AP 2710 at 2866 with AP 2710 as the Originator.
  • AP 2710 sends a Path-Init Reply to AP 2712.
  • AP 2712 sends an Initial Registration Request to AP 2710 with AP 2710 as the Responder.
  • AP 2710 sends an Initial Registration Request to SCM 2706 for AP 2712 with SCM 2706 as the Responder.
  • SCM 2706 sends a Deregistration Request to AP 2708.
  • SCM 2706 sends an Initial Registration Reply to AP 2710.
  • AP 2710 sends an Initial Registration Reply to AP 2712.
  • AP 2708 sends a Deregistration reply to SCM 2706.
  • AP 2710 sends a Path-Update Request to AP 2708.
  • a single active SCM is elected for each subnet, as described infra.
  • APs on a subnet operate in "distributed mode" if no SCM candidates are configured for the subnet
  • the active SCM either operates in 1) Stand-alone Mode or 2) SWAN Infrastmcture Mode.
  • An SCM operates in Stand-alone mode whenever it cannot communicate with a parent LCM.
  • Infrastmcture Mode an SCM is registered with a parent LCM and forwards WLCCP messages to its parent CM.
  • SCM operation in infrastmcture mode is specified in the section entitled "W2 - SCM Operation".
  • the LCM co-located with the CCM is tl e default backup LCM for all SCMs.
  • the sub tree rooted at an SCM does NOT need to be rebuilt when an SCM transitions from Infrastmcture Mode to Stand-alone mode.
  • the SCM must function as the IEEE 802. IX authenticator for its subnet, in stand-alone mode.
  • the general SCM Data Structures and State Variables will now be described.
  • SCM_Advertisement_Timer An SCM-Advertisement Reply messages is generated by an SCM Candidate or active SCM when the timer expires.
  • the period ofthe timer is DEF_SCM_ADVERTISE_PERIOD seconds (e.g. 5 seconds).
  • SCM_Instance_Age The SCMJfr ⁇ stance_Age is initialized to '0' and is reset to '0' whenever an SCM relinquishes the active SCM status.
  • the active SCM increments the SCM_h ⁇ stance_Age value each time the SCM_Advertisement_Timer expires.
  • the SCM is the 802. IX IN and MN Authenticator IN if the SCM is operating in standalone mode, hi standalone mode, the SCM must maintain an Authenticated Node Table, which is a list of Authenticated Node Entries.
  • Each Authenticated Node Entry contains authentication state information for APs and MNs in the sub tree rooted at the SCM. The authentication state in a node entry is initialized to 'unauthenticated'. The state information contained in the table is defined in the section entitled "WLCCP Security Support".
  • Registration Tables The active SCM must maintain a Registration Table, which contains state information for each AP and MN in its sub tree.
  • An AP Registration Table contains an AP Registration Record for each AP in its subnet.
  • a MN Registration Table contains a MN Registration Record for each MN that is associated with an AP in the subnet.
  • a Registration Record is created or updated when a Registration Request is received for an AP or MN.
  • a Registration Record contains a cross reference to an Authenticated Node Entry.
  • a MN Registration Record contains a cross reference to the AP Registration Record for the MN's parent AP.
  • a Registration Record is aged and discarded if a successful Registration Request is not received for the respective node with the registration Lifetime.
  • Each SCM candidate in a campus control domain is automatically assigned to a parent LCM by the CCM using Context Request Reply messages.
  • An SCM candidate must send a Path-Init Request to its assigned parent LCM, after it has successfully authenticated with the root CM, to initiate Path Authentication.
  • the LCM always forwards the Path-Init Request to the CCM, in campus infrastmcture mode.
  • the CCM functions as a KDC to mutually authenticate the SCM Candidate and the LCM and establish a shared CTK.
  • An (optional) WLCCP "multicast CTK" is forwarded to the SCM during the Path Authentication process.
  • the SCM candidate (optionally) uses the WLCCP multicast CTK to sign SCM Advertisement Reply messages.
  • the CTK shared by an SCM Candidate and the LCM is not used, if the SCM Candidate is not elected as the active SCM. Active SCM Election.
  • An SCM election protocol is used to elect a single active SCM for each subnet, from a set of one or more SCM Candidates.
  • the Primary LAN is the wired Ethernet LAN attached to the SCM; therefore, SCM election automatically establishes the Primary LAN for each Subnet.
  • the election protocol is facilitated by SCM Advertisement messages.
  • Each SCM candidate is configured with a non-zero SCM priority value from 1 to 255.
  • a WLCCP node is not an SCM candidate if it is configured with an SCM priority value of '0'.
  • the high-order bit ofthe SCM priority value is used as a "Preferred SCM' flag and is set ON in a "prefened” SCM.
  • the Preferred SCM flag is set OFF in a "backup" SCM. Therefore, priority values from 128 to 255 are used for "prefened” SCM candidates.
  • Priority values from 1 to 127 are used for "backup" SCM candidates.
  • the SCM “priority value” is concatenated with the SCM Node ED for form an SCM “Priority BD". The effective relative SCM priority is discussed in detail below.
  • the state transition table below defines the operation ofthe SCM election protocol.
  • SCM Advertisement messages that are received on any other VLAN are ignored.
  • An "SCM Candidate” is configured with a non-zero SCM “priority value”.
  • SCM Priority BD which consists ofthe concatenated SCM priority value and the SCM Node Address. The mles for the effective relative SCM priority are as follows:
  • An SCM candidate or active SCM has a relatively "higher priority" if it is configured with a higher priority value.
  • a first SCM candidate has a relatively higher priority than a second SCM Candidate if it has an SCM "Priority BD" that is lexicographically higher.
  • a first active SCM has a relatively higher priority than a second active SCM if it has an SCM "Priority ED" that is lexicographically higher.
  • An SCM candidate has a relatively higher priority than an active SCM if it is configured with a higher priority value. If an SCM Candidate is configured with the same or a lower priority value than an active SCM, then it has a relatively lower priority than the active SCM.
  • the effective priority is structured so that an SCM Candidate will not replace an active SCM with the same priority value, even if it has a "higher" Node BD.
  • the user can explicitly select the active SCM by configuring a higher priority value.
  • An SCM candidate initially enters an SCM_CANDBDATE state to listen for SCM advertisements on its Ethernet port.
  • the SCM candidate remains in the SCM_CANDIDATE state for a "listen period" which exceeds 3 SCM advertisement intervals or until it discovers a higher-priority SCM.
  • An SCM candidate enters the SCM_ACTIVE state if it does NOT receive a higher-priority SCM advertisement message within the listen period.
  • the "elected" active SCM In infrastructure mode, the "elected" active SCM must immediately register with its parent LCM and the CCM.
  • the active SCM sets the "SCM Active" flag ON in its SCM Advertisement Reply messages after it has successfully registered or enters "stand-alone mode".
  • An SCM candidate or active SCM enters an SCM_BACKUP state if it discovers a higher priority SCM.
  • An AP or SCM candidate must send an SCM Advertisement Request message, to the WLCCP "all L s" group address, on each port when tlie port is first enabled.
  • a node in the SCM_ACTIVE or SCM_CANDBDATE state responds by sending an SCM Advertisement Reply.
  • a node in the SCM_CANDBDATE state sets the "SCM Active" flag OFF in the reply and sets the Path Cost and Hop Count fields to "infinite" values.
  • multiple active SCMs can be elected for a single subnet.
  • Advertisement Request message contains an SCM Group Election field for that pu ⁇ ose.
  • the field contains the number of SCM election groups and the group BD assigned to the respective SCM candidate (i.e. identified by the SCM Node ID).
  • the group BD must be less than the number of election groups.
  • An SCM candidate only considers SCM Advertisements from other candidates in the same group, so that an active SCM is elected for each group.
  • the elected active SCM transmits SCM Advertisement Reply messages, with the Active Flag set ON, once per Advertisement Period.
  • SCM_Advertisement Reply messages sent by the active SCM are set as follows:
  • TLVFLag - ' 1 ' (the Request must include an EPV4_SUBNET TLV and an ROOT_CM NFO TLV).
  • SCMFlags Active Flag - '1'
  • SCM Priority User-configured SCM Priority.
  • SCM Node ID SCM Node Type and Ethernet port address InstaTice Age — SCM_Instance_Age value.
  • WTLV_ROOT_CM_INFO TLV - Contains the IPv4 address ofthe root CM (which is also the 802. IX IN Authenticator).
  • An SCM must register with the root CM immediately after it is elected as the "active SCM" for its subnet. [Note that it has already completed Path Authentication.]
  • the elected active SCM sends an "initial" Registration Request its assigned parent LCM.
  • the LCM always forwards the initial Registration Request inbound to the CCM, in campus infrastructure mode.
  • the CCM returns an initial Registration Reply message to the parent LCM, which forwards the Registration Reply message to the SCM.
  • the Reply message contains the Node BD and IP address of the "root CM" in a Root CM TLV.
  • the SCM must generate periodic "update" Registration Request messages to refresh its registration bindings in the parent LCM and CCM.
  • the update Registration Request messages are always forwarded to the root CM.
  • the root CM returns an update Registration Reply message, to acknowledge the Registration Request.
  • the parent LCM resets the age of the DPR, for the SCM, to '0' when it receives a "matching" Registration Request with a
  • a parent LCM must delete the sub tree rooted at the SCM if it does not receive an update Registration Reply message for the SCM with the registration Lifetime.
  • An SCM must repeat the path authentication and initial registration processes whenever it is assigned to a different parent LCM instance.
  • a WLCCP AP either operates in 1) “Distributed Mode” or 2) SWAN “Infrastmcture Mode”.
  • the AP operational mode depends on the presence of an SCM and on an AP "Operational Mode" parameter, which can be set to one ofthe following values: a) Infrastmcture-only i b) Automatic-fallback (default) A WLCCP AP always operates in "infrastmcture mode” if it discovers a SWAN SCM.
  • An AP operates in "distributed mode” if it cannot register with the active SWAN SCM and "Operational Mode" is set to "Automatic-fallback".
  • the CISCO Datagram Delivery Protocol (DDP) is used as the inter- AP protocol, in distributed mode.
  • DDP Datagram Delivery Protocol
  • a WLCCP Context or Path-Update messages can be used, in distributed mode, to directly transfer context from an "old AP" to a "new AP", when a station roams.
  • the "old AP" MAC address can be obtained from an 802.11 Reassociation message.]
  • Each AP must function as the 802. IX authenticator, in distributed mode.
  • APs should operate in distributed mode if the network contains non-WLCCP APs.
  • An AP can NOT operate in “distributed mode” if "Operational Mode” is set to "Infrastructure-only”.
  • AP operation in infrastmcture mode is generally the same in a standalone subnet infrastmcture, a standalone local infrastructure, or a campus infrastmcture.
  • An AP that is operating in infrastructure mode is considered “Attached” if it is registered with the active SCM; otherwise, it is considered “Unattached”.
  • An AP that is operating in "distributed” mode is considered “Attached” if it has a good Ethernet link, which is configured in parent or parent/child mode (see below), or if it is associated with a parent AP; otherwise, it is considered “Unattached”.
  • An Unattached AP must prohibit 802.11 station associations, to prevent stations from associating with an AP that cannot provide access to the Primary LAN.
  • a management station can use a special "Management SSBD" to associate with an Unattached AP, when other station associations are prohibited.
  • a child 802.11 bridge or repeater AP cannot operate in infrastmcture mode unless it is associated with a parent AP that is operating in infrastmcture mode.
  • a parent AP that is operating in infrastmcture mode transmits periodic SCM Advertisement Reply messages to child APs and bridges.
  • AP_Top_Level_State - Contains tlie current top-level AP state. Top-level AP states and top-level state transitions are described in the section entitled "AP Operational Modes" .
  • Parent_SCM_Record - contains the following infonnation about the active parent SCM:
  • SCMJfodeJD The Node BD ofthe active SCM copied from the SARpM.
  • SCM_Age Incremented once per SCM Advertisement Period. Reset to 0 when an "active" SARpM is received.
  • h ⁇ frastmcture_Mode is reset to False when the SCM_Age equals MAX_SCM_AGE.
  • SCM_Instance_ Age The Instance Age ofthe SCM copied from the SARpM.
  • SCM_Subnet_Address IPv4 Address and (optional) Subnet Mask ofthe SCM copied from a WTLV PV4JSUBNET D TLV in the SARpM.
  • SCMJPriority The priority ofthe active SCM copied from the SCM Priority field in the SARpM.
  • SCM_Advertisement_Period The number of seconds between scheduled SCM advertisements copied from the Advertisement Period field in the SARpM.
  • SCM_Path_Cost The Path Cost value from the SARpM, plus the cost assigned to the AP's primary port.
  • SCM_AdvertismentXTimer (optional) - A timer that expires once per "SCM Advertisement Period" when WLCCP is enabled. The duration ofthe timer is SCM_Advertisement_Period seconds (see above). IN_lX_Authenticator - Node ED and IPv4 Address of the WLCCP hifrastrucutre
  • IX Authenticator which is always the SCM in the simple WLCCP implementation.
  • An AP must monitor SCM Advertisement Reply messages received on its primary port on the native VLAN to determine if there is an active SCM for the native VLAN.
  • An AP operates in infrastmcture mode and executes the WLCCP protocol if there is an active SCM for the AP's native VLAN.
  • An AP must update its "Parent SCM Record” each time it receives an SCM Advertisement Reply message. Infrastmcture mode is enabled when an AP first receives an SCM Advertisement with the "Active_Flag" set ON. An AP must generate SCM Advertisement Reply messages on each of its secondary ports,using one ofthe following methods: 1) An AP can simply generate SCM Advertisements on each of its secondary ports when it receives an SCM Advertisement on its primary port, or 2) an AP can start a periodic SCM_Advertisement_Timer and generate SCM Advertisements on its secondary ports each time the timer expires. The period ofthe timer is the non-zero Advertisement Period value in advertisements received on the primary port. The first method must be used if the Advertisement Period value is zero in advertisements received on the primary port.
  • a repeater AP must send a multicast SCM Advertisement Request on its primary port when it first associates with a parent AP, to solicit a unicast unscheduled SCM Advertisement Reply message.
  • SCM_Advertisement Reply message SARpM processing logic.
  • An “active” SARpM has the "Active Flag” set ON.
  • the IN 802. IX Authenticator is in the root CM when the AP is in the LR state; otherwise, the IN 802. IX Authenticator is in the AP. Preregistration and Registration of MNs is only enabled in the I,R state.
  • the AP is actively operating in Distributed mode and is accepting station associations.
  • a - h ⁇ frastmcture_Mode is Tme and the AP has successfully authenticated with the root CM.
  • SCM Advertisement Reply messages are NOT transparently forwarded by WLCCP APs. Instead, a registered AP generates "secondary" SCM Advertisement Reply messages, on each of its active secondary ports, with the same period as the SCM. [The advertisement period is contained in SCM Advertisement Reply messages.] SCM Advertisement Reply messages are NOT transmitted on the AP primary port or on AP ports that are "blocked" by the underlying STP.
  • SCM advertisements which are transmitted on AP secondary ports, contain updated "path cost” and "hop count” values.
  • Each AP port is assigned a user-configurable "path cost”.
  • Default path cost values are defined for each AP port type (e.g. Ethernet, 802.1 la, 802.1 lb).
  • the updated path cost is calculated by adding the path cost assigned to the AP's primary port to the parent AP's path cost (i.e. the path cost in SCM advertisements received on the primary port); the "hop count" is incremented by ' 1 ', if the AP's primary port is a wireless port.
  • a subnet address and updated path cost and hop count infonnation is also advertised in 802.11 Beacon and Probe Response messages, sent on AP 802.11 secondary ports, so that unassociated wireless APs and MNs can quickly discover the least-cost path to the primary LAN (i.e. without iteratively associating and authenticating with each potential parent AP).
  • An AP may register with a logical SCM that is contained in the same hardware box. hi that case, the cost assigned to the "internal primary port" should be consistent with Ethernet port cost (i.e. to prevent stations from migrating to an AP that is co-located in the same box as an SCM).
  • a non-SWAN AP may transparently forward SCM Advertisement Reply messages generated by a different SWAN node.
  • a child AP must discard any SCM Advertisement Reply messages that are not generated by its parent.
  • a child AP can use the SCM Advertisement Hop Source field to determine if its parent AP generated an SCM Advertisement message. The Hop Source address must be the same as the parent AP's Hop Address.
  • Root APs are always bound to the active SCM on the native VLAN.
  • a Root AP only receives SCM Advertisement Reply messages on its native VLAN on the primary port.
  • a non-root AP must belong to the same subnet as its parent AP; therefore, a non-root AP is always bound to the same SCM as the parent (or ancestor) root AP.
  • SWAN APs are configured with a single "WLCCP SSBD".
  • a campus-wide WLCCP SSBD is sufficient if a campus network only contains root APs or if non-root APs can dynamically bind to any subnet.
  • Subnet-specific WLCCP SSBDs can be used to bind non-root APs to a specific subnet (i.e. the subnet with root APs with a matching WLCCP SSBD).
  • a child AP can use DHCP to dynamically bind to a subnet; however, tl e native VLAN and the set of enabled VLANs in a parent and child AP must match.
  • a child 802.11 port (i.e. in a repeater AP or child 802.11 bridge) uses the WLCCP SSBD to associate with a parent AP.
  • a child AP sends Probe Requests that contains the WLCCP SSBD and potential parent APs reply with a Probe Response that also contains the WLCCP SSBD.
  • a child AP can only attach to a parent AP with a matching WLCCP SSBD.
  • An AP or child CM must authenticate its path to the root CM, after it has successfully authenticated with the 802. IX LN Authenticator, to mutually authenticate and establish a secret Context Transfer Key (CTK) with each ancestor node on its branch ofthe SWAN
  • CTK Context Transfer Key
  • Path authentication includes a Path-Init Request/Reply exchange and initial Registration Request/Reply exchange. Path Authentication and CTK updates are described in more detail in the section entitled "Infrastructure Path Authentication" .
  • An Unattached AP must send a Path-Init Request to its selected parent node, on its selected primary port, to initiate path authentication.
  • the Originator is the Unattached AP; the Requester is also the Unattached AP; and the Responder is the selected parent node (i.e. parent AP or SCM), in the Path-hiit Request and the conesponding Reply.
  • Non-security fields in a Path-Init Request sent by an Unattached AP, are set as described below. (Unspecified fields are set to '0'.)
  • the Hopwise-Routing Flag is set to ' V so that each ancestor AP on the path to the SCM processes the Request and the conesponding Reply.
  • Security TLVs included in Path-hrit messages (and initial Registration messages).
  • Originator - Node BD ofthe Unattached AP Originator - Node BD ofthe Unattached AP.
  • TLVFLag- T (The Request must include an EAP_BDENTITY_TLV.)
  • the parent node must forward a Path-Init Request from an Unattached AP or CM inbound until it reaches the root CM.
  • the parent node enters its Node BD in the Originator field and the Node BD of its parent CM in the Responder field, before forwarding the request inbound.
  • An intermediate LCM must update the Responder field with the CCM Node BD before it forwards the request inbound to the CCM.
  • the CCM returns a Path-Init Reply to the parent node (i.e. the Originator).
  • the parent node updates the Responder field with the Requester Node ID before forwarding the Reply to the Unattached AP or CM.
  • An AP must authenticate with the root CM before it can register with the SWAN infrastmcture.
  • An AP discovers the root CM via a WTLV_ROOT_CM TLV contained in SCM advertisement messages.
  • the root CM may be the local SCM, an LCM, or the CCM.
  • An Unattached AP scans for a potential parent SCM or AP on each of its ports that are configured in child or parent/child mode. [Note that an Attached AP becomes Unattached if it discovers a new instance of its parent AP or SCM.]
  • An Unattached AP or CM must send an initial Registration Request to its selected parent node, on its selected primary port, to request attachment to the network.
  • the Originator is the Unattached AP; the Requester is also the Unattached AP; and the Responder is the selected parent node (i.e. parent AP or SCM), in the initial Registration Request and the conesponding Reply.
  • Responder -Node ED ofthe selected parent node (parent AP or parent SCM).
  • TLVFLag- '1' (the Request must include a WTLV_AP_PORT_ADDRESS TLV for each AP port).
  • Relay Node ID - '0' in a registration message generated by the Originator or Responder. Otherwise, the Node ED of an intermediate "relay" node that forwarded the message.
  • VLAN ID - The native VLAN BD of both the Unattached AP and the parent node.
  • the VLAN ID value may be '0'. It is an enor if the VLAN ID value is different than the parent node's native VLAN ED.
  • the parent node must forward an initial Registration Request from an Unattached AP inbound until it reaches the root CM.
  • the parent node enters its Node BD in the Originator field and the Node ED of its parent CM in the Responder field, before forwarding the request inbound.
  • An intermediate LCM must update the Responder field with the CCM Node BD before it forwards the request inbound to the CCM.
  • the CCM returns a Registration Reply to the parent node (i.e. the Originator).
  • the parent node updates the Responder field with the Requester Node ID before forwarding the Reply to the Unattached AP or CM.
  • An AP periodically sends an "update" Registration Request message to the SCM to "refresh" its mobility bindings in each node on the path to the SCM.
  • An update Registration Request has the Initial Flag set OFF and it contains a valid Path ID.
  • An Attached AP or CM can send an "update" Registration Request directly to its parent CM, with itself as both the Originator and the Requester Node and the parent CM as the Responder. The parent CM must update the Responder field, with the Node BD of its parent CM, before forwarding the request inbound.
  • An AP (re)transmits a Registration Request either until it receives a Registration Reply with a matching message BD, or until the maximum retries are exceeded.
  • An AP is "registered” when it receives a matching Registration Reply with a "good” RegStatus.
  • the Registration Reply contains a Path ID, set by the SCM, which identifies the "path instance"
  • a Registration Request from an AP must include a WTLV_AP_PORT_LIST TLV, which contains a list of WTLV_APJPORT NFO TLVs.
  • Each PORTJNFO TLV includes the port type, port mode (parent, child, or parent/child), and 802 port address of a physical communications interface.
  • a Registration Request from an AP must include an IP Address TLV to bind its IP address to its Node BD.
  • An AP must generate an update Registration Request immediately whenever its EP address changes.
  • Preregistration messages are used to obtain context information that is required prior to registration.
  • a new parent AP optionally, sends a Preregistration Request message, to its parent SCM, to obtain dynamic credentials and "old AP bindings" for an 802.11 station (MN or child AP) when it "reassociates”.
  • MN 802.11 station
  • a Preregistration Request is NOT generated when an 802.11 station initially "associates”.
  • the parent AP generates a Preregistration Request when it receives 1) an 802.11 Reassociation Request or 2) an 802.1X EAP Identity Response message from the 802.11 station.
  • the Preregistration Request contains the child station's Node BD and its security "Identifier".
  • a Preregistration Request is forwarded inbound to the nearest common ancestor CM ofthe old AP and new AP (with some restrictions noted below). If the "common CM" has the mobility bindings and security context for the child station, then the old AP bindings and dynamic credentials are returned in a Preregistration Reply message. Otherwise, a Preregistration Reply is returned with a "not found” status and the station must fully authenticate.
  • a Preregistration Request for a MN is never forwarded beyond the nearest common
  • the LCM since the LCM is the MN Authenticator. An AP cannot roam across subnet boundaries; therefore, the nearest common ancestor CM for a child AP should always be the local SCM.
  • a Preregistration Reply does NOT establish a "bound" Path Instance.
  • An 802.11 Reassociation Response message is, optionally, generated when the parent AP receives the Reply.
  • a new parent AP does not need to send a Preregistration Request to obtain an 802.11 station's's dynamic credentials if fast reauthentication with a Network Session Key is not supported or if the station's dynamic credentials are "predictively" forwarded to the new parent AP. In that case, tl e station's "old AP bindings" are returned in a Registration Reply message. Specific Preregistration handshaking is dependent on the 802.11 (re)authentication method.
  • the fields in a Proxy Preregistration Request message, generated by a parent AP for a child 802.11 MN are set as follows:
  • Originator - Node BD ofthe Parent AP Originator - Node BD ofthe Parent AP.
  • TLVFLag - ' 1 ' (The Request must include an EAP_BDENTITY_TLV and an SSBD_TLV).
  • EAPJDENTITY TLV- The Preregistration Request for a MN or child AP must contain a WTLV_EAP_BDENTLTY TLV that contains the node's identifier from an optional 802.11 Reassociation element or from tlie EAP Identity Response message.
  • SSIDXTLV- The SSBD ofthe MN taken from the MN's (Re)Association Request message.
  • a child AP can, optionally, include aNode_BD element in its (Re)Asssociation
  • a Preregistration Request should include a WTLVJPORT_ADDRESS_TLV, which contains the MAC port address ofthe child AP.
  • a parent AP generates "proxy" Registration Request messages for associated MNs.
  • the Originator, Responder, and Requester fields are always set as follows:
  • Originator Node BD ofthe Parent AP.
  • a parent AP must generate a Proxy Registration Request for a MN after it successfully authenticates or reauthenticates (as described below).
  • Proxy MN Registration logic is specific to the implementation and is described in more detail below in the sections entitled "Wl Proxy MN Registration” and "W2 Proxy MN Registration”.
  • SWAN Authentication and Privacy is achieved by enforcing SWAN infrastmcture nodes to mutually authenticate with both the root CM (CCM) as well as the IN nodes it will communicate with. Protection of WLCCP messages is achieved by the CCM generating and distributing CTKs upon successful pre-registration of ESfs.
  • CCM root CM
  • Initial authentication is based on the IEEE 802. IX protocol. Each "secure MN", AP, and CM must initially “mutually authenticate” with an 802. IX authenticator, via an external authentication server (e.g. a RADIUS server). Infrastmcture nodes (APs, SCMs, and LCMs) mutually authenticate with an "EM Authenticator”. "Secure MNs” mutually authenticate with a "MN Authenticator”. While MNs can select from any supported 802. IX EAP authentication types, for initial releases, BM nodes shall authenticate using LEAP. i a campus network, the SWAN CCM contains the EM Authenticator and LCMs contain a MN Autlienticator. hi a stand-alone local domain, both the EM Authenticator and the MN Authenticator are contained in the LCM. hi a stand-alone subnet domain, both the EM Authenticator and the MN Authenticator are contained in the SCM.
  • AP
  • the node authenticator will cache the credentials upon successful 802. IX EAP authentication.
  • the EM Authenticator will cache:
  • the MN Authenticator will cache:
  • each registration entry is populated at either 802. IX EAP Autlientication success or during a pre-registration.
  • a successful authentication will result in the creation of a registration entry with the proper BDs, NSK and session timeout values defined.
  • the valid BSSBD, SSBD and VLAN BD will also be defined at authentication based on the EAP identity.
  • IX EAP authentication messages are WLCCP encapsulated by the node's parent.
  • An infrastmcture node communicates directly via a wired link to the BM Authenticator during authentication. Once the EM parent has received the EAPOL authentication message, it will encapsulate it using a WLCCP_AAA message.
  • WLCCP_AAA messages can be optionally authenticated. As described in the section entitled "EAP-Authentication Request/Reply Message", WLCCP_AAA messages can have aJVIIC TLV appended. The MIC applies to the entire WLCCP message including the header:
  • CTK the key shared between the immediate sender and immediate reciever
  • WLCCP replies, or outbound messages allow the opportunity to specify a status.
  • status values will apply during a WLCCP_AAA:
  • Each "secure" MN must mutually authenticate with a MN 802. IX Authenticator via an external security server, hi infrastmcture mode, the MN authenticator is in an LCM. In SCM stand-alone mode, the MN authenticator is in the SCM. A MN does not require knowledge of the infrastmcture behind the AP. Thus, from the
  • MN authentication is done as specified by the 802.11 (SSN and TGi) protocols as well as the use of CCKM.
  • SSN and TGi 802.11 protocols
  • CCKM CCKM
  • the MN must employ 802.1X EAP Authentication to reap tl e benefits of LEAP, SSN or TGi's security advantages as well as SWAN manageability.
  • the MN Authenticator is detached from the parent AP.
  • EAPOL messages are WLCCP encapsulated by the parent AP, in EAP- Authentication Request messages, and forwarded to the MN Authenticator.
  • the MN Authenticator must also properly forward the required keys to the AP in a Pre-registration Request/Reply exchange.
  • the following table describes what the MN Authenticator must forward based on negotiated key management type:
  • the pairwise transient keys (PTKs) used to protect communications between the MN and AP are generated by the MN and AP in all key management schemes,
  • the AS must also accommodate the session timeout setting based on key management approaches.
  • the session timeout remains a function ofthe 802.11 negotiated cipher suite.
  • the session timeout is a function of the mutually derived key of each EAP authentication type.
  • the MN Authenticator After a CCKM MN has successfully authenticated, the MN Authenticator must trigger a key initialization to establish the Key Request Key (KRK) and Base Transient Key (BTK) before the MN and associated AP can establish PTKs.
  • KRK Key Request Key
  • BTK Base Transient Key
  • the MN Authenticator To trigger KRK and BTK derivation, the MN Authenticator must generate a 16-byte nonce.
  • An EAPOL Key message ofthe format described in the cunent TGi Draft [6] is generated to send the nonce to the MN and thus initiate the 4-way handshake used to establish KRK and BTK.
  • the EAPOL Key message is encapsulated in a WLCCP_AAA message and delivered to the MN. The delivery is through the AP, thus the AP will unencapsulate the WLCCP message and forward the EAPOL Key message to the MN.
  • the handshake proceeds as described in the Fast Handoff using Cisco's Central Key Management Protocol Specification.
  • the MN Authenticator After a CCKM MN has successfully authenticated, the MN Authenticator must trigger a key initialization to establish the Key Request Key (KRK) and Base Transient Key (BTK) before the MN and associated AP can establish PTKs.
  • KRK Key Request Key
  • BTK Base Transient Key
  • the MN Autlienticator To trigger KRK and BTK derivation, the MN Autlienticator must generate a 16-byte nonce.
  • An EAPOL Key message ofthe format described in the cunent TGi Draft [6] is generated to send the nonce to the MN and thus initiate the 4-way handshake used to establish KRK and BTK.
  • the EAPOL Key message is encapsulated in a WLCCP_AAA message and delivered to tl e MN. The delivery is through the AP, thus the AP will unencapsulate the WLCCP message and forward the EAPOL Key message to the MN.
  • the handshake proceeds as described in the Fast Handoff using Cisco's Central Key Management Protocol Specification .
  • An infrastmcture node must first authenticate with the EM Authenticator using 802. IX EAP Authentication to establish a secret network session key (NSK).
  • NSK secret network session key
  • LEAP will be the authentication type. Since LEAP is known to be susceptible to dictionary attacks, as well as good security practice, a CTK must also be mutually derived to protect data exchanged between the BM and EM Authenticator.
  • An authenticating "supplicant" BM exchanges EAPOL authentication messages with its parent AP or CM.
  • the supplicant's parent AP or CM relays the EAPOL authentication messages between the supplicant and the EM Authenticator in the root CM
  • the EAPOL authentication messages are encapsulated in WLCCP AAA Message Request and Reply messages, with one exception.
  • a child AP must exchange raw EAPOL messages with its parent AP on an 802.11 link.
  • the EM Authenticator contains a RADIUS client, which converts EAP__Authentication Request messages to RADIUS request messages, and converts RADIUS response messages to AAA Message Replies.
  • the BM Authenticator determines if the autlientication process has failed based on tlie RADIUS messages received.
  • the BM Authenticator indicates authentication failure by returning a non-zero Status value in a WLCCP_AAA Reply.
  • a secret "session key”, NSK, is established during initial authentication.
  • the NSK is then used by the BM and LA along with exchanged key material to mutually derive the CTK.
  • the CTK protecting TLVs and messages between the EM and IA are the only CTKs that require mutual derivation, all other links' CTKs are derived through a strong pseudorandom function by the IA and delivered to the h s.
  • An SCM or LCM determines that it must initially authenticate with the BM Authenticator in the CCM if it is configured with the B? address of tlie CCM.
  • SCM Advertisement Reply messages contain an ROOT_CM_TNFO TLV, which enables APs to automatically discover the Root CM and the EM Authenticator. An AP must initially authenticate with the BM Authenticator identified by the EP address contained in the TLV.
  • a Registration Reply message sent to an AP can include a MN_1X_AUTHEN TLV, which identifies the current MN authenticator.
  • the SCM can advertise a new MN Authenticator in a MN_1X_AUTHEN TLV contained in SCM Advertisement Reply messages.
  • An BM must periodically repeat the initial authentication process to maintain a "fresh" session key (e.g. NSK); the refreshing of NSKs is determined by the session timeout defined by the authentication server (AS).
  • a "fresh" session key e.g. NSK
  • AS authentication server
  • the SCM When in standalone mode, the SCM acts as both the MN and BM Authenticator.
  • a path initialization message with only a single Secure Context TLV is required as it only requires the direct CTK with the BM Authenticator (e.g. the SCM). Since this is the only present link the Path Intialization message only requires a 3 -way handshake: request, reply and confirm.
  • the AP shall use a request/reply handshake for Path Initialization and confirm the key establishment through tlie use ofthe Authenticator TLV in the Registration request/reply exchange.
  • FIG 29 gives an example of a root AP authentication. While the example demonstrates the root AP authentication and CTK establishment, the same steps are required for all other infrastructure nodes, e.g. LCM and SCM. After an infrastmcture node has initially authenticated, it must mutually authenticate and establish a separate secret a "Context Transfer Key" (CTK) with each of its ancestor nodes including the IA.
  • CTK Context Transfer Key
  • a Path-Init message is used to establish CTKs between the supplicant BM and its ancestors. Each ancestor node must provide a 16-byte nonce to allow for the distribution of fresh CTKs.
  • the IA serves as a trusted key distribution center, KDC, for that pu ⁇ ose.
  • the CTKs are used to generate MICs and encrypt sensitive context information in messages that are forwarded on branches ofthe Topology Tree.
  • CTKs are 256-bit values whose lower 128 bits are used to authenticate messages and TLV and whose upper 128 bits are used to encrypt messages and TLVs.
  • the supplicant BM For the CTK used between the EM and the IA, the supplicant BM must provide a 16-byte nonce in the Path-Init request message so that the IA can derive the CTK.
  • the IA provides its 16-byte nonce in the Path-Init reply message so that the BM can derive the CTK.
  • a final Path- hiit confinn message is needed to allow the EM to confirm proper receipt of key material and liveness of the CTK. If a full path authentication is requested by the use of a WTLV_BMIT_SESSION TLV, a fourth message is required to establish liveness ofthe CTK distributed in the Path-Init request/reply exchange.
  • An unregistered and unauthenticated IN "supplicant” initiates Path Authentication by sending a Path-Init Request message and embeds a WTLV_BMIT_SESSION to its selected parent node.
  • a Secure Context TLV that includes the EM's 16-byte nonce directed to the IA (e.g. the DST-flD is the IA in the Secure Context TLV).
  • the parent node forwards the Path-hiit Request inbound to the root CM, which contains the IA.
  • Each node on the path to the root CM, including the parent node inserts a Secure Context TLV into the request message's hiit Session TLV.
  • the BM Authenticator in the root CM determines the supplicant's list of ancestors from the list of WTLV_ ⁇ M_SECURE_CONTEXT_REQ TLVS when it receives the Path-Init Request.
  • the IA will mutually derive the CTK to protect the link between the requesting BM and the IA. Additionally, the IA will generate CTKs for each ofthe supplicant's ancestors. The IA must first derive the CTK protecting the IN-IA link so that it can generate tl e Transient Key TLVs to properly deliver the CTKs to the requesting EM. For all ofthe ancestors, the CTKs are embedded in the conesponding (and now encrypted) Secure Context TLVs.
  • the nonce generated by the LA is included in the TLV and a new MIC is computed using the newly established CTK I N- IA -
  • This WTLVJV1IC within the Secure Context TLV serves as the liveness authenticator to the requesting BM.
  • tlie set of CTK's are explicitly defined in FIG 30.
  • the AP path authentication are as follows:
  • NSK is shared between the AP and the CCM
  • CTKl CTK2 and CTK3 are fresh and valid. This is a requirement as CTKl is used to deliver and authenticate delivery of CTK5 to the LCM. While CTK2 is used to deliver CTK6 to the SCM but is sent via the LCM. The LCM in rum protects the WTLV_EM_SECURE_CONTEXT_REPLY using CTK3.
  • the WTLV_TRANSB3NT_KEY's used are described in shorthand as:
  • TKE1 WTLV_TRANSffiNT_KEY(CTK4, KSC AP - LCM II LCM-ED
  • TKE's are embedded in the encrypted Secure Context TLVs whose shorthand is:
  • WSC0 WTLV_ ⁇ M_SECURE_CONTEXT_REQ( ⁇ no encryption/MIO, IA-ED
  • WSC1 WTLV_EM_SECURE_CONTEXT_REQ(CTK2, SCM-BD
  • WSC2 WTLV_ BM_SECURE_CONTEXT_REQ(CTKl, LCM-ED
  • WSC4 WTLV_ EM_SECURE_CONTEXT_REPLY(CTK2, SCM-BD
  • WSC5 WTLV_ DM_SECURE_CONTEXT_REPLY( ⁇ no encryption ⁇ AP-BD
  • WAUTHl WTLV_AUTHENTICATOR(CTK6, SCAP-SCM II SCM-BD
  • WAUTH2 WTLV_AUTHENTICATOR(CTK5)
  • WAUTH3 WTLV_AUTHENTICATOR(CTK4, KSCAP-CCM II CCM-BD
  • WAUTH4 WTLV_AUTHENTICATOR(CTK6,
  • WAUTH5 WTLV_AUTHENTICATOR(CTK5)
  • the WTLV JNLT_SESSION (WIS) TLV exchanges during path authentication serves as the means to authenticate and establish the path CTKs between a requesting infrastmcture node and it's ancestors.
  • WIS WTLV JNLT_SESSION
  • Each CTK delivered to the supplicant is encoded in a WTLV_TRANSIENT_KEYT ⁇ N.
  • the CTK is directly delivered to the supplicant's ancestor in the
  • WTLV_SECURE_CONTEXTJREPLY TLV The list of TLVs is then entered into the Path- hiit Reply message, which is sent to the supplicant's parent node. The parent node relays the Reply to the supplicant. Each node on the outbound path ofthe Path-hiit Reply decrypts the CTK that it shares with the supplicant when it receives its respective WTLV_SECURE_CONTEXT_REPLY TLV. As shown in FIG 32, once the supplicant receives the Path-hiit Reply message, it must send an "initial" Registration Request message to the root CM, via its parent node, as described above. The supplicant must enter a
  • WTLV_AUTHENTICATOR TLV into the request message for each of its ancestor nodes.
  • Each ancestor node "authenticates" tl e supplicant when it receives its WTLV_AUTHENTICATOR TLV; therefore, the supplicant is fully authenticated before a Registration Reply is generated.
  • Each ancestor node must update and re-encrypt the WTLV_AUTHENTICATOR TLV before forwarding the Registration Request.
  • the supplicant mutually authenticates each of its ancestor nodes when it receives the updated list of WTLV_AUTHENTICATOR TLVs in the Registration Reply.
  • CTKs can be similarly refreshed as shown in FIG 33, with the only difference being that no registration is needed and thus, rather than using a Registration message type, it extends the Path-hiit message to use subtypes Confirm and ACK.
  • CTKs must be refreshed based on the entropy defined by the cipher suites used to provide privacy and authenticity.
  • RC4 and HMAC-MD5 for respectively encrypting and authenticating all messages or TLVs.
  • future releases may support AES.
  • CTKs must be refreshed when the message sequence counter has been exhausted or at a frequency of no more than a couple times a day (a 6hr. interval will be reasonable). However, if a node is experiencing frequent MIC and or decryption failures it should silently discard these messages.
  • the BM can decide whether to trigger a CTK refresh or a full (re)authentication.
  • CTK refreshes can optionally be refreshed for an entire branch, using WTLV_EMIT_SESSION, or a single CTK can be refreshed using a Secure Context request/reply exchange. While the CTK used between the infrastmcture node and the IA is also established and refreshed in WTLV EMIT SESSION or WTLV_SECURE_CONTEXT_REQ and WTLV_SECURE_CONTEXT_REPLY, its key can not be directly delivered by the IA, but rather key material (e.g. nonces) are exchanged to mutually derive a CTK. Thus the semantics ofthe
  • WTLV_SECURE_CONTEXT_ ⁇ REQ/REPLY ⁇ changes on whether the CTK is being delivered versus derived.
  • the supplicant BM To rekey or establish a single CTK, the supplicant BM must request the IA for a fresh key.
  • a 2-phase exchange is required, hi the first phase, a WTLV_SECURE_CONTEXT TLV is used to establish the CTK.
  • a WTLV_AUTHENTICATOR TLV is used to confirm liveness ofthe CTK.
  • the first phase is done during a Path-Init Request/Reply exchange while the second phase is completed during initial registration through the use of WTLV_AUTHENTICATORs.
  • the second phase is required to ensure CTK liveness between the link nodes.
  • an example of how a CTK used to protect the link between the AP and SCM employs the CCM for key delivery and direct path authentication from AP to SCM to confirm liveness ofthe CTK.
  • Dynamic security credentials for a MN are established in the initial MN authentication process, described above. These credentials include: NSK, session timeout, VLAN BD, SSBD, KRK, BTK and RN.
  • a MN's cached configuration information and dynamic credentials are automatically transfened to the new parent AP when a MN roams.
  • the cached configuration information and dynamic credentials are also forwarded to any new SCM on the new path so that future roaming is localized (i.e. so that the LCM is not accessed as the MN roams within the subnet).
  • the dynamic credentials are forwarded to the SCM during SCM registration updates.
  • a MN must be authorized to use its SSBD.
  • the 802. IX authentication server returns a list of allowed SSBDs for a MN, when the MN authenticates.
  • the list of SSBDs (and any other static configuration information) is cached in each CM on the path to the MN.
  • a MN's SSBD is included in its Pre-registration and Registration Requests.
  • the nearest common ancestor CM verifies that a MN is authorized to use its SSBD each time that it receives a Preregistration or Registration Request for the MN.
  • the roaming node affects an authenticated key refresh request to the new AP.
  • the new AP subsequently requests security credentials to the MN Authenticator via a pre-registration request.
  • the MN Authenticator must validate the security credentials provided by the MN (forwarded by the new AP to the MN Authenticator).
  • the MN Authenticator will forward the security credentials to the new AP.
  • the MN Authenticator will only provide a status code to indicate the failure point and allow the AP to decide whether to allow the MN to reestablish credentials by imposing a full authentication or to fully disassociate the MN.
  • -MN Security Context Forwarding h a full topology, the LCM acts as the MN Authenticator. The location ofthe MN
  • Authenticator in a full topology can present longer latencies and thus it is desirable to forward the MN's security credentials down to the SCM.
  • the forwarding ofthe credentials is achieved during Registration request/reply. This allows the MN's infrastmcture ancestors, mainly the SCM, to cache the MN's security credentials and facilitate roaming.
  • the credentials are forwarded by request. That is, during a MN Registration Request, each ancestor (excluding the AP) can insert a WTLV_SECURE_CONTEXT_REQ requesting that the MN credentials be forwarded, a MIC must be included in the Secure Context TLV for the MN Authenticator to validate.
  • the MN Authenticator will then embed a WTLV_MN_SEC_CONTEXT_REPLY TLV that includes all ofthe cached credentials encrypted in the TLV.
  • the Secure Context TLV must be MIC'ed on a reply as well.
  • a full depiction of an MN authentication and registration undea SWAM topology is shown in FIG 34.
  • the WLCCP_AAA message is the only explicit message type defined for node authentication. EAPOL messages are protected from man in the middle attacks as they are routed to the node's authenticator by means of a MIC in the WLCCP message encapsulation. TLVs can be protected by using a modified RC4 algorithm to provide privacy and HMAC-MD5 to provide message authenticity.
  • TLVs are encrypted using the standard RC4 algorithm but discarding the first 256 bytes ofthe RC4 stream to thwart the FMS attack.
  • a MIC TLV is included in WLCCP.
  • the CTK is thus a 256bit value comprised of two keys, the high order 128 bits is used as the HMAC-MD5 key while the low order 128 bits is used as the RC4 key.
  • a Message Integrity Check (MIC) TLV is used to authenticate WLCCP messages.
  • a source node can, optionally, set the MIC Flag ON and enter a WTLVJVIIC TLV in a WLCCP message to "authenticate" the message to the destination.
  • the TLV contains a MIC that is calculated with the high order 128bits ofthe Context Transfer Key (CTK) shared by the source and destination. If a Request message is authenticated, then the corresponding Reply message must also be authenticated.
  • CTK Context Transfer Key
  • Each, source and destination node maintains a message sequence counter, MSC, initialized to 0 when a CTK is initialized or refreshed.
  • MSC serves as a replay counter as well as the RC4 initialization vector. If the current MSC is less than or equal to the previous MSC value, then the message is a replay and must be discarded.
  • the MSC value is concatenated with the low order 128bits ofthe CTK to generate the RC4 key. In little endian order:
  • RC4-key MSC
  • the MSC values shall be even on inbound paths and odd on outbound paths.
  • the MSC should also be incremented every time a TLV or message is encrypted or authenticated. Messages that are forwarded on branches of the SWAN Topology Tree are authenticated with CTKs that are established during the preregistration/registration process. Messages that are forwarded "laterally" are authenticated with dynamically-established lateral CTKs. Lateral message authentication is discussed in the next section.
  • the Relay Flag is set OFF in a message
  • the MIC is calculated using the CTK shared by the Originator and the Responder.
  • An intermediate AP may "relay" a message that is forwarded with "Hopwise Routing”. If the Relay Flag is set ON in a message, then the MIC is calculated using the CTK shared by the immediate sender and receiver.
  • the mles for determining the shared CTK for a hopwise-routed message are as follows:
  • the immediate sender AP of an inbound message uses the CTK it shares with its parent node.
  • the immediate sender (AP or SCM) of an outbound message uses the CTK it shares with the next hop child node.
  • the immediate receiver uses the CTK it shares with the immediate sender. If the Relay Flag is set OFF, then the immediate sender is the Originator in a Request message and the Responder in a Reply message. If a the Relay Flag is set ON, then the immediate sender is the "relay node" identified by the required Relay Node ID field, A CTK is also used to encrypt any TLVs that contain sensitive data (e.g. a session key for a descendant node). The mles for determining the CTK used to encrypt sensitive TLVs are the same as the mle for determining the CTK used for message authentication. Note that each relay AP must decrypt and re-encrypt TLVs in messages that are forwarded with Hopwise- Routing. TLVs are defined to allow for node authentication, context management, and CTK and
  • PTK management i.e. path authentication and pre-registration.
  • TLV Group BDs There are five basic operations to establish, cache and manage security credentials; these are defined as TLV Group BDs in the following table:
  • WTLV_TRANSIENT_KEY is an embedded TLV used to deliver link keys within a WTLV_INIT_SESSION or WTLV_SECURE_CONTEXT_REPLY.
  • EAP Identity can be of arbitrary length a TLV is define as follows:
  • WTLVJVflC Another TLV used to secure WLCCP messages or TLVs is the WTLVJVflC. It is defined as:
  • the WTLVJVIIC allows expansion ofthe MIC for some future use. Initially, the MIC length is preset to 8 bytes to define the MIC to be of length 8 bytes.
  • the message sequence counter is used to define the number of WTLVJVIICs generated using the conesponding CTK. This TLV will be appended to any WLCCP message whose Flags value includes the MIC Flag (0x0100). Messages that require a WTLVJVIIC must define the fields covered by the HMAC-MD5 function.
  • WTLVJVIIC is used to authenticate WLCCP_AAA messages for MN authentications only.
  • WTLV JTRANSffiNT_KEYs must include a MIC to authenticate delivery of a CTK or when forwarding MN's keys.
  • WTLV_MN_SECURE_CONTEXT_REQ, WTLV_EM_SECURE_CONTEXT_REQ, WTLVJN_SECURE_CONTEXT_REPLY and WTLV_MN_SECURE_CONTEXT_REPLY must be autl enticated as they are augmented and propagated hop to hop.
  • WTLV_BMIT_SESSION must be authenticated as they are augmented and propagated from the supplicant node to its authenticator.
  • WTLV_AUTHENTICATOR must include a MIC to ensure session liveness between a supplicant node and ancestor
  • CTKs and BTKs are required to establish CTKs and BTKs, respectively.
  • CTKs must be established between the node and it's ancestors up to the root CM.
  • the WTLV_INIT_SESSION TLV triggers the state for establishing fresh CTKs.
  • sequence counters are initialized to zero and CTKs are established for all links between the requesting BM nodes and the BM Authenticator.
  • PTKs are required for an MN and its cunently associated AP to consume. The key established between the MN and IA must be forwarded to the AP before PTKs can be mutually derived and consumed between MN and AP.
  • a BTK must first be established for a CCKM MN.
  • the WTLV NIT_SESSION triggers tlie state for establishing fresh CTKs and BTKs.
  • sequence counters are initialized to zero and CTKs are established for all links between the requesting BM nodes and the EM Authenticator. Key sequence counters are only set to zero after a successful authentication, they are incremented every time a key is refreshed.
  • a BTK and first PTK are established for securing data packets between the AP and MN; this of course, implies that for SCM standalone mode, the AP must have secured a CTK between itself and the SCM. That is, APs must first authenticate and register into the SWAN topology before it can pre-register or register MNs.
  • the WTLV_BMIT_SESSION TLV is defined as follows:
  • each TLV is preceded by an offset to indicate the next TLV length or the offset to the next TLV.
  • An offset of 0 (zero) indicates the end, e.g. no more TLVs.
  • the MN Authenticator When MNs successfully authenticate into the network, the MN Authenticator will cache it's NSK and other relevant security credentials. If CCKM is the negotiated
  • the MN Authenticator must respond with an
  • the WTLV_BMIT_SESSION includes a Secure Context TLV that includes the AP's identity as the Destination-ID and the negotiated
  • the SSBD is also included in the Secure
  • the Secure Context's Nonce must be provided by the MN as it serves as the keying material used to derive the KRK and BTK.
  • the WTLV_INIT_SESSION generated by tl e AP (on behalf of the MN) is defined as:
  • the MN has negotiated CCKM then it must have also provided a nonce, which is embedded in the WTLV_MN_SECURE_CONTEXT_REQ.
  • the AP should trigger an error if the MN does not provide a nonce. If the MN has negotiated SSN or legacy systems, the AP must obtain only the NSK.
  • the MN Authenticator must derive and deliver the BTK to the AP and cache the KRK.
  • the MN Authenticator must deliver the key (NSK or BTK) to the AP, embedded in the MN_SECURE_CONTEXTJILV. Since it is an MN requesting such a key, tlie MN Authenticator will omit the WTLVJTRANSEBNTJf EY normally used to deliver the NSK or BTK to the MN. This step is redundant and unnecessary as the MN has already mutually derived this key as well as it need not be aware what is behind the AP.
  • Path authentication and initialization of CTKs for BM nodes presumes that the BM's ancestors have successfully registered into the SWAN infrastructure. Path authentication is initiated with a Path-hiit request that includes a WTLV_EMIT_SESSION TLV ofthe form:
  • the Supplicant's ancestors will in turn request a key to protect the link between it and the requesting EM by embedding their WTLV_SECURE_CONTEXT_REQ:
  • FIG 33 is an example of how a node initializes the CTKs between itself and it's ancestry path up to the IA.
  • the Path Length field must incremented by one by each ancestor as the request is forwarded to the IA.
  • the IA must return this value and confirm that there are Path Length WTLV_SECURE_CONTEXT_REQ TLVs in the WTLV_BMIT_SESSION. If too many or too few are provided then it must discard this request.
  • Each ancestor must identify itself and provide it's conesponding WTLV_SECURE_CONTEXT_REQ.
  • the IA in rum will convert each requesting Secure Context TLV into a WTLV_SECURE_CONTEXT_REPLY to deliver the appropriate CTKs. Since keys are delivered within WTLV_SECURE_CONTEXT_REPLYs, the responding Secure Context TLVs must be both encrypted and MIC'ed.
  • TLV TLV
  • the TLV implies the source BM identifier from the overall WLCCP message to avoid too much redundancy.
  • the encryption uses RC4 to encrypt the key only:
  • EsUP_DST Encrypted Key RC4(MSC
  • CTKiN -1D _su pp ii ca n t i D is encrypted using the key established between the EM Autlienticator and the destination BM.
  • the delivered key, CTK 1N- i D _s upp ii can tiD is used to protect data between the destination BM and the Supplicant.
  • the NSK is used to deliver its CTK.
  • the key delivery for protecting messages between the AP and MN is the same as that defined above, with the difference being that the BTK is the delivered key along with the Rekey sequence number to the AP only:
  • EAP Encrypted Key RC4(MSC
  • the authentication of tl e TLV includes fields excluded in the WTLVJ ⁇ RANSEENT_KEY but embedded in the overall WLCCP message.
  • the MIC for an BM node response is computed as follows:
  • KEY-MIC SU p_ D s ⁇ HMAC-MD5(CTK A uthenticator_iN-iD, KSC, SNonce, ANoncej,
  • the responding MIC for an AP request for a BTK is computed as follows:
  • KEY-MICAP HMAC-MD5(CTK A uthenticator_AP, KSC, SNonce, ANonc , Supplicant-BD, Destination-EMJDD, E AP )
  • a counter, KSC, for all keys delivered to the Destination EM must be kept and used between the destination EM and the BM Authenticator to prevent replays. Similarly, if the keys are delivered to tlie AP for protecting AP to MN communications, it must also retain a count for such keys in its KSC.
  • Secure Context TLVs are used to establish link keys between the Supplicant node and its ancestor. Since requesting Secure Context TLVs do not include keys but other pertinent information to cany the requests, the Secure Context TLVs are split into a requesting and a responding Secure Context TLV. Further, since MNs define a key management type and are proxied by the AP, the Secure Context TLV for requesting MN security credentials are distinguished from BM secure contexts.
  • the requesting MN Secure Context TLV is defined as:
  • Optional TLVs are also provided for when CCKM is the negotiated key management and thus further work is required by the MN authenticator to validate the EAPOL Key message on association or the Reassociation CCKM element.
  • the requesting BM Secure Context TLV is defined as:
  • the responding MN Secure Context TLV will ultimately deliver Key(s) to the Supplicant node.
  • SBD Supplicant node
  • optional fields are included. The succeeding subsections further describe the required fields based on the requests.
  • WLCCP pre-registration is used to request security credentials.
  • the parent AP sends a Pre-registration Request message to the SCM to request security credentials. [The request may be forwarded inbound, as required, if the security credentials are not cached in the SCM.]
  • the Pre-registration request includes a
  • WTLVJSECURE_CONTEXT REQ TLV The parent AP must be authenticated and have an established CTK between itself and the SCM (i.e. via Path Authentication).
  • the WTLV_SECURE_CONTEXT_REPLY contained in a Pre-registration Reply, is used to deliver keys and thus the TLV must be encrypted as follows:
  • MIC HMAC-MD5(CTKj N-IA , DST-BD
  • a responding EM Secure Context TLV is defined as follows:
  • the WTLV_CCKM_ASSOCIATE element is used to forward tl e second EAPOL Key message from the MN to the MN Authenticator as it is MlC'ed with the KRK, which only the MN Authenticator holds.
  • the EAPOL Key message must be validated by the MN Authenticator.
  • a TLV is defined to propage the EAPOL Key message for MIC validation as follows:
  • the WTLV_CCKM_REASSOCIATE element is used to forward the timestamp and MIC portions ofthe CCKM information element provided by the MN in the reassociation message.
  • the MN includes a CCKM element in the Reassociation message ofthe format:
  • the AP places the RN value as the KSC field in the MN Secure Context Request TLV. h addition, it propagates this element in the CCKM Reassociate TLV as follows:
  • WTLV_SECURE_CONTEXT requests a new CTK for the link specified between the Supplicant and BM.
  • the request format is defined as follows:
  • the BM Autlienticator will deliver a CTK for protection of WLCCP messages between the Supplicant and BM-BD.
  • the delivery mechanism to the Supplicant is througli the use of WLTVJTRANSIENT_KEY while the key can be delivered in the encrypted WTLV_SECURE_CONTEXT to the Destination (ancestor to the Supplicant) directly.
  • the WTLV_SECURE_CONTEXT response must encrypt the Nonce, Key and Key TLV as well as append a WTLVJVIIC.
  • the NSK provided at authentication may be not meet the freshness requirement
  • the supplicant EM must include a Nonce in the requesting WTLV_SECURE_CONTEXTJREQ so that the IA can then derive a CTK and use it to authenticate the reply.
  • the Reply message will include the IA's Nonce and it's WTLV_SECURE_CONTEXT_REPLY MIC and an extra WTLVJVIIC that serves as the authenticator to the supplicant EM.
  • the final authentication and liveness proof of this key refresh must be completed with at WTLV_AUTHENTICATOR.
  • CTKj N-IA PRF-256( NSK, "SWAN EM - IA link Context Transfer Key Derivation"
  • the defined PRF-256 function is based on HMAC-SHAl and allows the NSK to be stretched to 256 and ensure freshness by having each node contribute fresh key material.
  • the SCM initiates a 4-way handshake with the MN to establish the KRK and BTK.
  • the messages are forwarded to the MN via the AP, with the AP decapsulating the WLCCP header and forwarding the EAPOL Key messages to the MN.
  • the AP On receipt of the 2 nd message from the MN to the SCM, the AP triggers a pre-registration request to request forwarding of the BTK. Details of this exchange depicted in the Fast Handoff Specification[8].
  • the pre-registration uses a WTLV_EMIT_SESSION that embeds a Secure Context TLV forwarding the following MN infonnation:
  • the Pre-Registration request includes the above TLV to propagate the Nonc ⁇ MN contributed by the MN as well as the MIC TLV used to prove liveness to the SCM that the MN has conectly derived the KRK.
  • the pre-registration concludes with a reply with the Secure Context TLV as:
  • the MN Authenticator will remove the MN's credential after it sends a Pre-Registration Reply. That is, the MN Authenticator will not cache nor will it propagate the PMK to any node other than to the immediate AP.
  • the Pre- registration reply terminates by forwarding the PMK to the AP using the following Secure Context TLV:
  • Tx Key Length there is a second Optional Tx Key Length, for authentication types that provide both a Rx and Tx key in the MS-MPPE Radius attribute. All authentication types will provide an Rx key, the Tx key is optional and it's length will be zero when it is not provided by tlie Authentication Server. Note that in any of tlie negotiated Key Management types, the VLAN is forwarded to the AP as the VLAN field provided in the Pre-Registration message.
  • the WTLV_SECURE_CONTEXT replies are encrypted from the WTLV_SECURE_CONTEXT Nonce field through the end (up to but excluding) the WTLV- MIC using the CTK established between the AP and MN Authenticator. Similarly, tlie same fields are authenticated using HMAC-MD5.
  • CCKM provides a base key, BTK to generate the link key, PTK.
  • the request format is defined as follows:
  • the new AP identifies the MN by using its MAC address.
  • the RN is encapsulated as the KSC.
  • the MIC is an HMAC-MD5 operation over the entire WTLV_MN_SECURE_CONTEXT_REQ message, beginning with the WLTV_MN_SECURE_CONTEXT_REQ type through and including the MIC MN -
  • the SSBD serves as a means for the MN Authenticator to validate security credentials for the MN and ensure that the MN is not switching to a prohibited VLAN. While the MN Authenticator can effectively match the security credentials, it is up to the AP to decide on policy; e.g. the AP must define what state it will transition to upon a failure. The MN Authenticator must also validate the MN's authorization by computing and matching the provided MIC MN . Finally, it must also ensure that the session timeout for the MN has not expired. On a successful response, the MN Authenticator will safely deliver the BTK to the new AP and affect a switch from old AP to new AP. That is, the MN's registration entry will reflect the new AP's BSSED and the RN will be incremented by one.
  • the response TLV is defined as follows:
  • the WTLV_MN_SECURE_CONTEXT_REPLY response is encrypted from the WTLV_MN_SECURE_CONTEXTJ EPLYNonc ⁇ field through the end (up to but excluding) the WTLV-MIC using the CTK established between the AP and MN Authenticator. Similarly, the same fields are authenticated using HMAC-MD5.
  • the MN Authenticator Since the MN Authenticator provides the MNs session timeout to the active AP, it is up to the AP to enforce a re-authentication prior to the expiration ofthe session timeout.
  • the response will populate the BTK field with all zeroes and include one ofthe following status values:
  • MN's credentials are forwarded during a MN registration. If the credentials are being forwarded, then no optional key is forwarded, rather a new TLV holding most ofthe MN's cached credentials are propagated to the MN's ancestry infrastructure nodes, terminating at the SCM. In the standalone mode, the SCM does not forward credentials unless predictive roaming is (statically) configured at the time SCM or LCM is initialized. The MNs credentials are forwarded using the WTLV_MN_SEC_CONTEXT. -WTLV_MN_SEC_CONTEXT.
  • This TLV is only used during a MN Registration Reply to forward it's credentials from the MN Authenticator to the MN's ancestors excluding the AP (unless predictive roaming has been configured). For example, if the LCM is the MN Authenticator, the LCM will forward the MN credentials to the SCM.
  • the TLV is defined as follows:
  • This TLV carries highly sensitive information and thus must be encrypted using the CTK shared between the MN Authenticator and the destined EM.
  • the Secure Context TLV that embeds the MN Secure Credentials TLV must be authenticated, e.g. a TLV MIC must also be used.
  • the MN Secure Credentials TLV is encrypted from the State field through the Cipher field.
  • This TLV is only valid between APs and MN Authenticators as it is used to update the key sequencing between the AP and MN. Since APs are capable of affecting PTK rekeys, the SCM must be appraised of any key refreshes as they occur. A request for update but be sent from the AP to MN Authenticator as follows:
  • the WTLV_KEY_UPDATE message is encrypted and authenticated using the CTK established between the AP and MN Authenticator.
  • the MN Authenticator must conectly decrypt and authenticate this request for a successful update and response. That is, if the message can not be decrypted, authenticated nor is the RN greater than the cunent RN, the MN authenticator discards this message and no update is done. However, the response must provide a status to indicate how it failed.
  • the response is defined as follows:
  • the MN Authenticator may need to request the NSK ofthe associated AP upon a successful EAP authentication.
  • legacy MN nodes that only support static WEP keys and/or 802. IX authentication types (such as EAP-MD5) that do not provide dynamic keys
  • the MN Authenticator must use the AP statically configured NSK for the negotiated SSBD/VLAN. To achieve this, a new WTLV is defined to allow the MN Authenticator request the NSK of the associated AP.
  • the Requesting TLV is defined as:
  • the Reply TLV is definec as:
  • WTLV_NSK TLV length MN-BD WTLV_TRANSIENT_KEY WTLV JVIIC
  • This TLV is only required when pre-shared keys and authentication types such as EAP-MD5 are used and result in using statically configured keys. While this use is highly discouraged due to insecurities, this feature is presented to better support legacy systems and allow for a migration path.
  • the key retrieval would be achieved by using a WLCCP_CONTEXT request/reply exchange between the MN and AP.
  • a WTLV_AUTHENTICATOR is required to ensure liveness of a CTK between a link. This is effectively the means by which the Originating EM authenticates with it's ancestor. While any of the link endpoints can request this in a pre-registration request response. It is expected to follow post a Secure Context (or WTLV_BMIT_SESSION) request and reply, typically during registration.
  • the TLV is defined as follows:
  • the Originating MIC is computed as follows:
  • MIC request HMAC-MD5(CTK SRC- Ds ⁇ , SRC-BD
  • the Destination must increment the provided Nonce SRC and compute it's MIC as follows:
  • Request and Reply WTLV_AUTHENTICATOR must encrypt the TLV as follows:
  • the security policy negotiated by the MN must be propagated to the SCM when:
  • MN roams from cunent AP to new AP and establishes reassociation to new AP
  • the RSNEE is included in the signature element included in the reassociation message.
  • the RSNIE must be propagated to the SCM for validation.
  • TLV As the RSNTE varies in length, it's TLV is defined as follows:
  • a "lateral" Context Request or Context Reply message is forwarded independently of the SWAN Topology Tree.
  • the Originator and Responder may not be on the same Topology Tree branch; therefore, the Originator and Responder may not share a secret CTK.
  • the Inbound and Outbound flags are set OFF in a lateral Context message.
  • a "lateralL-CTK" (L-CTK) shared by the Originator and Responder of a lateral Context message is used to authenticate the message and to encrypt any sensitive TLVs contained in the message.
  • a common ancestor of the Originator and Responder functions as a trusted third party to generate a L-CTKL-CTK.
  • the common ancestor uses the path CTK it shares with the Originator and the path CTK it shares with the Responder to securely deliver the L-CTKL-CTK to each node.
  • the common ancestor generates a "ticket" and a L-CTK.
  • the L-CTK is encrypted with the path CTK shared by the common ancestor and the Originator.
  • the ticket also contains the L-CTK and is encrypted with tl e path CTK shared by the common ancestor and the Responder.
  • the L-CTK and ticket are delivered to the context transfer Originator in a WTLV_CTK_TICKET TLV.
  • the Originator includes the Node BD ofthe common ancestor, the ticket and an
  • the Originator uses the L-CTK to generate the WTLVJVIIC TLV used to authenticate the Context Request.
  • the Responder decrypts the ticket with the path CTK it shares with the common ancestor and extracts the L-CTK.
  • the Responder can then use the L- CTK to authenticate the message and to decrypt any encrypted TLVs.
  • the Responder also uses the CTK to authenticate the Reply message and to encrypt any sensitive TLVs contained in the Reply.
  • the root CM is the common ancestor of all SWAN nodes; therefore, the root CM can establish a L-CTK for any two nodes.
  • An Originator node can send a WTLV_TICKET_REQUEST TLV, in a Context Request message, to the root CM to request a L-CTK and ticket for a second Responder node.
  • the root CM returns the ticket and the L- CTK in a WTLV_CTK TTCKET TLV in the Context Reply message.
  • a MN roams from an old AP to a new AP it may be necessary to forward context information laterally from the old AP to the new AP, in a Context Request message.
  • the nearest common ancestor CM can automatically deliver a L-CTK and a "ticket" for the new AP in the Deregistration Request message sent to the old AP.
  • the old AP can use the L-CTK to generate a WTLVJVIIC TLV and to encrypt any sensitive context information in the Context Request sent to the new AP, as described above.
  • a similar mechanism can be used to transfer context laterally from the "old LCM” to the "new LCM” when a MN roams to a new local control domain.
  • This section describes a simple single-subnet WLCCP implementation where the SCM for each subnet operates in SCM standalone mode and WLCCP is NOT used to update Layer 2 forwarding paths.
  • the simple implementation includes the following components: The SCM is the "root CM' in a standalone single subnet infrastmcture. AP and MN Initial Authentication
  • MN Preregistration MN Fast Reauthentication Simple AP and MN Registration.
  • WLCCP Registration does NOT establish Layer 2 forwarding paths.
  • the SCM is the 802. IX Authenticator for both MNs and APs. EAPOL messages are relayed between the SCM and parent APs in WLCCP AAA messages.
  • the simple implementation does not support Layer 2 path updates, inter-subnet handoffs, or inter-subnet context transfer.
  • the network topology does not include a CCM or LCMs.
  • the existing Cisco DDP protocol is used to establish and delete layer-2 forwarding paths. DDP is also used for intra-subnet handoffs (i.e. when stations roam within a single subnet).
  • the simple implementation uses the following WLCCP message types:
  • the Wl Network Topology includes an SCM and APs in a single subnet. It also 5 includes any MNs associated with those APs. Layer 2 path updates are not supported; fast- reauthentication of repeater APs is not supported; therefore, multihop AP-to-AP links are generally transparent to the Wl implementation.
  • the active SCM operates in subnet standalone mode in the simple WLCCP implementation. o
  • the data structures and state variables required for the Wl implementation are the same as the General SCM Data Structures and State Variables.
  • the SCM is the EM and MN 802. IX authenticator; therefore, it must maintain an Authenticated Node Table.
  • Each SCM Candidate which is configured with a non-zero SCM Priority value, must participate in the SCM election protocol, as described in the section entitled "Active SCM s Election.
  • the WTLV_ROOT_CM_BMFO TLV contains the IPv4 address ofthe SCM.
  • Wl - EM Authentication. o Each AP must mutually authenticate with the 802. IX Infrastructure Authenticator, which is the active SCM in the simple WLCCP implementation.
  • the SCM advertises its IP address in the ROOT_CMJGMFO TLV in SCM_Advertisement Reply messages.
  • WLCCP IP- encapsulated Context Request and Reply messages are used to transport EAPOL authentication messages between the "Supplicant" AP and the 802. IX Authenticator.
  • the 5 AP/SCM mutual authentication process establishes a Network Session Key (NSK) that is shared by the Supplicant AP and the SCM.
  • An AP must initiate Path Authentication with the SCM after it has successfully authenticated (and whenever it roams).
  • the NSK is used in the Path Authentication process (described below) to establish an AP-SCM Context Transfer Key
  • the active SCM must maintain an Registration Table, which has an entry for each AP in its subnet and each MN associated with those APs.
  • the Registration Table is initialized to 'empty'.
  • the active SCM resets the table to empty whenever it relinquishes the active SCM status.
  • the Registration Table is only used to manage MN context information. It does NOT contain Layer 2 forwarding infonnation and Path State infonnation.
  • the SCM creates or updates a Registration Record for an AP or MN when it receives a valid Registration Request and generates a conesponding Registration Reply for the AP or MN.
  • Wl - (Pre)Registration Message Authentication h the simple WLCCP implementation, Preregistration and Registration Messages are authenticated with an SCM/AP CTK established via AP Path Authentication.
  • the CTK is used to generate and check a Message Integrity Check contained in a WTLVJVIIC TLV in all (Pre)Registration messages.
  • the SCM always uses the CTK it shares with the Originator to authenticate (Pre)Registration Request messages.
  • the AP always uses the CTK it shares with the SCM (i.e. the Responder) to authenticate (Pre)Registration Reply messages.
  • (Pre)Registration messages generated by a non-root AP are not processed or autlienticated by intermediate APs, in the simple WLCCP implementation.
  • General WLCCP message authentication is discussed in detail in the section entitled "WLCCP Message Authentication".
  • An AP must authenticate its path to the SCM, as described below, to establish and update a Context Transfer Key (CTK) that is shared with the SCM.
  • CTK Context Transfer Key
  • the SCM generates a Path-Init Reply when it receives a Path-hiit Request with the Response-Req Flag set ON.
  • the SCM returns a Path-hiit Reply with a 'good' status if it has an Authenticated Node Entry, for the Requestor AP, that is in the 'authenticated', 'preregistered', or 'registered' state; otherwise, the SCM returns a Path-hiit Reply with an 'unauthenticated' status.
  • An AP which has successfully completed path authentication, must register with the SCM, as described below.
  • the SCM generates a Registration Reply for an AP when it receives a Registration Request from the AP with the Response-Req Flag set ON.
  • the SCM returns a Registration Reply with a 'good' status if it has an Authenticated Node Entry, for the Requestor AP, that is in the 'preregistered' or 'registered' state; otherwise, the SCM returns a Registration Reply with an 'unauthenticated' status.
  • the SCM creates or updates an AP Registration Record for the Originator, when it generates a Registration Reply with a 'good' status. The age of the Registration Record is reset to '0' when a good Reply is generated.
  • a new parent AP sends a Preregistration Request to the SCM, with the Response-Req Flag set ON, to obtain the dynamic security credentials of a child MN when it reassociates.
  • the SCM generates a Preregistration Reply for a MN when it receives the Preregistration Request.
  • the SCM returns a Reply with a 'good' status if has an Authenticated Node Entry for the MN.
  • the protocol for transfening a MN's security credentials to a new parent AP is discussed in detail in the section entitled "MN Security Context Transfer". Wl - Received MN Registration Request.
  • the SCM generates a Registration Reply for a MN when it receives a Registration Request from the MN's parent AP with the Response-Req Flag set ON.
  • the SCM returns a Registration Reply with a 'good' status if 1) it has an Authenticated Node Entry, with a 'successful' status, for the Requestor MN and 2) it has a 'bound' Registration Record for the Originator AP.
  • the SCM returns a Registration Reply with an 'unauthenticated' status if the MN is not authenticated.
  • the SCM returns a Registration Reply with an 'unregistered parent' status if the parent AP does not have a bound Registration Record.
  • the SCM accepts Registration Requests in order of anival.
  • the SCM should timestamp a MN Registration Record each time a 'good' Registration Reply is generated for the respective MN.
  • the timestamp is calculated using the cunent time minus any Delay value in the conesponding Registration Request.
  • the SCM should discard a received Registration Request for a MN if there is ,an existing Registration Record for the MN and the timestamp value in the entry is greater than the cunent time minus any Delay value in the Registration Request.
  • tl e SCM does NOT generate a Deregistration Request when a MN roams to a different parent AP. Wl - AP Operation.
  • AP procedures are, generally, described in the order of AP "top-level” WLCCP state transitions. Top-level AP WLCCP states and state transitions are described in the section entitled “AP Operational Modes”.
  • the simple AP implementation requires the following AP procedures:
  • An AP must process SCM-Advertisement Reply messages to discover the active SCM.
  • An AP must mutually authenticate with the 802. IX BM Authenticator, and establish an NSK.
  • Each AP must authenticate its path to the SCM to establish a CTK. APs must register with SCM.
  • Registered APs must generate SCM Advertisement Reply messages on secondary ports. Registered APs must preregister MNs to obtain MN dynamic credentials. Registered APs must register MNs.
  • Preregistration and Registration messages are sent with the Hopwise-Routing Flag set OFF; therefore, intermediate APs do not process the messages.
  • An AP must monitor SCM Advertisement Reply messages received on its primary port on the native VLAN to determine if there is an active SCM for the native VLAN.
  • An AP executes the simple WLCCP protocol if there is an active SCM for the AP's native VLAN.
  • the MN 802. IX Authenticator is in the SCM when the AP is registered with the active
  • An AP must mutually authenticate with the 802. IX EM Authenticator when it first discovers a new instance of an active SCM, as described above in the section entitled "Wl - EM Authentication".
  • the BM Authenticator is always tlie active SCM, in the simple WLCCP implementation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé et un système pour le traitement des noeuds mobiles itinérants dans un réseau sans fil. Le système fait appel à un gestionnaire de contexte de sous-réseau pour enregistrer les clés de session de réseau, la politique de sécurité et la durée de la session en cours (par exemple, interruption de session) pour les noeuds mobiles, et ce gestionnaire est établi lorsque le noeud mobile est initialement authentifié. Des clés de transit par paires sont dérivées de la clé de session du réseau. Le gestionnaire traite les demandes de réassociation ultérieures. Lorsqu'un noeud mobile est en itinérance vers un nouveau point d'accès, le point d'accès obtient la clé de session de réseau depuis le gestionnaire et valide le noeud mobile en établissant une nouvelle clé transitoire par paires, à partir de la clé de session de réseau.
PCT/US2004/011880 2002-11-26 2004-04-16 Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide WO2004095800A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2004231612A AU2004231612C1 (en) 2002-11-26 2004-04-16 802.11 using a compressed reassociation exchange to facilitate fast handoff
EP04759954A EP1614273A1 (fr) 2003-04-17 2004-04-16 Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide
CA002520494A CA2520494A1 (fr) 2003-04-17 2004-04-16 Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/417,653 2003-04-17
US10/417,653 US7350077B2 (en) 2002-11-26 2003-04-17 802.11 using a compressed reassociation exchange to facilitate fast handoff

Publications (1)

Publication Number Publication Date
WO2004095800A1 true WO2004095800A1 (fr) 2004-11-04

Family

ID=33309511

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/011880 WO2004095800A1 (fr) 2002-11-26 2004-04-16 Protocole 802.11 utilisant un echange de reassociation comprime pour faciliter le transfert rapide

Country Status (4)

Country Link
EP (1) EP1614273A1 (fr)
AU (1) AU2004231612C1 (fr)
CA (1) CA2520494A1 (fr)
WO (1) WO2004095800A1 (fr)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7724704B2 (en) 2006-07-17 2010-05-25 Beiden Inc. Wireless VLAN system and method
US7724703B2 (en) 2005-10-13 2010-05-25 Belden, Inc. System and method for wireless network monitoring
US7844298B2 (en) 2006-06-12 2010-11-30 Belden Inc. Tuned directional antennas
US7865713B2 (en) 2006-12-28 2011-01-04 Trapeze Networks, Inc. Application-aware wireless network system and method
US7873061B2 (en) 2006-12-28 2011-01-18 Trapeze Networks, Inc. System and method for aggregation and queuing in a wireless network
US7912982B2 (en) 2006-06-09 2011-03-22 Trapeze Networks, Inc. Wireless routing selection system and method
US8064939B2 (en) 2006-06-01 2011-11-22 Juniper Networks, Inc. Wireless load balancing
US8072952B2 (en) 2006-10-16 2011-12-06 Juniper Networks, Inc. Load balancing
US8150357B2 (en) 2008-03-28 2012-04-03 Trapeze Networks, Inc. Smoothing filter for irregular update intervals
US8161278B2 (en) 2005-03-15 2012-04-17 Trapeze Networks, Inc. System and method for distributing keys in a wireless network
US8218449B2 (en) 2005-10-13 2012-07-10 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US8238298B2 (en) 2008-08-29 2012-08-07 Trapeze Networks, Inc. Picking an optimal channel for an access point in a wireless network
US8238942B2 (en) 2007-11-21 2012-08-07 Trapeze Networks, Inc. Wireless station location detection
US8250587B2 (en) 2005-10-27 2012-08-21 Trapeze Networks, Inc. Non-persistent and persistent information setting method and system for inter-process communication
US8270408B2 (en) 2005-10-13 2012-09-18 Trapeze Networks, Inc. Identity-based networking
US8340110B2 (en) 2006-09-15 2012-12-25 Trapeze Networks, Inc. Quality of service provisioning for wireless networks
US8457031B2 (en) 2005-10-13 2013-06-04 Trapeze Networks, Inc. System and method for reliable multicast
US8474023B2 (en) 2008-05-30 2013-06-25 Juniper Networks, Inc. Proactive credential caching
US8509128B2 (en) 2007-09-18 2013-08-13 Trapeze Networks, Inc. High level instruction convergence function
US8638762B2 (en) 2005-10-13 2014-01-28 Trapeze Networks, Inc. System and method for network integrity
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
US8902904B2 (en) 2007-09-07 2014-12-02 Trapeze Networks, Inc. Network assignment based on priority
US8966018B2 (en) 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US8964747B2 (en) 2006-05-03 2015-02-24 Trapeze Networks, Inc. System and method for restricting network access using forwarding databases
US8978105B2 (en) 2008-07-25 2015-03-10 Trapeze Networks, Inc. Affirming network relationships and resource access via related networks
US9191799B2 (en) 2006-06-09 2015-11-17 Juniper Networks, Inc. Sharing data between wireless switches system and method
US9258702B2 (en) 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US20220303868A1 (en) * 2019-09-11 2022-09-22 Carrier Corporation Bluetooth mesh routing with subnets

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8792646B2 (en) 2008-03-25 2014-07-29 Qualcomm Incorporated Systems and methods for group key distribution and management for wireless communications systems

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020061748A1 (en) * 2000-11-17 2002-05-23 Kabushiki Kaisha Toshiba Scheme for registration and authentication in wireless communication system using wireless LAN

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020061748A1 (en) * 2000-11-17 2002-05-23 Kabushiki Kaisha Toshiba Scheme for registration and authentication in wireless communication system using wireless LAN

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ARKKO J ET AL: "EAP AKA Authentication", INTERNET DRAFT OF THE INTERNET ENGINEERING TASK FORCE IETF, February 2002 (2002-02-01), pages 1 - 28, XP002273977, Retrieved from the Internet <URL:http://www.potaroo.net/ietf/old-ids/draft-arkko-pppext-eap-aka-03.txt> [retrieved on 20040318] *
DECLEENE B ET AL: "Secure group communications for wireless networks", MILCOM 2001. PROCEEDINGS. COMMUNICATIONS FOR NETWORK-CENTRIC OPERATIONS: CREATING THE INFORMATION FORCE. MCLEAN, VA, OCT. 28 - 30, 2001, IEEE MILITARY COMMUNICATIONS CONFERENCE, NEW YORK, NY: IEEE, US, vol. 1 OF 2, 28 October 2001 (2001-10-28), pages 113 - 117, XP010578990, ISBN: 0-7803-7225-5 *
THE INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS: "IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS-PORT-BASED NETWORK ACCESS CONTROL", AMERICAN NATIONAL STANDARD, 13 July 2001 (2001-07-13), New York, USA, pages 1 - 134,I-VIII, XP002966199 *
WALDVOGEL M ET AL: "THE VERSAKEY FRAMEWORK: VERSATILE GROUP KEY MANAGEMENT", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, IEEE INC. NEW YORK, US, vol. 17, no. 9, September 1999 (1999-09-01), pages 1614 - 1631, XP002941560, ISSN: 0733-8716 *

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8161278B2 (en) 2005-03-15 2012-04-17 Trapeze Networks, Inc. System and method for distributing keys in a wireless network
US8218449B2 (en) 2005-10-13 2012-07-10 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US7724703B2 (en) 2005-10-13 2010-05-25 Belden, Inc. System and method for wireless network monitoring
US8638762B2 (en) 2005-10-13 2014-01-28 Trapeze Networks, Inc. System and method for network integrity
US8514827B2 (en) 2005-10-13 2013-08-20 Trapeze Networks, Inc. System and network for wireless network monitoring
US8457031B2 (en) 2005-10-13 2013-06-04 Trapeze Networks, Inc. System and method for reliable multicast
US8270408B2 (en) 2005-10-13 2012-09-18 Trapeze Networks, Inc. Identity-based networking
US8116275B2 (en) 2005-10-13 2012-02-14 Trapeze Networks, Inc. System and network for wireless network monitoring
US8250587B2 (en) 2005-10-27 2012-08-21 Trapeze Networks, Inc. Non-persistent and persistent information setting method and system for inter-process communication
US8964747B2 (en) 2006-05-03 2015-02-24 Trapeze Networks, Inc. System and method for restricting network access using forwarding databases
US8966018B2 (en) 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US8064939B2 (en) 2006-06-01 2011-11-22 Juniper Networks, Inc. Wireless load balancing
US9838942B2 (en) 2006-06-09 2017-12-05 Trapeze Networks, Inc. AP-local dynamic switching
US9191799B2 (en) 2006-06-09 2015-11-17 Juniper Networks, Inc. Sharing data between wireless switches system and method
US10327202B2 (en) 2006-06-09 2019-06-18 Trapeze Networks, Inc. AP-local dynamic switching
US10638304B2 (en) 2006-06-09 2020-04-28 Trapeze Networks, Inc. Sharing data between wireless switches system and method
US7912982B2 (en) 2006-06-09 2011-03-22 Trapeze Networks, Inc. Wireless routing selection system and method
US11627461B2 (en) 2006-06-09 2023-04-11 Juniper Networks, Inc. AP-local dynamic switching
US11432147B2 (en) 2006-06-09 2022-08-30 Trapeze Networks, Inc. Untethered access point mesh system and method
US10798650B2 (en) 2006-06-09 2020-10-06 Trapeze Networks, Inc. AP-local dynamic switching
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
US9258702B2 (en) 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US11758398B2 (en) 2006-06-09 2023-09-12 Juniper Networks, Inc. Untethered access point mesh system and method
US10834585B2 (en) 2006-06-09 2020-11-10 Trapeze Networks, Inc. Untethered access point mesh system and method
US8581790B2 (en) 2006-06-12 2013-11-12 Trapeze Networks, Inc. Tuned directional antennas
US7865213B2 (en) 2006-06-12 2011-01-04 Trapeze Networks, Inc. Tuned directional antennas
US7844298B2 (en) 2006-06-12 2010-11-30 Belden Inc. Tuned directional antennas
US7724704B2 (en) 2006-07-17 2010-05-25 Beiden Inc. Wireless VLAN system and method
US8340110B2 (en) 2006-09-15 2012-12-25 Trapeze Networks, Inc. Quality of service provisioning for wireless networks
US8446890B2 (en) 2006-10-16 2013-05-21 Juniper Networks, Inc. Load balancing
US8072952B2 (en) 2006-10-16 2011-12-06 Juniper Networks, Inc. Load balancing
US8670383B2 (en) 2006-12-28 2014-03-11 Trapeze Networks, Inc. System and method for aggregation and queuing in a wireless network
US7873061B2 (en) 2006-12-28 2011-01-18 Trapeze Networks, Inc. System and method for aggregation and queuing in a wireless network
US7865713B2 (en) 2006-12-28 2011-01-04 Trapeze Networks, Inc. Application-aware wireless network system and method
US8902904B2 (en) 2007-09-07 2014-12-02 Trapeze Networks, Inc. Network assignment based on priority
US8509128B2 (en) 2007-09-18 2013-08-13 Trapeze Networks, Inc. High level instruction convergence function
US8238942B2 (en) 2007-11-21 2012-08-07 Trapeze Networks, Inc. Wireless station location detection
US8150357B2 (en) 2008-03-28 2012-04-03 Trapeze Networks, Inc. Smoothing filter for irregular update intervals
US8474023B2 (en) 2008-05-30 2013-06-25 Juniper Networks, Inc. Proactive credential caching
US8978105B2 (en) 2008-07-25 2015-03-10 Trapeze Networks, Inc. Affirming network relationships and resource access via related networks
US8238298B2 (en) 2008-08-29 2012-08-07 Trapeze Networks, Inc. Picking an optimal channel for an access point in a wireless network
US20220303868A1 (en) * 2019-09-11 2022-09-22 Carrier Corporation Bluetooth mesh routing with subnets
US11917520B2 (en) * 2019-09-11 2024-02-27 Carrier Corporation Bluetooth mesh routing with subnets

Also Published As

Publication number Publication date
CA2520494A1 (fr) 2004-11-04
AU2004231612A1 (en) 2004-11-04
AU2004231612B2 (en) 2009-11-19
AU2004231612C1 (en) 2010-05-20
EP1614273A1 (fr) 2006-01-11

Similar Documents

Publication Publication Date Title
CA2507119C (fr) 802.11 utilisant un echange par reassociation compresse pour faciliter le transfert intercellulaire rapide
AU2004231612B2 (en) 802.11 using a compressed reassociation exchange to facilitate fast handoff
US8122249B2 (en) Method and arrangement for providing a wireless mesh network
KR100813295B1 (ko) 무선 휴대 인터넷 시스템에서 ｅａｐ를 이용한 보안 관계협상 방법
US9553875B2 (en) Managing user access in a communications network
US8270382B2 (en) System and method for securing mesh access points in a wireless mesh network, including rapid roaming
KR101481558B1 (ko) 이기종 무선접속망간 보안연계 설정 방법
US8561200B2 (en) Method and system for controlling access to communication networks, related network and computer program therefor
AU2007292554B2 (en) Method and apparatus for establishing security associations between nodes of an ad hoc wireless network
US20090175454A1 (en) Wireless network handoff key
US20030031151A1 (en) System and method for secure roaming in wireless local area networks
BRPI0716621A2 (pt) Gerenciamento de chave de rede ad-hoc
EP1887758B1 (fr) Utilisation d&#39;un échange de réassociation compressé pour faciliter un transfert rapide
DeCarlo et al. Distributed trust relationship and polynomial key generation for IEEE 802.16 m networks
Ramezani Coordinated Robust Authentication In Wireless Networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2520494

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2004759954

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004231612

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2004231612

Country of ref document: AU

Date of ref document: 20040416

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2004231612

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2004759954

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2004759954

Country of ref document: EP