Title: EXTENSIBLE ARCHITECTURE FOR UNTRUSTED MEDIUM DEVICE CONFIGURATION VIA TRUSTED MEDIUM
TECHNICAL FIELD
] 0001] The subject invention relates generally to computer system(s) and, more
particularly, to an extensible architecture for untrusted medium (e.g., wireless) device configuratiorM'/a trusted medium.
BACKGROUND OF THE INVENTION
[0002] The popularity of employing wireless device(s) with computer system(s)
has increased in recent years. For example, many devices communicate via wireless busses such as WiFi (IEEE 802.11) and/or Bluetooth.
[0003] "Bluetooth" refers to a protocol of a short-range (e.g., about 10 meters)
frequency-hopping radio link between devices to allow wireless connections between the
devices. Bluetooth employs Gaussian frequency shiA keying to modulate the data to
frequecies around 2.4 GHz and is capable of point-to-point or point-to-multipoint
communication. This flexibility allows the wireless technology of Bluetooth to penetrate
the market in a variety of applications such as heart rate monitors, PDAs (personal digital
assistants), and human interface devices (HIDs), for example, keyboards.
] 0004] With respect to WiFi, generally, when a user comes within range of a
wireless network, the client device is able to discern two pieces of information about that network, without connecting to it (e.g., from the wireless network beacon): (1) the service set identifier (SS1D) of the network (e.g., essentially its name); and, (2) whether or not the network encrypts data. If the network employs encryption, an encryption key is required. The encryption key can be manually entered by the user and/or sent in accordance with the S02.1x protocol.
[0005] With the information that the client device can retrieve from the wireless
network beacon, the client device can generally determine whether the network is of type unencrypted, encrypted or, with the addition of a Wi-Fi Protected Access (WPA) information element, encrypted using WPA-pre-shared key or encrypted using WPA. If it is unencrypted, then a user needs only to acknowledge that the network is insecure, and
that they wish to use it in spite of that information. However, if it is encrypted and does not use WPA, then il either requires the user to enter a Wired Equivalent Privacy (WEP) key or it is an 802.1x-enabled network which distributes the WEP key automatically (requiring the client computer to enable SOI. lx authentication to complete the connection).
[0006] Employment of a wireless device with a computer system can differ
markedly from the use of a wired device. For example, a user, of a wireless device can be required to indicate with which computer system and/or network the user desires the wireless device to communicate. Additionally, a user and/or wireless device can provide a secret key to facilitate encrypted communication. Further, the computer system and/or wireless device can engage in mutual authentication and/or deal with device(s) going out of range and reappearing.
[0007] There are many security issues related to the use of wireless device(s).
For example, a rogue computer system and/or network can attach to a wireless device before a user of the wireless device can associate the wireless device with the computer system and/or network of the user's choice. Additionally, with conventional systems, association of a wireless device with a specific computer system and/or network can take an excessive amount of time (e.g., five minutes).
SUMMARY OF THE INVENTION
[0008] The following presents a simplified summary of the subject invention in
order to provide a basic understanding of some aspects of the subject invention. This
summary is not an extensive overview of the subject invention. It is not intended to
identify key/critical elements of the subject invention or to delineate the scope of the
subject invention. Its sole purpose is to present some concepts of the subject invention in
a simplified form as a prelude to the more detailed description that is presented later.
[0009] The subject invention provides for an extensible architecture for untrusted
medium (e.g.. wireless) device configuration via trusted medium. The architecture can be employed to associate a device that utilizes an untrusted medium (e.g.. wireless connection). Association is effected using a trusted medium, for example, a wired connection.
[0010] The architecture can facilitate configuration of the device to communicate
(eg. securely) via an untrusted medium (e.g., wireless connection). Configuration of the
device can be based, at least in part, upon information exchanged via a trusted medium
(e.g., wired connection). For example, the device can send an association request to a
driver and receives an association response from the driver. An "association request"
refers to a block of data sent from the device to a driver in order to initiate association.
An "association response" refers to a block of data sent from the driver to the device in
order to complete association (e.g., successful and/or unsuccessful).
] 0011] If the association is successful, the association response can include, for
example, configuration information (e.g.. encryption key) to enable the device to
communicate (e.g., securely) via the untrusted medium. If the association is
unsuccessful, the association response can include, for example, error information.
[0012] I" accordance with an aspect of the subject invention, a driver channels an
association request received via a trusted medium from a device to an association
manager. The driver further can provide an association response received from the
association manager to the device via the trusted medium. Alternatively, the driver can
generate and provide an association request to the association manager. Optionally, the
driver can further determine an appropriate time for issuance of an association request.
[0013] Another aspect of the subject invention provides for the association
manager to direct association data to the appropriate components. The association
manager can receive an association request from a driver. Based, at least in part, upon
routing information in the association request, the association manager can provide
information associated with the association request to a particular handler for processing.
Once the particular handler has completed processing of the association request, the
handler can provide an association response to the association manager. The association
manager can provide the association response to the requesting driver.
[0014] Yet another aspect of the subject invention provides for the handler to
(along with possibly other component(s) (not shown)) consume the association request and generates information associated with an association response. The handler takes action based, at least in part, upon contents of the association request, as described in greater detail below. For example, the action(s) can be dependent upon the connection
type sought to be established by the association request. Once the particular handler has completed processing of the association request, the handler can provide an association response to the association manager.
[0015] The architecture can include a handler registry which stores identification
information associated with one or more handlers. The association manager can employ
the identification information stored in the handler registry to determine to which of a
plurality of handlers to provide a particular association request.
[0016] Further, the architecture can, optionally, include a driver registry that
stores identification information associated with one or more drivers. The association
manager can employ the identification information stored in the driver registry to
determine which of one or more drivers to instantiate, for example, during initialization.
[0017] To the accomplishment of the foregoing and related ends, certain
illustrative aspects of the subject invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the subject invention may be employed and the subject invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the subject invention may become apparent from the following detailed description of the subject invention when considered in conjunction with the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Fig. 1 is a block diagram of an association architecture in accordance with
an aspect of the subject invention.
[0019] Fig. 2 is a diagram of an association request in accordance with an aspect
of the subject invention.
[0020] Fig. 3 is a diagram of an associate response in accordance with an aspect
of the subject invention.
[0021] Fig. 4 is a block diagram of an association management system in
accordance with an aspect of the subject invention.
[0022] Fig. 5 is a block diagram of an association management system in
accordance with an aspect of the subject invention.
[0023] Fig. 6 is a block diagram of an association handler system in accordance
with an aspect of the subject invention.
[0024] Fig. 7 is a block diagram of an association driver system in accordance
with an aspect of the subject invention.
[0025] Fig. 8 is a flow chart of a method of associating a device in accordance
with an aspect of the subject invention.
[0026] Fig. 9 is a flow chart of a method facilitating association of a device in N
accordance with an aspect of the subject invention.
[0027] Fig. 10 is a flow chart of a method of associating a device via a USB
connection in accordance with an aspect of the subject invention.
[0028] Fig. 11 is a flow chart further illustrating the method of Fig. 10.
[0029] Fig. 12 is a flow chart further illustrating the method of Figs. 10 and 11.
[0030] Fig. 13 is a flow chart of an association management method in
accordance with an aspect of the subject invention.
[0031] Fig. 14 is a flow chart of an association management method in
accordance with an aspect of the subject invention.
[0032] Fig. 15 is a flow chart further illustrating the method of Fig. 14.
[0033] Fig. 16 is a flowchart further illustrating the method of Figs. 14 and 15.
Fig. 17 is a flow chart of an association handler method in accordance with an aspect of the subject invention.
Fig. 18 illustrates an example operating environment in which the invention may function.
DETAILED DESCRIPTION OF THE INVENTION
[0036] The subject invention is now described with reference to the drawings,
wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject invention. It may be evident, however, that the subject invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the subject invention.
[0037] As used in this application, the terms "component," "handler," "model,"
"system," and the like are intended to refer to a computer-related entity, either hardware,
a combination of hardware and software, software, or software in execution. For
example, a component may be. but is not limited to being, a process running on a
processor, a processor, an object, an executable, a thread of execution, a program, and/or
a compuler. By way of illustration, both an application running on a server and the server
can be a component. One or more components may reside within a process and/or thread
of execution and a component may be localized on one computer and/or distributed
between two or more computers. Also, these components can execute from various
computer readable media having various data structures stored thereon. The components
may communicate via local and/or remote processes such as in accordance with a signal
having one or more data packets (e.g.. data from one component interacting with another
component in a local system, distributed system, and/or across a network such as the
Internet with other systems via the signal). Computer components can be stored, for
example, on computer readable media including, but not limited to, an ASIC (application
specific integrated circuit). CD (compact disc), DVD (digital video disk), ROM (read
only memory), floppy disk, hard disk, EEPROM (electrically erasable programmable
read only memory) and memory stick in accordance with the subject invention.
[0038] Further, "trusted medium" refers to a trusted connection over which
association information can be transferred in order to associate an untrusted medium.
Examples of trusted media include, but are not limited to, a serial connection, a parallel
connection and/or a universal serial bus (USB) connection "Untrusted medium" refers to
a medium which is being associated in order to establish trust. Wireless connection(s)
such as Bluetooth and/or IEEE S02.11 are examples of untrusted media.
[0039] Referring to Fig. I, an association architecture 100 in accordance with an
aspect of the subject invention is illustrated. The architecture 100 can be employed to
associate a device 110 that utilizes an untrusted medium (e.g.. wireless connection).
Association is effected using a trusted medium, for example, a wired connection.
[0040] An "association request" refers to a block of data sent from the device 110
to a driver 120 in order to initiate association. The association request can then be forwarded to an association manager 130 which forward to the association request to an
appropriate handler 140. An "association response" refers to a block of data sent from the driver 120 to the device 110 in order to complete association (e.g., successful and/or unsuccessful).
[00-41] The architecture 100 can facilitate configuration of the device 110 to
communicate (e.g., securely) via an untrusted medium (e.g.. wireless connection).
Configuration of the device 110 can be based, at least in part, upon information
exchanged via a trusted medium (e.g . wired connection). In one exaniple, the device 110
sends an association request to the driver 120 and receives an association response from
the driver 120. If the association is successful, the association response can include, for
example, configuration information (e.g., encryption key) to enable the device 110 to
communicate (eg., securely) via the untrusted medium. If the association is
unsuccessful, the association response can include, for example, error information.
[0042] In one example, the device 110 is a wireless-enabled digital camera that
also includes a USB connection. The USB connection (trusted medium) can be employed to configure the wireless connection (untrusted medium) of the digital camera. For example, a "found new hardware" wizard can be employed to choose and/create a wireless profile to transfer to the digital camera via the architecture 100. Once the profile information has been transferred to the digital camera via the USB connection, the USB connection can be disconnected and the digital camera can communicate via the wireless connection.
[0043] For example, the driver 120 can channel an association request received
via a trusted medium from a device 110 to the association manager 130. The driver 120
further can provide an association response received from the association manager 130 to
the device 110 via the trusted medium. In another example, the driver 120 generates and
provides an association request to the association manager 130. Optionally, the driver
120 can further determine an appropriate time for issuance of an association request.
[0044] In yet another example, a particular driver 120 can be employed to
configure a plurality of untrusted media. For example, a driver 120 can be employed to communicate via a USB connection to a plurality of devices 110 that communicate via a plurality of untrusted media.
[0045] The association manager 130 provides association data to the appropriate
components. The association manager 130 can receive an association request from a driver 120. Based, at least in part, upon routing information in the association request, the association manager 130 can provide information associated with the association request to a particular handler 140 for processing. Once the particular handler 140 has completed processing of the association request, the handler 140 can provide an Association response to the association manager 130. Based, at least in part, upon routing information in the association response, the association manager 130 can provide the association response to the requesting driver 120.
[0046] The handler 140 interfaces with a service (not shown) that implements
device installation. In one example, the handler 140 is the only component of the architecture 100 that has explicit knowledge of the association request. The handler 140 take action based, at least in part, upon contents of the association request, as described in greater detail below. For example, the aclion(s) can be dependent upon the connection type sought to be established by the association request. Once the particular handler 140 has completed processing of the association request, the handler 140 can provide an association response to the association manager 130.
[0047] The architecture 100 can include a handler registry 150 which stores
identification information associated with one or more handlers 140. The association manager 130 can employ the identification information stored in the handler registry 150 to determine to which of a plurality of handlers 140 to provide a particular association request.
[0048] Further, the architecture 100 can, optionally, include a driver registry 160
that stores identification information associated with one or more drivers 120. The association manager 130 can employ the identification information stored in the driver registry 160 to determine which of one or more drivers 120 to instantiate, for example, during initialization (as discussed below).
[0049] While depicted as a single entity, those skilled in the art will recognize
that the device 110 can include an object that sends and/or receives association requests and an object {e.g.. target device) that ultimately is associated with a host.
[0050] In one example, the architecture 100 supports only one association request
and associated association response. In this example, the information needed from the device 110 to facilitate association is embedded in the association request. Similarly, the information needed for the device 110 to facilitate association is embedded in the association response.
[0051] Referring to Fig. 2, an association request 200 in accordance with an
aspect of the subject invention is illustrated. Th^ association request 200 includes an association request header 210 and one or more association request attribute(s) 220 (e.g., attribute type, length and data). An attribute is a single item within an association request and/or response. For example, the association request header 210 can include a set of globally defined request attribute(s) similar in format to those described below with respect to association request attribute(s) 220.
[0052] In one example, association request(s) and/or association response(s) are
organized in a parse-able stream. The stream comprises a series of attribute(s) with each attribute having a defined type and associated data. This facilitates flexibility and extensibility of the architecture. An exemplary attribute structure is set forth in Table I:
(Table removed)

[0053] In one example, there are several pre-defined attribute types that are
intended to be used by the system itself (e.g.. common to many association types), and are not specific to any particular association type.
Table removed)

Association Request
[0054] Jn this example, an association request is a series of attributes. The first
attribute is the AssociationType. This is used to identify which handler to which the request should be directed. In this example, this value is a GUID that is defined by the handler (or some specification associated with the handler). For example, in order to associate a Bluetooth device, there can be a Bluetooth specific GUID, and a handler that has specified that it handles that particular GUID.
[0055] The second attribute in the association request is the length. This is the
total length of all of the attributes in this request including the AssociationType and
Length field itself. This is used to aide in parsing, so that if a component is not interested in a specific AssocialionType, it can skip over the whole request as opposed to having lo parse each attribute within it.
[0056] In this example, the attribute(s) that immediately follow the length are
defined carefully in order to facilitate simple devices lo be able to implement basic
association with minimal processing {e.g., device(s) having silicon-only solutions with no
firmware). In order to achieve this, being able to simply jump to a pre-defined* offset in a
structure in order to extract desired data can be helpful. Thus, in this example, the
attributes immediately following the length contain the minimal amount of data needed to
carry out basic association. Further, the attributes can be laid out in a pre-defined order
and always be present. In one example, substantially all of this required data is contained
within a single attribute. In this example, any variable length fields are located at the end
of these basic attributes so as to not affect the offset in the association request.
[0057] In another example, several attributes are employed, each containing a
small amount of data. Thus, it is to be appreciated that any number of attribute(s), if any, can follow, for example, in order to provide extended functionality.
Association response
[0058] Turning to Fig. 3, an associate response 300 in accordance with an aspect
of the subject invention is illustrated. The association response 300 includes an association response header 310 and zero, one or more association response attribute(s) 320. For example, the association response header 310 can include a set of globally defined request attribute(s) similar in format to those described below with respect to association response attribute(s) 320.
[0059] An association response attribute 320 is a piece of data comprising an
attribute type, length, and data. Similar to the association request discussed above, in one example, the association response is a series of attributes. In this example, the first attribute is the AssociationType. This is used to echo the AssocialionType of the association request that resulted in this response.
[0060] The second attribute in the association response is the length. This is the
total length of all of the attributes in this request including the AssociationType and
length field itself. This is used to aide in parsing, so that if a component is not interested in a specific AssociationType, it can skip over the response as opposed to having to parse each attribute within it.
[0061] The third attribute of the association response is the AssociationStatus.
This is to notify the device as to the result of the association request. In this example, if the association process was successful, then this value will be 0x0000, meaning that the device can continue to read the attributes in the association response. If the value is OxcOOOl, then the host could not find a handler that can handle the specified AssociationType. In this case, the device should not make any assumptions about further attributes in the association response.
[0062] The attribute(s) immediately following the AssociationStatus can be
defined carefully as discussed above to allow simple devices to be able to implement basic association with minimal processing. In this example, in order to achieve this, being able to simply jump to a pre-defined offset in a structure in order to extract desired data is necessary. So these attributes contain the minimal amount of data needed to carry out basic association. They are atso laid out in a pre-defined order and always be present in this example. Any variable length fields are located at the end of these basic attributes so as to not affect the offset in the association request. Any number of attributes, if any, can follow in order to provide extended functionality.
[0063] Referring to Fig. 4, an association management system 400 in accordance
with an aspect of the subject invention is illustrated. The association management system 400 includes an association manager 410 having a manager communication component 420 and a handler identification component 430. The system 400 further includes a handler registry 150, and, optionally, a driver registry 160.
[0064] The association manager 410 is responsible for providing association data
(e.g.. association request(s) and/or association response(s)) to the appropriate components (e.g., handler and/or driver). The manager communication component 420 can receive association request(s) from driver(s) (not shown). The manager communication component 420 can provide at least part of the association request (e.g., association request header) to the handler identification component 430.
[0065] Based on the information provided by the manager communication
component 420 and identification information stored in the handler registry 150, the handler identification component 430 identifies the particular handler (not shown) to which the association request is to be provided. In one example, the association manger 410 loads the handler identified by the handler identification component 430. In another example, handlers) are loaded at initialization (as discussed in greater detail below). Thereafter, the manager communication component 420 provides information associated with the association request to the handler identified by the handler identification component 430.
[0066] Once the handler has processed the association request, (he handler
provides an association response to the manager communication component 420. The manager communication component 420 then provides the association response to the requesting driver.
[0067] In one example, the association manager 410 validates the association
request. For example, the association manager 410 can determine whether is well-formed. Ifthe request is not well-formed, then the association manager 410 can generate an association response indicating the association request was malformed {eg., status attribute set to ERROR_MALFORMED_ASSOCIATION_REQUEST) and provide the association response to the requesting driver. In this example, the association manager 410 utilizes the following criteria to determine whether an association request is well-fomied:
a. The request length is at least large enough to hold the Association Type
and Length attributes (e.g., 36 bytes);
b. The first attribute is the Association Type and its length is of the
appropriate size (e.g.. based on a globally unique identifier (GUID)
associated with the particular handler);
c. The second attribute is the Length and is of the appropriate size (e g.,
ULONG);
d. The value of the Length attribute is greater than the Association Type and
Length attributes (e.g., 36 bytes), and is less than or equal to the length of
the request;
e. Each following attribute has a length that when added to its current
position in the request does not result in a value greater than the value in
the Length attribute;
f. Exactly one association type attribute and exactly one Length attribute is
present in the request.
[0068] Next, the association manager 410 determines if there is a handler that has
registered for the specified association type included in the association request (e.g.,
GUID stored in the handler registry 150). If a handler is not found, then the association
manager 410 can generate an association response indicating that the association type
requested is not supported and provide the association response to the requesting driver.
[0069J If a handler is found, in this example, the association manager 410 can
parse the association request and extract a list of attribute(s). The association manager
410 can then provide the list of extracted attribute(s) to the particular handler.
[0070J If the association manager 410 is unsuccessful in providing the list of
extracted attribute(s) to the particular handler, the association manager 410 can generate an association response indicating that the particular handler was not responsive and provide the association response to the requesting driver.
[0071] If the association manager 410 is successful in providing the list of
extracted attribute(s) the particular handler, upon completion of processing by the handler, in this example, the association manager 410 receives an association response attribute list from the handler. The association manager 410 can determine whether the association response attribute list is well-formed. For example:
a. There is exactly one status attribute;
b. A Length attribute and an association type attribute are not present (e.g.. to
be added by the association manager 410);
c.
If the association request included a maximum response length attribute, then the total size of the attributes must be less than that value.
[0072] If the response is well-formed, then the association manager 410 generates
an association response (e.g., byte array) based, at least in part, upon the association response attribute list. For example, the association manager 410 can:
a. Add up lhe total size of all attributes in the response attribute list;
b. Add the size required for the association type and length attributes;
c Allocate a buffer large enough to hold the response;
d. Set the first attribute in the buffer to the association type from the
association request;
e. Add the length attribute to the buffer using the calculated response length.
f. Add an association status attribute;
g. Add each additional attribute in the order that they were in the list.
[0073] The association manager 410 can then provide the association response to
the requesting driver.
[0074] In one example, the association manager implements the following
interface:
interface IManager
{
HRESULT SendAssociationRequest(BYTE* AssociationRequest, ULONG AssociationRequestLength, PBYTE *AssociationResponse, PULONG AssociationResponseLength);

TABLE 5
[0075] SendAssociationRequest() is called by driver(s) in order to begin the
association process. The association response is returned as a byte array which can easily
be sent back to the device. In one example, it is the responsibility of the driver to free the
AssociationResponse.
[0076] Turning to Fig. 5, an association management system 500 in accordance
with an aspect of the subject invention is illustrated. The system 500 includes an
association manager 510, a handler registry 150, a driver registry 160 and an initialization
component 520.
[0077] The association manager 510 is responsible for providing association data
(e.g., association request(s) and/or association response(s)) to the appropriate components
(eg., handler and/or driver), as discussed previously. However, in this example, the
initialization component 520 employs information stored in the driver registry 160 to
determine which of one or more drivers (not shown) to instantiate, for example, during
initialization of the system 500. For example, drivers) can be registered during
configuration of a computer system (not shown) {e.g., manually and/or automatically).
[0078] In one example, upon system initialization, the initialization component
520 identifies driver(s) and handler(s) based, at least in part, upon information stored in the driver registry 160 and handler registry 150, respectively. Thereafter, the initialization component 520 creates instances of the identified handler(s) and the vx identified driver(s).
[0079] In this example, for each of the handlers, the association manager 510 can
retrieve an association type count and allocate an associated storage buffer (e.g., association type count * sizeof (GUID)). This buffer can be used to retrieve the association types from the handler. In another example, the handler allocates the storage space and provides it to the association manager.
[0080] The association types can be an array of GUIDs that represent the specific
association types that the handler supports. For each of the GUIDs retrieved, an entry can be added to a list of GUID to Handler mappings stored in the handler registry. For example:
(Structure removed)

This list of mappings can then be employed by the association manager 510 to determine
routing of association requests to the appropriate handler.
[0081] In this example, once the handlers have been created and their association
types discovered, the initialization component 520 activates the drivers. Activation
occurs after the handlers have been loaded and initialized to ensure that association
request(s) are not received until the handlers have been discovered and loaded. For
example, to activate a driver, a "StartQ" method can be invoked.
[0082] Next, referring to Fig. 6, an association handler system 600 in accordance
with an aspect of the subject invention is illustrated. The system 600 includes a handler
610 comprising a request component 620, a response component 630 and an association
processor.
[0083] The handler 610 (along with possibly other component(s) (not shown))
consumes the association request and generates information associated with an
association response.
[0084] For example, the request component 620 can receive information
associated with an association request (e.g., the association request and/or a parsed list of
attributes) from an association manager (not shown). The request component 620 can
parse the contents of the information associated with the association request to determine
what action(s) are to be taken. The association processor 640 facilitates action(s) via the
service 650. Action(s) of can be dependent upon, for example, the connection type
sought to be established. Once the action(s) have been completed, the association
processor 640 can provide information regarding the association to the response
component 630. The response component 630 can then generate information associated
with an association response (e.g., an association response and/or list of attributes) which
can be provided to the association manager.
[0085] In one example, a plurality of handlers 610 implement the following COM
(Structure removed)

In this example, "manager" is an interface pointer to the association manager Further, "AssociationTypes" returns an array of AssociationType GUIDs that the PONG Handler can handle. Similarly, "AssociationTypeCount" is the number of AssociationTypes that ihe PONG Handler can handle. "HandleAssociationRequest()" is called by the association manager when it receives an association request that the handler 610 reported
it supported. "RequestAttribules" is a list of attribute structures. The handler 610 is expected to allocate the memory necessary to return the ResponseAttributes which is a list of attribute structures which are the attributes that will be returned to the device (not shown).
[0086] In another example, the handler 610 stores information about the device,
for example, in a database for future installation once the device is discovered on the target medium. For example, a particular handler 610 can be related (o a Wi-Fi target medium. In this example, device(s) desiring to employ the Wi-Fi target medium send association requesl(s) and receive association response(s) in the form of attribute lists. The attribute lists can be provided by the handler 610 to an association manager which can then form an association response.
[0087] With respect to Tables 9, 10 and 11 below, ".attribute" refers to a friendly
name associated with an attribute element. "Attribute ID" is an identifier (e.g.. number) used to identify the attribute element in the attribute list. "Length" refers to the length of the data in an attribute element. Attribute lengths can be varied and/or fixed and, in this example, are expressed in bytes. A length value can also specify a maximum length. In the association response, in one example, fixed lengths can be used so that the offset to the value is deterministic; aiding the ability of a device to parse the response. The actual value of the attribute may not use up the entire length allocated for the data. In these cases, an additional field can specify the actual length of the attributes data. "Allowed Values" refers to the allowed values field describes the values to be supported by the device. If an allowed value is required, it means the device must support that value if it contained in the attribute list. Unless otherwise stated in Tables 9,10 and/or 11, values should be assumed to be required. If an allowed value is optional, the device need not support the value, but should be prepared for it to be contained in the attribute list. Optional values may become required in future versions of this specification.
Wireless protocols
[0088] The IEEE 802.11 set of standards defines two network types: encrypted
networks (e.g., WEP networks) and unencrypted networks. Owing to the well-known weaknesses of the WEP protocol, the wireless industry implemented support for the IEEE
802.Ix standard as a mechanism for addressing the key deficiencies in the WEP protocol, those being user authentication, encryption key management and encryption key distribution. For WEP-encrypted networks, the user needs to provide an encryption key and for 802.1 x enabled networks the key is provided automatically if the user has a valid credential (e.g., such as a digital certificate or uscmame and password). For 802.11 networks which are encrypted, this presents a usability problem as it is currently not possible to determine a priori whether the user needs to enter the WEP key or whether the network supports 802.1.x, in which case they do not have to enter it.
To address the underlying weaknesses of the WEP algorithm, which has been shown to be cryptographically weak, a security enhancement to the 802.11 set of standards was introduced, called Wi-Fi Protected Access (WPA). WPA also addresses some of the usability issues of the original 802.11 standard by specifying an information element which WPA-capable access points include in their beacon frame. This information element describes inter alia whether the network requires the user to enter the encryption key called WPA pre'Shared key mode (WPA-PSK.) or whether the key is provided automatically by virtue of the user's credential, referred to as "WPA mode".
Wired Equivalent Privacy
WEP is defined by the IEEE 802.11 standard and is intended to provide a level of data confidentiality that is equivalent to a wired network. Due to the nature of wireless LAN networks, implementing a security infrastructure that monitors physical access to the network can be difficult. Unlike a wired network where a physical connection is required, anyone within range of a wireless access point (AP) can conceivably send and receive frames as well as listen for other frames being sent. This makes eavesdropping and remote sniffing of wireless LAN frames very easy.
WEP provides data confidentiality services by encrypting the data sent between wireless nodes. WEP encryption for an 802.11 frame is indicated by setting a WEP flag in the MAC header of the 802.11 frame. WEP provides data integrity for random errors by including an integrity check value (ICV) in the encrypted portion of the wireless frame.
The following tables illustrates the two shared keys that WEP defines-
Key type Description
Multicast/global key Encryption key that helps to protect
multicast and broadcast traffic from a wireless AP to all of its connected wireless clients.
Unicast session key Encryption key that helps to protect unicast
traffic between a wireless client and a \vireless AP and multicast and broadcast traffic sent by a wireless client to the wireless AP.
TABLE 8 WEP encryption employs the RC4 symmetric stream cipher with 40-bit and 104-bit encryption keys.
Wi-Fi Protected Access
WPA is a Wi-Fi standard designed to improved upon the security features of WEP. Unlike WEP. S02.1x authentication is required in WPA. With WPA, rekeying of both unicast and global encryption keys is required. For the unicast encryption key, the Temporal Key Integrity Protocol (TKIP) changes the key for every frame, and the change is synchronized between the wireless client and the wireless access point (AP). For the global encryption key, WPA includes a facility for the wireless AP to advertise the changed key to the connected wireless clients.
TKIP replaces WEP with an encryption algorithm that is stronger than the WEP algorithm. TKJP also provides for verification of the security configuration after the encryption keys are determined; synchronized changing of the unicast encryption key for each frame; and, determination of a unique starting unicast encryption key for each pre-shared key authentication.
WPA further employs a method know as "Michael" that specifies an algorithm that calculates an 8-byte message integrity code (MIC). The MIC is placed between the data portion of the IEEE 802.1 ] frame and the 4-byte integrity check value (ICV). The MIC field is encrypted together with the frame data and the ICV.
WPA is an interim standard that will be replaced with the IEEE's 802 1 li standard upon its completion.
Wi-Fi Handler
[0089] The association type is an attribute contained in the header section of the
association request and association response, and is separate from data attributes. This attribute is used by the association manager Jo forward the association requesl(s) to the correct handler. In this example, a Wi-Fi handler 410 has the following required association type:
(Table removed)

[0090] The data section of the association request includes attributes that are
specific to the attribute type. The following table identifies exemplary attributes that an association manager can forward to a Wi-Fi handler 610:
(Table removed)

MAC Address
[0091] The MAC Address is 6 byte value that contains the 48 bit value of the
MAC Address. For example: 0x00 0x07 0xE9 0x4C OxAS 0x1 C.Network Authentication Type Flags
[0092] This set of flags allows a device to signal which "Network Authentication
type" types are supported. This information can be used for diagnostic purposes. If a device fails to support the required attributes, then the user can be notified of this and given actionable instructs to correct the problem. In this example, the value of this field is a bitwise OR of one or more of the following values:
0x0001 = Open
0x0002 = WPAPSK
0x0004 = Shared 0x0008 = WPA 0x0010 = WPA-NONE 0x0020 = WPA2 In this example, olher values are reserved and set to 0.
Data Encryption Type Flatus x
[0093] This set of flags allows a device to signal which "Data Encryption type"
types are supported. This information can be used for diagnostic purposes. If a device fails to support the required attributes, then the user can be notified of this and given actionable instructs to correct the problem. In this example, the value of this field is a bitwise OR of one or more of the following values:
0x0001 =WEP
0x0002 = TKIP
0x0004 = AES Again, in this example, other values are reserved and set to 0.
Connection Type Flas
[0094] This set of flags allows a device to signal which "Connection type" types
are supported. This information is used for diagnostic purposes. If a device fails to support the required attributes, then the user can be notified of this and given actionable instructs to correct the problem. The value of this field is a bitwise OR of one or more of the following values:
0x01 = ESS (Extended Service Set)
0x02 = IBSS (Independent Basic Service Set) In this example, other values are reserved and are set to 0.
[0095] Based, at least in part, upon the handler 610's interaction with the service 650, the response component 630 generates information associated with an association response. Continuing with the Wi-Fi handler example, Table 11 identifies exemplary association response attributes. The lengths of the attributes in the attribute list in this
example are fixed. Thus, device manufactures can easily jump to the appropriate offset to read the value of any given attribute in the response. Offsets refer to the start of the attribute.
(Table removed)

J00991 When the data auth type is WEP. the Network key is either an ASCII or
HEX representation of a 40-bit or i 04-bit WEP key. The type can be determined by the length of the string.
WPAPSK pass phrase
[00100] If the network key attribute is a 0-63 char ASCII string and the "network
authentication type" attribute is WPA, the network key attribute is used as a pass phrase to derive the WPA binary key.
Key Provided Automatically (802.1 x)
[00101] The "Key Provided Automatically (802.Ix)" attribute dictates whether or
not the Network Key is provided via 801 .x This is typically set to 0 in cases where WPA-PSK, or WEP are used to secure the wireless network.
Network Authentication Type
[00102] The network authentication type indicates what type of security
mechanism is required to join a particular network. The flag set specifies which of the following mechanisms is used:
0x0001 = Open
0x0002 = WPAPSK
0x0004 = Shared
0x0008 = WPA
0x0010 = WPA-NONE
0x0020 = WPA2 In this example, other values are reserved and are set to 0. Significantly, unlike (he association request, these flags are mutually exclusive - only one flag can be set at a given time.
Data Encryption Type
[00103] This value specifies the encryption mechanism deployed by the wireless
network. The flag set specifies which of the following mechanisms is used:
0x0001 =WEP
0x0002 = TK.IP
0x0004 = A ES
[00104] All other values are reserved and are set to 0. Significantly, unlike the
association request, these flags are mutually exclusive - only one flag can be set at a given time.
\ Connection Type
[00105] Connection type defines the type of wireless network. The flag set
specifies which of the following mechanisms is used:
0x01= ESS
0x02 = IBSS All other values are reserved and are set to 0. These flags are mutually exclusive.
[00106) Turning next to Fig. 7, an association driver system 700 in accordance
with an aspect of the subject invention is illustrated. The system 700 includes a driver 710 comprising a trusted media communication component 720 and a driver communication component 730.
[00107] The trusted medium communication component 720 interfaces with a
device 740 via a trusted medium (e.g., USB connection). In one example, the trusted
medium communication component 720 receives an association request from the device
740 (e.g.. association request initiated time independent of device enumeration). In
another example, the trusted medium communication component 720 receives
notification of a request to issue an association request. Thereafter, the driver 710
generates an association request which is sent to an association manager (not shown) via
the driver communication component 730.
[00108] In one example, driver(s) 710 implement the following interface:
interface IPngDriver
{
// Properties
HRESULT Manager([in] IPngMgr* newVal);
// Methods
HRESULT SlartQ; HRESULT Slop();
}
TABLE 13
[00109] "Manager" is an interface pointer to the association manager so that the
driver can call SendAssociationRequest. Start() is called by the association manager
\ when it wishes for the driver to begin detecting and issuing new association requests.
Stop() is called by the association manager when it whishes for the driver to stop issuing
new association requests (eg. when a user desires to disable association over a particular
trusted medium).
[00110] In one example, a particular driver 710 can be related to a USB trusted
medium. In this example, device(s) desiring to employ an untrusted medium send
association request(s) and receive association response(s) securely through the driver
710.
[00111 ] For device(s) that implement dynamic association functionality, where
association requests can be generated independent of device enumeration, in one
example, there is an optional Interrupt IN endpoint. This endpoint facilitates notifications
of new association requests. The standard endpoint descriptor for this optional endpoint
can be found in Table 14:
(Table removed)

TABLE 14
If a device's interface does not contain the optional endpoint, then association will only occur at enumeration time. If such a device wishes to initiate the association process, it will have to do a device initiated USB reset. This will cause the device to be re-enumerated by the host, at which point the host will retrieve the associationM;equest(s) from the device. In another example, a device can also implement HUB functionality to cause the association function to come and go as the device wishes.
Since the control endpoint is the only mandatory endpoint for a device that supports an association interface, the necessary data transfers happen over that endpoint. In this example, these transfers are in the form of association class requests.
[00114] Table J 5 depicts a list of association class requests that must be supported
by a device in one example.
(Table removed)

[00120] In Ihis example, a request block is a 4KB block of data. The maximum
transfer size of a control transfer is 64KB, so 16 request blocks can be theoretically transferred in each GET_ASSOCIATION_R£QUEST. The actual amount of data to be transferred is specified by the wLength field. The BlockNumber specified in the wValue
field identifies the starting block number for this control transfer. So. in this example, the device 540 should return association request data for the request specified by Request ID starting at offset BlockNumber * 4KB, and transferring wLenglh bytes.
SET ASSOCIATION RESPONSE
[00121] This request sends a response to a specific association request identified
by the RequestlD value in the wValue fiejd:
bmRequestType 00100001B
bRequest SET_ASSOCIATION_RJESPONSE
wValue RequestlD TransferFlags
w Index Interface
wLength Length of response Data
Data Association Response
TABLE 21
(Table removed)

Association interrupt-in message(s)
NewAssociationRequest
[00123] This interrupt IN message indicates to the host that the device has new or
modified association request(s) that need to be processed. Upon receiving this message,
the host can issue a GET_ASSOCIATlONJNFORMATION request, and process the requests accordingly.
(Table removed)

TABLE 23
[00124] It is to be appreciated that the system 100, device 110, association
manager 120, handler 130, driver 140, handler registry 150, driver registry 160, system 400, association manager 410, manager communication component 420, handler identification component 430, association manager 510, initialization component 520, system 600, handler 610, request component 620, response component 630, association processor 640, service 650, system 700, driver 710, trusted medium communication component 720, driver communication component 730 and/or the device 740 can be computer components as that term is defined herein.
[00125] Turning briefly to Figs. 8-18, methodologies that may be implemented in
accordance with the subject invention are illustrated While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the subject invention is not limited by the order of the blocks, as some blocks may, in accordance with the subject invention, occur in different orders and/or concurrently with other blocks from that shown and described herein. Moreover, not all illustrated blocks may be required to implement the methodologies in accordance with the subject invention.
[00126] The subject invention may be described in the general context of
computer-executable instructions, such as program modules, executed by one or more components. Generally, program modules include routines, programs, objects, data structures, etc. that perform particular tasks or implement particular abstract data types.
Typically the functionality of the program modules may be combined or distributed as
desired in various embodiments.
[00127] Referring to Fig. 8, a method of associating a device 800 in accordance
with an aspect of the subject invention is illustrated. At 810, a connection (e.g.. of a
device) is established via a trusted medium (e.g., USB). At 820, an association request is
issued, for example, by the device and/or an associated driver. At 830, information
associated with art,association response is received (e.g., from a driver). The information
can include, for example, the association response received from an association manager.
Alternatively, the information can include a portion of the association response received
from the association manager.
[00128] At 840, a determination is made as to whether the association was
successful. If the determination at 840 is NO, no further processing occurs. If the
determination at 840 is YES, at 850, information associated with the association response
is employed to connect (e.g., the device) via an untrusted medium (e.g., wireless
connection).
[00129] Turning next to Fig. 9, a method facilitating association of a device 900 in
accordance with an aspect of the subject invention is illustrated. At 910, information
associated with an association request is received. At 920, a determination is made as to
whether an association request was received. If the determination at 920 is NO, at 930,
the association request is generated, and, processing continues at 940. If the
determination at 920 is YES, at 940, the received association request is sent, for example,
to an association manager.
[00130] At 950, an association response is received, for example, from the
association manager. At 960, information associated with the association response is
provided to the requesting device. For example, the information can include the entire
association response and/or a portion of the association response. Thereafter, no further
processing occurs.
[00131] Next, referring to Figs. 10 - 12, a method of associating a device via a
USB connection 1000 in accordance with an aspect of the subject invention is illustrated.
At 1004, a device is enumerated and/or a new association request event is issued. At
1008, a GET_ASSOCIATION_INFORMATION request is sent to the device, for
example, by a driver. At 1012, a size of the total association information is determined, for example, by the driver (e.g., size = 3 + sizeof (REQUESTJNFO) * PendingReqiiestCount).
[00132] At 1016, a determination is made as to whether substantially all of the
association information has been received, for example, by the driver. If the
determination at 1016 is NO, processing continues at 1008. If the determination at 1016
is YES, at 1020, a determination is made as to whether PendingReqiiestCount is greater
than zero. If the determination at 1020 is NO, no further processing occurs.
[00133] If the determination at 1020 is YES, at 1024, a request is identified to
handle (e.g.. by the driver). At 1028, the size of the transfer (e.g., association request) is determined. At 1032, a GET_ASSOClATION_REQUEST is sent. At 1036, a determination is made as to whether there is more request data. If the determination at 1036 is YES, process continues at 1028. If the determination at 1036 is NO, at 1040, the association requested is handled and an association response is generated (eg. by an association manager and/or handler).
[00134] At 1040, the sizeof the association response transfer is determined. At
1048, a SET_ASSOCIATION_RESPONSE is sent. At 1052, a determination is made as to whether there is more response data. If the determination at 1052 is YES, processing continues at 1044. If the determination at 1052 is NO, at 1056, a determination is made as to whether there are more requests.
[00135] If the determination at 1056 is YES, processing continues at 1024. If the
determination at 1056 is NO, at 1060 a determination is made as to whether an additional requests flag has been sent in the association information. If the determination at 1060 is YES, processing continues at 1008. If the determination at 1060 is NO, no further processing occurs.
[00136] Referring next to Fig. 13, an association management method 1300 in
accordance with an aspect of the subject invention is illustrated. At 1310, an association request is received, for example, from a driver. At 1320, a handler for the association request is identified. At 1340, a determination is made as to whether a handler exists for the association request. If the determination at 1340 is NO, at 1350, a failure of association response is generated, and, processing continues at 1360.
[00137] If the determination at 1340 is YES, at 1370, information associated with
The association request is sent to the handler. For example, the information can comprise
Ihe association request andA>r a portion of the association request (e.g., attribute list(s)).
[00138] At 1380, information associated with an association response is received
from the handler. At 1360, an association response is provided to the requesting dnver.
[00139] Turning to Figs. 14 - 16, an association management method 1400 in
accordance with an aspect of the subject invention is illustrated. At 1404, an association
request is received, for example, from a driver. At 1408, the association request is
validated. At 1412, a determination is made as to whether the association request is well-
formed. If the determination at 1412 is NO, at 1416, an association response indicating
malformed association request is generated, and, processing continues at 1420.
[00140] If the determination at 1412 is YES, at 1424, a handler for the association
request is located. At 1428, a determination is made as to whether a handler has been
found. If the determination at 1428 is NO, at 1432, an association response indicating
association type not supported is generated, and, processing continues at 1420
[00141] If the determination at 1428 is YES, at 1436, the association request is
parsed and a list of attribute(s) is built. At 1440, the attribute list is sent to the identified handler. At 1444, response information is received from the handler. At 1448, a determination is made as to whether the association was successful. If the determination at 1448 is NO, at 1452, an association response is generated indicating an appropriate error status, and, processing continues at 1420.
[00142] If the determination at 1448 is YES, at 1456, the response format is
validated. At 1460, a determination is made as to whether the response is well-formed.
If the determination at 1460 is NO, at 1464, an association response indicating an
appropriate error status is generated, and, processing continues at 1420.
[00143] If the determination at 1460 is YES, at 1468, an association response is
generated based on the response from the handler. At 1420, the association response is
provided to the requesting driver, and, no further processing occurs.
[00144] Referring to Fig. 17. an association handler method 1700 in accordance
with an aspect of the subject invention is illustrated. At 1710, information associated with an association request (e.g, attribute list) is received, for example, an association
manager. At 1720, the association request is processed. At 1730, response information is provided to the association manager.
[00145] In order to provide additional context for various aspects of the subject
invention. Fig. 18 and the following discussion are intended to provide a brief, general description of a suitable operating environment 1810 in which various aspects of the subject invention may be implemented. While the subject invention is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices, those skilled in the art will recognize that the subject invention can also be implemented in combination with other program modules and/or as a combination of hardware and software. Generally, however, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular data types. The operating environment 1810 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the subject invention. Other well known computer systems, environments, and/or configurations that may be suitable for use with the subject invention include but are not limited to, personal computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include the above systems or devices, and the like.
[00146] With reference to Fig. 18, an exemplary environment 1810 for
implementing various aspects of the subject invention includes a computer 1812. The
computer 1812 includes a processing unit 1814, a system memory 1816, and a system bus
1818. The system bus 1818 couples system components including, but not limited to, the
system memory 1816 to the processing unit 1814. The processing unit 1814 can be any
of various available processors. Dual microprocessors and other multiprocessor
architectures also can be employed as the processing unit 1814.
[00147] Thesystembus 1818 can be any of several types of bus structure(s)
including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, an S-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA),
Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Persona] Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
[00I48] The system memory 1 Si6 includes volatile memory 1820 and nonvolatile
memory 1S22. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1812, such as during start-up, is stored in nonvolatile memory 1822. By way of illustration, and not limitation, nonvolatile memory 1822 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 1820 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM(DRRAM).
[00149] Computer IS 12 also includes removable/nonremovable,
volatile/nonvolatile computer storage media. Fig. 18 illustrates, for example a disk
storage 1824. Disk storage 1824 includes, but is not limited to, devices like a magnetic
disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flash memory
card, or memory stick. In addition, disk storage 1824 can include storage media
separately or in combination with other storage media including, but not limited to, an
optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive
(CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive
(DVD-ROM). To facilitate connection of the disk storage devices 1824 to the system bus
18! 8, a removable or non-removable interface is typically used such as interface 1826.
[00150] It is to be appreciated that Fig 18 describes so Aware that acts as an
intermediary between users and the basic computer resources described in suitable operating environment 1810. Such software includes an operating system 1828. Operating system 1828, which can be stored on disk storage 1824, acts to control and allocate resources of the computer system 1812. System applications 1830 take
advantage of the management of resources by operating system 1828 through program
modules 1832 and program data 1S34 stored either in system memory 1S16 or on disk
storage 1S24. It is to be appreciated that the subject invention can be implemented with
various operating systems or combinations of operating systems.
[00151] A user enters commands or information into the computer 1812 through
input device(s) 1836. Input devices 1S36 include, but are not limited to, a pointing
device such as a mouse, trackball, stylus, touch pad. keyboard, microphone, joystick,
game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera,
web camera, and the like. These and other input devices connect to the processing unit
1814 through the system bus 1818 via interface port(s) 1838. Interface port(s) 1838
include, for example, a serial port, a parallel port, a game port, and a universal serial bus
(USB). Output device(s) 1840 use some of the same type of ports as input device(s)
1836. Thus, for example, a USB port may be used to provide input to computer 1812,
and to output infomiation from computer 1812 to an output device 1840. Output adapter
1842 is provided to illustrate that there are some output devices 1840 like monitors,
speakers, and printers among other output devices 1840 that require special adapters.
The output adapters 1842 include, by way of illustration and not limitation, video and
sound cards that provide a means of connection between the output device 1840 and the
system bus 1818. It should be noted that other devices and/or systems of devices provide
both input and output capabilities such as remote computer(s) 1S44.
[00152] Computer 1812 can operate in a networked environment using logical
connections to one or more remote computers, such as remote computer(s) 1844. The remote computer(s) 1844 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1812. For purposes of brevity, only a memory storage device 1846 is illustrated with remote computers) 1844. Remote computer(s) 1844 is logically connected to computer 1812 through a network interface 1848 and then physically connected via communication connection 1850. Network interface 1848 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper
Distributed Data Interface (CDDl), Ethernet/IEEE 802.3. Token Ring/IEEE 802 5 and the
like. WAN technologies include, but are not limited to, point-to-point links, circuit
switching networks like Integrated Services Digital Networks (ISDN) and variations
thereon, packet switching networks, and Digital Subscriber Lines (DSL).
[00153] Communication connection(s) 1S50 refers to the hardware/sofiware
employed to connect the network interface 1848 to the bus 1818. While communication connection IS50 is shown for illustrative clarity inside computer 1812, it can also be external to computer 1812. The hardware/software necessary for connection to the network interface 1848 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
[00154] What has been described above includes examples of the subject
invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the subject invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject invention are possible. Accordingly, the subject invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.
41

CLAIMS
What is claimed is:
1. An association management system comprising:
a handler registry that stores identification information associated with one or more handlers;
an association manager that provides an association request to a particular handler based, at least in part, upon routing information in the association request and the identification information stored in the handle registry.
2. The system of claim 1, the identification information associated with a handler comprising a globally unique identifier.
3. The system of claim I, further comprising an initialization component that identifies at least one driver and at least one handler to be instantiated during system initialization, the initialization component further initiating instantiation of the at least one driver and at least one handler.
4. The system of claim 3, further comprising a driver registry that stores information associated with the at least one driver to be instantiated.
5. The system of claim' 1, the association request comprising at least one association request attribute.
6. The system of claim 5, the association request attribute comprising an attribute type, an attribute data length and data.
7. The system of claim 1, the association manger generates an association response based, at least in part, upon information provided by the handler.
8. The system of claim 7, the association response comprising an association response attribute.
9. The system of claim 8, the association response attribute comprising an attribute type, an attribute length, and data.
10. The system of system of claim 7, the associatioq response comprising information for a device to communicate with a computer system via an untrusted medium.
11. The system of claim 10, the untrusted medium comprising a wireless communication connection.
12. The system of claim 10, the association request generated by a driver, the driver further receives the association response.
13. An association management method comprising:
identifying a handler based, at least in part, upon an association request; sending information associated with the association request to the identified handler.
receiving a response from the handler;
generating an association response based, at least in part, upon the response; and,
providing the association response to a requesting driver.
14. The method of claim 13, further comprising at least one of:
validating the association request;
determining whether the association request is well-formed; and, generating an association response indicating a malformed association request, if the association request is not well-formed.
15. The method of claim 13, further comprising at least one of:
determining whether a handler was located;
generating an association response indicating an association type not supported, if the handler was not located; and,
parsing the association request to build a list of attributes.
16. The method of claim 13, further comprising at least one of:
validating the response format;
determining whether an association was successful,
generating an association response indicating an error status, if the association • was not successful;
determining whether the response is well-formed; and,
generating an association response indicating an error status, if the response is not well-formed.
17. A computer readable medium having stored thereon computer executable instructions for carrying out the method of claim 13.
18. A data packet transmitted between two or more computer components that facilitates device association, the data packet comprising:
an association response comprising an association response header and an association response attribute, the association response provides information for a device to communicate with a computer system via an untrusted medium.
19. The data packet of claim 18, the association response attribute comprising an attribute type, an attribute length, and data.
20. The system of claim 18, the untrusted medium comprising a wireless communication connection.