Tunneling Extensible Authentication Protocol (“EAP”) methods are commonly used to perform authentication between two end points in a network, such as between a sender and a receiver or a client and a server. Tunneling EAP methods generally consists of two phases, a first phase in which a method (outer method) is used to establish a secure communication tunnel between two end points. In the second phase, authentication is performed. The authentication method is determined using standard EAP method negotiation. However, there are many different versions of inner and outer EAP methods, each of which may support different capabilities.
In order to support new capabilities, the EAP method versions supported by end points must be updated. In certain circumstances, the capabilities of the outer EAP method may need to be updated. However, in many instances the EAP outer method cannot be updated because a programmer does not have access to the source code or the updates would require changes to the EAP standard, which can be difficult and time consuming. It is with respect to this general environment that embodiments of the present disclosure have been contemplated.
Embodiments of the present disclosure relate to systems and methods for performing capability negotiation with Extensible Authentication Protocol (“EAP”) methods used with tunneling EAP methods. One example tunneling EAP method is Protected Extensible Authentication (“PEAP”). Embodiments of the present disclosure are illustrated with respect to PEAP; however, one of skill in the art will appreciate that the methods and systems disclosed herein are applicable to any type of tunneling EAP methods. Embodiments of the present invention relate to providing a number of EAP methods for negotiating capabilities supported by the end points involved in an EAP tunneling transaction, such as a PEAP transaction. After the establishment of the outer tunnel, a sender generates an EAP capability negotiation method that is used during the negotiation of the inner EAP method. The EAP capability negotiation method relates to a specific capability. For example, the capability negotiation method may relate to a fragmentation capability. The sender initiates the capability negotiation method and sends a request to the receiver to perform the negotiated capability. If the receiver supports the negotiated capability, it may respond by performing the negotiated capability or by sending an acknowledgement indicating the ability to perform the negotiated capability. If the receiver does not support the negotiated capability, for example, the version of the outer method supported by the receiver does not support a desired capability, it may respond with a negative acknowledgment (“NAK”) listing EAP capability methods that it supports. The sender uses the NAK to determine that the receiver does not support the negotiated capability and also as an indication of which capabilities are supported by the receiver.
In another embodiment, the sender may perform the negotiated capability even though the secure outer tunnel created by the outer method does not support the negotiated capability. In embodiments, the sender may generate a wrapper inner EAP method that is compatible with the receiver's EAP capability. The wrapper inner EAP method acts as a tunnel within the outer EAP method to perform capabilities not supported by the outer method that the receiver employs. For example, if a receiver's outer method does not support the chaining of multiple authentication methods, the sender may generate a wrapper inner EAP method which is compliant with the capability supported by the receiver's outer method. The sender may then chain multiple authentication methods within the wrapper inner EAP method.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Embodiments of the present disclosure may be more readily described by reference to the accompanying drawings in which like numbers refer to like items and in which:
This disclosure will now more fully describe exemplary embodiments with reference to the accompanying drawings, in which some of the possible embodiments are shown. Other aspects, however, may be embodied in many different forms and the inclusion of specific embodiments in the disclosure should not be construed as limiting such aspects to the embodiments set forth herein. Rather, the embodiments depicted in the drawings are included to provide a disclosure that is thorough and complete and which fully conveys the intended scope to those skilled in the art. When referring to the figures, like structures and elements shown throughout are indicated with like reference numerals.
Embodiments of the present invention relate to determining capabilities supported by a receiver involved in a tunneling EAP transaction. Although specific embodiments are illustrated with respect to PEAP, one of skill in the art will appreciate that the use of PEAP is for illustrative purposes only and that the disclose systems and methods are operable with any tunneling EAP methods. After creating a secure tunnel between a sender and a receiver, the sender initiates an EAP capability negotiation method. In embodiments, the capability negotiation method relates to a specific capability. For example, the capability negotiation method may relate to fragmentation. The sender uses the capability negotiation method to send a request to the receiver to perform the negotiated capability. If the receiver supports the negotiated capability, it may respond by performing the capability. If the receiver does not support the negotiated capability, it may respond with a NAK. The sender uses the NAK to determine that the receiver does not support the negotiated capability. In another example, the capability negotiation method may relate to negotiating the specific capabilities of an outer method employed by one of the parties to an EAP transaction. One of skill in the art will appreciate that while particular illustrations may describe the capability negotiation as determining the specific capabilities of a device involved in a PEAP transaction, the capabilities of the device depends upon the capabilities of the EAP methods employed by the device.
The use of the capability negotiation method provides a safe approach to detecting whether a device involved in a PEAP transaction supports a capability. Because both parties to the PEAP transaction are compliant with the EAP standard, the capability negotiation method may be used to detect the capabilities of one of the devices without the possibility that the negotiation will cause the devices to choke, crash, or misbehave. Additionally, the EAP capability negotiation method allows for the detection of capabilities without having to change the protocol version number or using reserved bits defined by the protocol. This ensures that any added capabilities will not conflict with future versions of the protocol which may define different uses for the reserved bits.
Turning now to the figures,
If the client 12 is able to perform the desired capability, the client 12 responds with communication 20. In one embodiment, communication 20 may be an acknowledgment that the client 12 supports the desired capability. In yet another embodiment, communication 20 may include additional negotiation packets to define the specific parameters to be employed in performing the desired capability. For example, if the server 14 desires to apply fragmentation, client 12 may respond with communication 20 by detailing instructions and/or parameters regarding the capability, e.g., maximum size of a fragment, or any other detail related to fragmentation. One of skill in the art will appreciate that in other embodiments, the parameters will relate to other types of capabilities that are being negotiated using the additional negotiation packets.
If the client 12 is unable to perform the desired capability, the client 12 responds with a Negative Acknowledgment (“NAK”), as illustrated by communication 22. The NAK of communication 22 may contain a list of capabilities supported by the client 12. In such embodiments, server 14 may use the list to determine which capabilities are supported by client 12 and may use these capabilities to complete the PEAP transaction. In some embodiments, the NAK contains only a partial list of capabilities that client 12 supports. In those embodiments, the server 14 cannot determine all of the capabilities supported by the client 12 by examining the NAK; however, the server 14 can still determine that client 12 does not support the desired capability.
Referring now to
Flow proceeds to operation 204 where the sending device sends an EAP request to a receiver. The EAP request may be a request to utilize a specific capability. In another embodiment, the request may simply be used to verify that the receiver is capable of performing the specific capability. In such embodiments, the request may take the form of an empty request. For example, the request may simply specify that fragmentation is desired. In other embodiments, the request may consist of more complex instructions. For example, referring to the fragmentation example, the request may also perform further functionality, such as negotiating maximum fragment size, etc. While the above examples relate to fragmentation capabilities, one of skill in the art will appreciate that any other type of capability may be negotiated.
Flow then proceeds to operation 206, where the sender receives a response from the receiver. At operation 208, the sender determines whether the response is a negative acknowledgment (“NAK”) from the receiver. If at operation 208, a determination is made that the response is not a NAK, flow proceeds to operation 210, where the PEAP transaction is completed using the capability negotiated. However, if at operation 208 a determination is made that the response is a NAK indicating that the receiver does not support the requested capability, then it may be necessary to discover what capabilities the receiver supports in order to complete the PEAP transaction. Accordingly, at operation 212 the sender determines the capabilities of the receiver. In one embodiment, the sender determines the capabilities of the receiver by sending multiple requests to the receiver until the receiver performs a requested capability or sends a response indicating that a capability is supported. In another embodiment, the NAK lists the capabilities supported by the receiver. In such an embodiment, the sender determines the supported capabilities of the receiver by examining the NAK. In other embodiments, the NAK may contain a partial list of capabilities that the receiver supports. In such situations, the sender cannot determine all of the capabilities supported by the receiver by examining the NAK; however, the sender can still determine that the receiver does not support the desired capability. Once the sending device determines the supported capabilities of the receiver that are compatible with the capabilities of the sender, flow proceeds to operation 214, where the PEAP transaction is completed using capabilities supported by both the sender and receiver.
Referring now to
Flow proceeds to decision operation 304, where the receiver determines whether or not it supports the desired capability. In embodiments, the receiver may support the capability. For example, the receiver may be using the same version of an EAP protocol as the sender requesting the capability. In other embodiments, the receiver may be using a different version of the protocol than is being used by the sender; however the version used by the receiver may still support the desired capability. In embodiments, if the receiver supports the desired capability, upon receiving the capability negotiation method the receiver understands the capability negotiation method (e.g., the receiver recognizes the desired capability requested in the capability negotiation or recognizes that the capability negotiation method is requesting the desired capability). If the receiver supports the capability, flow branches YES to operation 306, wherein the receiver performs the desired capability. In another embodiment, the receiver responds with a message for negotiating specific parameters of the desired capability. For example, the receiver may respond with a message specifying packet size, number of packets, etc. if the desired capability is fragmentation.
If the receiver does not support the desired capability, then, in embodiments, it will not understand the capability negotiation method request. In other embodiments, the receiver may understand the capability negotiation method request; however the receiver may not support the desired capability. In such embodiments, flow branches NO to operation 308. At operation 308, the receiver responds to the request with a negative acknowledgement (“NAK”). In embodiments, the receiver responds with a Legacy NAK or an Expanded NAK. In other embodiments, the NAK lists the capabilities supported by the device. In such embodiments, the list may contain a complete list of supported capabilities or a partial list of supported capabilities.
In embodiments, the methods detailed in
In another embodiment, a sender may perform a capability even though the outer method employed in the PEAP transaction does not support the capability. In embodiments, the sender may generate an inner wrapper EAP method that is compatible with the outer method. The wrapper method acts as a tunnel within the inner EAP method to perform a capability not supported by the outer method. For example, if the outer method employed in a PEAP transaction does not support the chaining of multiple authentication methods, the sender may generate a wrapper method which is compliant with the capability supported by the outer method. The sender may then chain multiple authentication methods within the wrapper method.
Referring now to
Referring now to
Flow proceeds to operation 504, where the sender determines that the outer method does not support the chaining of multiple EAP methods. This may be done, for example, by using the methods described with respect to
Flow proceeds to operation 506, where an inner wrapper method is initiated. In embodiments, the inner wrapper method is initiated according to the method detailed with respect to
Flow proceeds to operation 508, where multiple inner EAP methods are initiated. In embodiments, these methods may be used to perform authentication. In other embodiments, the multiple inner EAP methods may be used to perform other functions, e.g., fragmentation. In embodiments, the multiple inner EAP methods are generated such that they can be chained together in a PEAP transaction. While the illustrated embodiment describes initiating the wrapper method before initiating the multiple inner methods, one of skill in the art will readily appreciate that these methods may be initiated in any order
Flow then proceeds to operation 510, where the multiple inner EAP methods are chained together. In one embodiment, the multiple inner EAP methods may be chained by the inner wrapper method. In another embodiment, the multiple inner EAP methods may be chained by a a different method or process. The chaining of the multiple inner EAP methods has been described as a discreet step for illustrative purposes. One of skill in the art will appreciate that the multiple inner EAP methods may be simultaneously chained as they are transported by the inner wrapper method, as is described with respect to operation 512.
Flow then proceeds to operation 512 where the chained multiple inner EAP methods are transported inside the inner wrapper method. In embodiments, the inner wrapper method completely manages the chained inner methods. For example, the inner wrapper method may supply the chained inner methods with any data or functions needed for the chained methods to be performed. In other embodiments, the inner wrapper method may also perform the chaining of the multiple inner EAP methods, as described in operation 510. As described with respect to
One of skill in the art will appreciate that the embodiments described with respect to
Flow proceeds to decision operation 606. At operation 606, a determination is made as to whether or not the outer method in the PEAP transaction supports the desired capabilities. If the desired capabilities are supported, flow branches YES to operation 608, where the PEAP transaction is completed using the desired capabilities. If the desired capabilities are not supported by the outer method in the PEAP transaction, flow branches NO to decision operation 610.
At decision operation 610, a determination is made as to whether or not the inner method in the PEAP transaction supports the desired capability. In embodiments, the capabilities of the inner method may be determined using the capabilities negotiation method described with respect to
If the inner method supports the desired capability, flow branches YES to operation 612. At operation 612, one end point requesting a specific capability generates a inner wrapper method. As described with respect to
Referring again to decision operation 610, if the inner method does not support the desired capability, flow branches NO to operation 618. At operation 618, the PEAP transaction may be completed using the capabilities supported by the inner and outer EAP methods employed in the PEAP transaction instead of the desired capabilities. In other embodiments, the PEAP transaction may fail at operation 618. Using the disclosed methods, end points are able to negotiate the capabilities supported by the inner and outer methods in PEAP transactions. If a desired capability is not supported by the outer method employed by the PEAP transaction, the disclosed methods provide for performing the desired capabilities within a compatible inner wrapper method. While embodiments of the present disclosure have been illustrated with respect to PEAP, one of skill in the art will appreciate that the methods and systems disclosed herein are applicable to any type of EAP tunneling methods.
With reference to
In its most basic configuration, computer system 700 comprises at least one processing unit or processor 704 and system memory 706. The most basic configuration of the computer system 700 is illustrated in
Additionally, computer system 700 may also have additional features/functionality. For example, computer system 700 includes additional storage media 708, such as removable and/or non-removable storage, including, but not limited to, magnetic or optical disks or tape. In some embodiments, software or executable code and any data used for the described system is permanently stored in storage media 708. Storage media 708 includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. In embodiments, the capability negotiation methods and wrapper inner methods are stored in storage media 708.
System memory 706 and storage media 708 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (“DVD”) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, other magnetic storage devices, or any other medium which is used to store the desired information and which is accessed by computer system 700 and processor 704. Any such computer storage media may be part of computer system 700. In some embodiments, mammogram images and/or results of probability determination are stored in system memory 706. In embodiments, system memory 706 and/or storage media 708 stores data used to perform the methods or form the system(s) disclosed herein, such as generating well-defined messages, expressing a collective intent of security semantics, accepting and/or rejecting well-defined messages, etc. In embodiments, system memory 706 would store information such as EAP methods 714 and generation instructions 716. In embodiments, EAP methods 714 may be general EAP methods, capability negotiation methods, wrapper inner methods, or any other type of EAP methods. Generation instructions 716, in embodiments, store the instructions necessary to generate the EAP methods and/or perform the disclosed methods and systems. For example, generation instructions 716 may include functions or processes for generating a capability negotiation method, generating a wrapper inner method, etc.
Computer system 700 may also contain communications connection(s) 710 that allow the device to communicate with other devices. In embodiments, communications connection(s) 710 may be used to transmit and receive messages between sender devices, intermediary devices, and recipient devices. Communication connection(s) 710 is an example of communication media. Communication media may embody a modulated data signal, such as a carrier wave or other transport mechanism and includes any information delivery media, which may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information or a message in the data signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as an acoustic, RF, infrared, and other wireless media. In an embodiment, EAP methods may be transmitted over the communication connection(s) 710.
In some embodiments, computer system 700 also includes input and output connections 712, and interfaces and peripheral devices, such as a graphical user interface. Input device(s) are also referred to as user interface selection devices and include, but are not limited to, a keyboard, a mouse, a pen, a voice input device, a touch input device, etc. Output device(s) are also referred to as displays and include, but are not limited to, cathode ray tube displays, plasma screen displays, liquid crystal screen displays, speakers, printers, etc. These devices, either individually or in combination, connected to input and output connections 712 are used to display the information as described herein. All these devices are well known in the art and need not be discussed at length here.
In some embodiments, the component described herein comprise such modules or instructions executable by computer system 700 that may be stored on computer storage medium and other tangible mediums and transmitted in communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Combinations of any of the above should also be included within the scope of readable media. In some embodiments, computer system 700 is part of a network that stores data in remote storage media for use by the computer system 700.
This disclosure described some embodiments of the present disclosure with reference to the accompanying drawings, in which only some of the possible embodiments were shown. Other aspects may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments were provided so that this disclosure was thorough and complete and fully conveyed the scope of the possible embodiments to those skilled in the art.
Although the embodiments have been described in language specific to structural features, methodological acts, and computer-readable media containing such acts, it is to be understood that the possible embodiments, as defined in the appended claims, are not necessarily limited to the specific structure, acts, or media described. One skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present disclosure. Therefore, the specific structure, acts, or media are disclosed only as illustrative embodiments. The disclosure is defined by the appended claims.