Project Topics
Get Complete Project Material File(s) Now! »
Asymmetric cryptographic keys
Asymmetric keys, also known as public/private keys, are the strength of many security systems. HTTPS use them to exchange the encryption key between a client and the server, SSH on the other hand can perform a client authentication based on its public key. Both of these examples are based on the same property: data encrypted by a key can be decrypted using its counterpart. Keys are generated by a generator with a random seed: G(seed) = (Kpriv , Kpub) (1.2).
According to their names, the private key Kpriv must be kept secret whereas the public key Kpub can be disclosed safely to others. Given an encryption algorithm A which takes a key and a data payload to encrypt it and its reverse form A′ which takes a key and encrypted data to decrypt it, the following properties exist between the two keys: A(K, data) = C (1.3).
Authentication protocols for access con-trol
In the previous section, multiple authentication methods were presented. It allowed the understanding of the different mechanisms and keying mate-rials needed to verify a user’s identity. This sections focuses on presenting the various network protocols to transport user authentications. Figure 1.4 describes a general view of a private network where users need to au-thenticate. From left to right, the user device communicates with a border controller which communicates with an authentication server. Typically, the border controller is in charge of controlling the user traffic by decid-ing whether to forward its traffic or not. It uses cross-layer information to build custom rules per device. This border controller uses the authentica-tion server to decide if a user is authorized to access the network. As a result, two kinds of protocols are presented in this section: from the user device to the border controller and from the border controller to the authentication servers.
Lightweight Directory Access Protocol
LDAP is an applicative protocol to access and manage information di-rectory services over the network. It is specified by the IETF as multiple RFCs. The latest one defines the Version 3 in the RFC 4511 [44]. LDAP uses either TCP or UDP as transport layer on port 389 with no encryption, or port 636 with TLS encryption.
Information directories store data according to their directory schema. This schema defines the data structure with a number of elements per object:
— Attribute syntax – defines what information can be stored in an attribute.
— Matching rules – defines how to compare the attribute values.
— Object classes – defines a set of required and optional attributes identified by a unique name. Data is stored in the entry’s attributes. Each entry has at least an Object class which tells what kind of object it represents and how clients may interact with them. Clients can access the server schema to learn about the elements’ structure as well as the hierarchy of entries. Entries are identified by a distinguished name called dn, it is neither an attribute nor part of the entry. The dn contains a common name (e.g. John Doe) plus the dn of its parent entry.
For example, a user can be represented by the person object class. Its common name is “John Doe”and it is part of the example.com provider. Hence its dn can be represented as: dn: cn=John Doe,dc=example,dc=com.
The person class requires no attribute itself but inherits from the top object class, a special abstract class, forcing the definition of the object class attribute. The person object class defines optional attributes including the userPassword, telephoneNumber or description.
Clients access the directory server using a set of operations: add, search, delete, modify, bind. . . When a session starts, the bind operation allows the user to authenticate against the directory. The simple bind uses the user’s dn as well as its password in plain text to check if the userPassword entry matches. Such operation should be encrypted to avoid eavesdropping. A wider range of authentication mechanisms is provided by the Simple Au-thentication and Security Layer bind such as Kerberos [41] authentication or TLS authentication using certificates. Once the client is bound to the directory, he has access to a subtree corresponding to his identity. Further-more, he gains the rights to use (or not) other operations. Leveraging the bind mechanism in addition to the information structure makes LDAP a great tool to manage users in a guest access environment. After users being authenticated against the directory, they have only ac-cess to their information. Furthermore, the network topology including incoming networks, zone definition, network services can be stored in that directory allowing the retrieval of key information for each user.
Controller side implementation
In order to provide good user experience, ease of integration with new vendors and secure filtering, some developments have to be done on the controller side. This section first presents the implementation details 2.3.1 regarding the vendor model which represents each vendor’s specificity, then the implementation of the user pre-authentication 2.3.2 with the gathering of its device information is presented.
Adapting to each vendor
The proposed solution to adapt to each vendor is a model representing each attribute sent inside the redirection URL as well as the HTTP request to authenticate and disconnect a user on the border controller. Among the long list of languages which can fulfill this task, including JSON and YAML, XML seems to be a good candidate because it can be parsed by lots of programming languages and platforms and is easy to write by non-programmers. This choice is somehow arbitrary as other languages would also do the job. Hence the model presented here is translatable if needed.
The list of attributes sent in the redirection URL is represented by a list of XML tags. The tag’s name identifies the attribute’s role, for instance the <USER_IP> tag describes the attribute containing the user’s IP address. Each tag has a number of child tags to describe it. The only mandatory attribute is its key in the URL to extract the value. Optionally, the attribute’s type can be defined as well as its default value in the event where the attribute is missing. Here is an example of the Xirrus vendor to represent the border controller’s IP address on which the authentication request should be sent:
<HOST>.
<type>i p _ a d d r e s s</ type>.
<v a l u e>uamip</ v a l u e>.
<default> 1 8 5 . 0 . 0 . 1</ default> </HOST>.
In the process of retrieving the attributes of a specific vendor from a URL, the first step is to identify the vendor. To do so, the model uses a list of attribute’s keys along with the logical operator AND or OR. This list has to uniquely identify one and only one vendor because this infers the way of building the authentication URL which would break things if the vendor is not correctly recognized. To match the vendor, the attributes on the list has to be verified in the URL. For instance, looking at the Xirrus vendor again, its list contains only two attributes: uamip and uamport, with the AND operator. This means that both attributes must be present in the URL to identify the Xirrus vendor. The last part of the model describes how to construct the authentication and de-authentication HTTP requests. A different tag is used to describe each one as they may widely differ. First of all, a quick reminder on how HTTP requests are built is required. The simpler method, GET, uses the URL to transmit parameters to the HTTP server. The URL also holds information about the server to targeted as well as the protocol to access it. Figure 2.2 presents a general URL split into different sections from left to right: the protocol, either HTTP or HTTPS, the server’s host name or IP address, the path which is a document identifier on the server and finally the list of parameters. The other method, named POST, uses the request body to send its parameters list. The URL no longer includes them which is sometimes valuable because web browsers display it to users. When using the POST method, users will not directly see what information were sent to the server including their password for instance, though it does not strengthen security.
The URL representation defines the HTTP method to use (GET or POST), the protocol (HTTP or HTTPS) which depends on information sent by the border controller, how to build the server’s host name, the URI and the list of parameters to include in the request. Regarding the host name, it is extracted from the user redirection where the border controller tells either its IP address or host name and TCP port on which it is listening on. The parameters list usually includes the user’s login and password but can also embed a token sent by the border controller or a URL to redirect the user to after the operation is completed.
With its simplicity and its flexibility, the proposed model elegantly solves the vendor adaptation. It centralizes the specificities of every hard-ware in one place leaving the source code vendor independent. This is a highly valuable characteristic when increasing the number of supported equipments. Furthermore, it has little to no impact on performance as it only defines attribute names and URL structures, it does not increase the remote controller’s workload.
Improving user experience and data gathering
Currently, the implementation allows end-users to get a remote captive portal, authenticate against their local border controller and disconnect from it. This minimal set of features is enough to control users in a private network. Though functional, it is not user friendly enough. Indeed in the event where the authentication request is rejected, it is difficult to provide the right feedback to the user about the triggered error. Because the border controller performs the authentication request using the RADIUS protocol, only a yes/no answer, including an optional reason message is sent back by the server. This reason message is by no mean self explanatory for every-body: foreign language, technical information or error codes. That is why the captive portal should be the one to display a comprehensive feedback understandable by a multitude of people. Section 2.2.3 also outlined that border controllers do not always send the RADIUS reason message when authentication fails leaving the captive portal powerless to display anything but a generic error.
Implementing a user pre-authentication prior to building the HTTP request to post user’s credentials on the border controller addresses this limitation. Indeed the captive portal is able to trigger an authentication without starting a new session and able to retrieve the resulting error code. Depending on it, the portal can send the proper feedback to the user and prevent the border controller from triggering an authentication request which will fail. Figure 2.3 is an updated version of the interactions between the border and the remote controllers. The pre-authentication is done right after the user sends its credentials to the captive portal.
Moreover, the pre-authentication is a great opportunity to implement the BYOD filtering. As only the captive portal is able to retrieve these information from the User-Agent attribute, it is the only place where they can be checked and stored if needed. The enhanced implementation uses the captive portal in order to fulfill to BYOD filtering as well as storing these information into the session database so they are available for reporting and statistics.
Table of contents :
Introduction
1 Access control in private networks
1.1 Authentication
1.1.1 Identity management
1.1.2 Password
1.1.3 Asymmetric cryptographic keys
1.1.4 Digital certificate
1.1.5 SIM
1.1.6 Summary
1.2 Authentication protocols for access control
1.2.1 Device to access network
1.2.2 Authenticator to authentication server
1.2.3 Summary
1.3 Flow control
1.3.1 Hierarchy of protocols
1.3.2 Basic firewalling
1.3.3 Deep packet inspection
1.3.4 URLs filtering
1.3.5 Lawful obligation
1.4 Summary
2 A mutualized approach
2.1 Motivations
2.2 Proposed architecture
2.2.1 Local equipment
2.2.2 Remote controller
2.2.3 Technical challenges
2.3 Controller side implementation
2.3.1 Adapting to each vendor
2.3.2 Improving user experience and data gathering
2.4 Summary
3 An SDN approach
3.1 Discussion
3.2 OpenFlow
3.2.1 Protocol overview
3.2.2 Packet matching
3.2.3 Limitations
3.3 Proposal to overcome OpenFlow limitations
3.4 OpenFlow network tunnel
3.4.1 TCP analysis
3.4.2 Packets handling
3.4.3 Performance measurements
3.5 Captive portal implementation
3.5.1 Traffic redirection
3.5.2 Web server
3.5.3 OpenFlow controller
3.5.4 Dealing with TCP
3.5.5 Performance
3.5.6 Summary
Conclusion and Perspectives
A Dealing with over sized packets
List of Figures
List of Tables
Bibliography
