Authentication infrastructure for IP phones of a proprietary TOIP system by an open EAP-TLS system

Abstract

The infrastructure according to the invention includes: a proprietary TOIP system including a call server connected to the network, integrating a certification module able to certify an IP telephone; an external certification architecture able to certify the certification module of the call server; an EAP-TLS authentication system including a RADIUS server and a directory server, the RADIUS server including a rule for verifying certificates consisting of verifying the entire certification chain formed by the certification of the IP telephone by the certification module of the call server and the certification of the certification module of the call server by the external certification architecture, the directory server including a user account for each IP telephone authorized to access the network and a match table associating a signature of the certificate of the corresponding IP telephone with each username of a user account.

Claims

1. An infrastructure for authenticating an IP telephone of a proprietary IP telephony system by means of an open EAP-TLS authentication system, in order to authorize said IP telephone to access an IP network, wherein said infrastructure includes: the proprietary IP telephony system including a call server connected to the IP network, integrating a certification module for generating an authenticating proprietary certificate for an IP telephone; an external certification architecture for signing a certification request from the certification module of the call server so as to obtain a certificate for the certification module; the EAP-TLS authentication system including a RADIUS server and a directory server, the RADIUS server including a rule for verifying certificates consisting of verifying the entire certification chain formed by the certification of said IP telephone by the certification module of the call server and the certification of the certification module of the call server by the external certification architecture, the directory server including a user account for each IP telephone authorized to access the IP network and a match table associating a signature of the certificate of the corresponding IP telephone with each username of the user account.

2. The infrastructure according to claim 1, wherein the external certification architecture modifies attributes of the certificate request from the certification module of the call server, before signing the modified certificate request, the modified certificate obtained being compatible both with the proprietary IP telephony system and the EAP-TLS authentication system.

3. The infrastructure according to claim 1, wherein the RADIUS server performs a dynamic matching between a proprietary username of an IP telephone, indicated in the certificate received from an IP telephone to be authenticated, and a username of the IP telephone indicated in the user account corresponding to said IP telephone in the directory server.

4. The infrastructure according to claim 1, wherein the open EAP-TLS authentication system is a Network Policy Server (NPS) system, integrating a NPS RADIUS server.

5. The infrastructure according to claim 4, wherein the NPS system is combined with an Active Directory server.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The invention and its advantages will be better understood upon reading the following detailed description of one particular embodiment, provided solely as a non-limiting example, this description being done in reference to the appended drawings, in which:

(2) FIG. 1 is a diagrammatic illustration of one embodiment of the infrastructure according to the invention;

(3) FIG. 2 is a diagrammatic illustration of the steps of a method for configuring the infrastructure of FIG. 1; and

(4) FIG. 3 is a diagrammatic illustration of the steps of a method for using the infrastructure of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

(5) Structure of the Infrastructure

(6) In reference to FIG. 1, an infrastructure 10 associating a proprietary TOIP system and an open EAP-TLS authentication system is shown.

(7) The infrastructure 10 has, as support, an IP network 12 belonging to an organization, such as a company.

(8) The infrastructure 10 includes a TOIP system 20, an EAP-TLS authentication system 30 and a PKI architecture 40.

(9) The TOIP system 20 is a proprietary system. It is in particular a CICSO TOIP system.

(10) It includes a plurality of IP telephones 22, only one of which is shown in FIG. 1.

(11) The IP telephone 22 is connected to the local IP network by an access point 14.

(12) The TOIP system 20 also includes a call server 24, connected to the IP network 12.

(13) The call server 24 of the Cisco TOIP system includes a module, called CAPF (Certificate Authority Proxy Function) module, referenced 25 in FIG. 1. The CAPF module 25 constitutes of a PKI architecture for the Cisco TOIP system 20, able to generate Cisco certificates for IP telephones 22.

(14) A certificate request for an IP telephone 22 can only be generated by the CAPF module 25, such that the values of the attributes contained in the certificate request and consequently in the final certificate allow the operation of the telephone 22 with the call server 24. The models for Cisco certificate requests cannot be modified. They are imposed by Cisco. These models may optionally be different depending on the version of the IP telephone 22 to be certified.

(15) A certificate request can only be signed by the certification authority for the CAPF module 25.

(16) The EAP-TLS authentication system 30 is an open system. It in particular involves the NPS system by Microsoft.

(17) Its purpose is to implement, for each IP telephone 22, an authentication according to standard IEEE 802.1x EAP-TLS when this IP telephone connects to a control port of an access point 14.

(18) The EAP-TLS authentication system 30 includes a RADIUS server 32, in particular the NPS RADIUS server by Microsoft, connected to the IP network 12.

(19) The EAP-TLS authentication system 30 includes a directory server 34, in particular the Active Directory server by Microsoft.

(20) The directory server includes, for each user authorized to access the IP network 12, a user account 35, in particular including a username, and a match table T associating each username of an account with a signature of a certificate for that user.

(21) The external PKI architecture 40 is shown diagrammatically by the server 41 in FIG. 1. The server 41 may be on or off the IP network 12, optionally with no direct communication link with the IP network 12. For example, the external PKI architecture 40 is the solution provided by the company Thales.

(22) The external PKI architecture 40 includes a certification authority 42 for the certificate requests it receives. This certification authority.

(23) Configuration of the Infrastructure

(24) The method 100 for configuring the infrastructure described above is illustrated in the diagram in FIG. 2.

(25) In step 110, in order to increase the access security of the IP network 12, using the PKI architecture 40, a certificate request is generated for the CAPF module 25 of the call server 24, then signed by the certification authority 42 of the external PKI architecture 40, so as to obtain a certificate for the CAPF module 25.

(26) The certificate request for the CAPF module 25 of the call server 24 is generated by the CAPF module 25 itself.

(27) In order for the certificate for the CAPF module 25 to be able to be used both by the Cisco TOIP system 20 and the Microsoft NPS authentication system 35, it is necessary to modify the certificate request generated for the CAPF module 25. Indeed, some values of the attributes present in the certificate request generated for the CAPF module 25, and by the CAPF module 25, are incorrectly interpreted by the Cisco system and/or the Microsoft system.

(28) To that end, a script is integrated in the external PKI architecture so as to generate, from the certificate request for the CAPF module 25, a modified certificate request for the CAPF module 25. This script makes it possible to select values compatible with the requirements of the Cisco and NPS systems for the attributes of the certificate request for the CAPF module 25. Once signed by the PKI architecture 40, a modified certificate for the CAPF module 25 is issued and injected on the call server 24.

(29) The certificate for the CAPF module 25 in particular make it possible to create a certification chain: a Cisco IP telephone is certified by a Cisco certificate generated by the CAPF module 25, and the CAPF module 25 is certified by a certificate generated by an external PKI architecture.

(30) In step 115, the configuration includes generating a Cisco certificate request for each IP telephone 22 by using the CAPF module 25. The latter signs the Cisco certificate request so as to obtain a Cisco certificate that is stored on the corresponding IP telephone. A Cisco certificate in particular includes a username included on at least 19 characters, i.e., a long username LUserName.

(31) In step 120, the configuration method continues by creating rules in the NPS RADIUS server.

(32) First rules, called network strategy rules, make it possible to perform verifications of a set of conditions, constraints and parameters seeking to authorize an IP telephone to connect to the network and define the circumstances under which this IP telephone can connect.

(33) In particular, the NPS RADIUS server is configured so as to modify a first rule relative to the verification of the certification authority having granted the Cisco certificate for the IP telephone 22. This rule makes it possible to extract, from the Cisco certificate of the IP telephone 22, the name of the authentication authority, i.e., of the CAPF module 25; then to verify the certificate of the CAPF module 25, i.e., the certificate issued by the PKI architecture 40. The verification rule for the certification authority makes it possible to verify the certification chain.

(34) Other first rules are configured on the NPS RADIUS server to verify the validity date of the Cisco certificate, the functionalities associated with the Cisco certificate, etc., or to verify the existence of a user account (by querying the directory server), or the fact that the IP telephone actually connects in the EAP-TLS, etc.

(35) The configuration includes step 130 for creating, on the Active Directory server 34, a user account for each IP telephone to be authenticated. This involves associating a username SUserName with each IP telephone.

(36) The username SUserName in the Microsoft Active Directory server 34 is limited to 15 characters. An IP telephone is therefore identified therein by a short username.

(37) However, according to the model of the Cisco certificates, the username of the IP telephone 22 can only be a long username LUserName.

(38) The NPS RADIUS server must therefore be able, from the long username of the Cisco certificate received from an IP telephone 22 seeking to be authenticated, to create a query request from the directory server 34 using the short username.

(39) To that end, in step 135, the RADIUS server is configured by creating second rules, called connection request strategy rules, which define conditions and parameters making it possible to designate the server that must perform a task, associated with the message sent by a particular IP telephone 22, such as the authentication of that IP telephone.

(40) In particular, the NPS RADIUS server is configured so as to create a second rule able to dynamically convert the long username LUserName into a short username SUserName. For example, the short name corresponds to the first 15 characters of the long name, such that the dynamic transformation done by the RADIUS server is an operation truncating the long name present in the received certificate.

(41) In step 140, it is lastly necessary to create, in the Active Directory server 34, a match table making it possible to connect the short username SUserName with a signature of the Cisco certificate, such that the directory server can respond to a request from the NPS RADIUS server 32 to verify the identity of the Cisco certificate.

(42) This step therefore includes creating a signature for each certified IP telephone 22 and creating the short username/signature of the Cisco certificate match table.

(43) The configuration steps described above can be done in a different order.

(44) Operation of the Infrastructure

(45) The authentication method, according to standard IEEE 802.1x, is then as follows once the IP telephone 22 is connected to a port of the access point 14: in step 201, the IP telephone 22, as EAP client, sends an EAP initialization message to the access point 14, as EAP server; in step 202, the access point 14 responds by sending an identity request EAP message to the IP telephone 22; in step 203, the IP telephone 22 sends its username LUserName in a response EAP message to the access point 14; in step 204, the access point 14 sends its username LUserName to the NPS RADIUS server 32, in an access request according to a particular client/server AAA protocol, the access point 14 then operating as client of the AAA protocol; in step 205, the NPS RADIUS server 32 responds to the access point 14 by sending it its certificate of the NPS RADIUS server (for example, created by the external PKI architecture 40); in step 206, the access point 14 sends the certificate for the NPS RADIUS server to the IP telephone 22; in step 208, the IP telephone 22 responds by sending its Cisco certificate to the in step 207, the IP telephone 22 validates the NPS RADIUS server certificate; access point 14; in step 209, the access point 14 sends the Cisco certificate to the NPS RADIUS server; in step 210, the NPS RADIUS server reads the username LUserName in the Cisco certificate and dynamically truncates the username LUserName to obtain the short username SUserName; in step 211, the NPS RADIUS server sends the short name SUserName and the Cisco certificate to the Active Directory server 34; in step 212, the directory server 34 verifies that a user account corresponds to the short username SUserName; if yes, in step 213, the directory server 34 extracts the certificate signature associated with the short username SUserName from the table T, produces a signature of the Cisco certificate received from the NPS RADIUS server, and compares it to the certificate signature extracted from the table T; if there is a match, in step 214, the directory server 34 sends the NPS RADIUS server an identification confirmation for the IP telephone 22; in step 215, the NPS RADIUS server then continues the verification of the Cisco certificate in particular by applying the verification rule of the certification chain to it; then, if the NPS RADIUS server validates the Cisco certificate of the IP telephone 22, in step 216, a WEP encryption key is negotiated between the NPS RADIUS server and the IP telephone 22 via the access point 14; in step 217, the NPS RADIUS server sends the access point 14 an AAA acceptance message of the connection, indicating a successful authentication, the AAA acceptance message containing the WEP key; in step 218, the access point 14 sends the IP telephone an EAP success message; in step 219, the access point 14 sends the IP telephone 22 a public encryption key and a public encryption key length, encrypted with the WEP key.

(46) The IP telephone 22 can thus access the IP network 12, and in particular connect (step 220) to the Cisco call server 24 by establishing a secure TLS connection with the latter, the modified Cisco certificate of the IP telephone 22 again being used during this step.

(47) It is thus possible, using the Microsoft NPS system, to authenticate the Cisco IP telephones, with a same certificate that is compatible between the Cisco TOIP component and the Microsoft authentication component.

(48) This solution makes it possible to increase security by using a certification authority other than the default authority of the Cisco TOIP system.

(49) This solution therefore allows independence with respect to the Cisco tools, both for the Cisco certification tools and the Cisco authentication tools.

(50) In this solution, the authentication of all of the equipment of the company, IP telephones and computers, is centralized on the same Microsoft server or set of servers.

(51) It is possible to use the Microsoft TOIP system in combination with the Cisco TOIP system. Indeed, the latter works naturally with the Microsoft NPS authentication system. The network is thus secured by using a single type of authentication system.

(52) If there is a Microsoft authentication system already in place, this solution makes it possible not to modify the authentication system when Cisco IP telephones are deployed. Without the solution, it would not be possible to secure access to the network by the Cisco IP telephones. It would be necessary to establish the Cisco RADIUS ISE server in place of the Microsoft RADUIS NPS server, and consequently, to change the infrastructure as a whole.

(53) Theoretically, according to the Cisco documentation, the Cisco TOIP system supports the use of certificates signed by an external certification authority.

(54) Furthermore, no contraindication is mentioned regarding the possibility of using the Cisco certificates in an EAP-TLS authentication system, in particular the Microsoft NPS system.

(55) However, during tests, compatibility limitations have been observed during analysis by the EAP-TLS authentication system of the Cisco certificates.

(56) Thus, IEEE 802.1X authentication of the Cisco IP telephones with a Cisco certificate is not possible in the Microsoft NPS authentication system.