EP1891771A1 - Procede de traduction d'un protocole d'authentification - Google Patents

Procede de traduction d'un protocole d'authentification

Info

Publication number
EP1891771A1
EP1891771A1 EP06764849A EP06764849A EP1891771A1 EP 1891771 A1 EP1891771 A1 EP 1891771A1 EP 06764849 A EP06764849 A EP 06764849A EP 06764849 A EP06764849 A EP 06764849A EP 1891771 A1 EP1891771 A1 EP 1891771A1
Authority
EP
European Patent Office
Prior art keywords
authentication
challenge
protocol
peer
eap
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06764849A
Other languages
German (de)
English (en)
Inventor
Magali Crassous
Claire Duranton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1891771A1 publication Critical patent/EP1891771A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Definitions

  • the invention relates to a method for translating messages conforming to a first authentication protocol into messages conforming to a second authentication protocol during an authentication phase during which a peer, with an identity and who wishes to accessing a resource of a network connects to an authenticator, said credential authorizing access to the network based on an identity check and peer rights made by an authentication server based on data of authentication received in messages conforming to the second authentication protocol.
  • the present invention is in the field of telecommunications and networks. It is known that users who wish to access an IP network and who have subscribed an access service from an Internet Service Provider (ISP) must first authenticate with the ISP. Authentication makes it possible to control that an identified person is who he claims to be, by the use of a password for example. This then makes it possible to verify that it has rights to access a physical resource.
  • ISP Internet Service Provider
  • the authentication of a client is performed by an authentication server that retrieves client authentication data during a dialogue based on an authentication protocol.
  • the most used and most implemented protocol by network equipment manufacturers is the Remote Authentication Dial In User Service Protocol (PPP), both from the Internet Engineering Task Force (NETF) http: // wwwJetf .org / rfc / rfc2865.txt, http://wwwJetf.org/rfc/rfc1661.txt.
  • Authentication servers that support the RADIUS protocol are called RADIUS servers.
  • PPP CHAP Point to Point Protocol Challenge Handshake Authentication Protocol
  • EAP PPP Point to Point Protocol Extensible Authentication Protocol
  • PPP CHAP periodically checks the identity of a client by sending a PPP CHAP request to the client containing a challenge that is a random value.
  • the client sends back a value computed from several data including the challenge and a secret it holds, thus allowing the RADIUS server to control the identity of the client by calculating a value from the same data.
  • the secret is a password specific to the user and known to the RADIUS server.
  • EAP allows the authentication of a client wishing to associate with an access network.
  • EAP is unique in that it defines generic exchanges to transport various EAP authentication methods.
  • EAP supports a dozen EAP authentication methods, such and such non-exhaustive MD5 Challenge EAP after I 1 http://www.ietf.org/rfc/rfc3748.txt IETF, EAP-TTLS (Tunneled Transport Layer Security) in discussion I 1 http://www.ietf.org/internet-drafts/draft-funk- IETF eAP-TTLS-v1 -00.txt.
  • the genericity that characterizes EAP makes it a very flexible protocol that is increasingly used.
  • EAP MD5-Challenge is the easiest of the EAP authentication methods to implement: authentication is done by sending the client an EAP MD5-Challenge request containing a challenge. The client responds by hashing the challenge using an MD5 (Message Digest-5) hash function, defined by I 1 IETF http://www.ietf.org/rfc/rfc1321 .txt and using as a parameter a secret that is the password of the user. The RADIUS server checks the identity of the client by calculating a value from the same data.
  • MD5 Message Digest-5
  • I 1 IETF http://www.ietf.org/rfc/rfc1321 .txt The RADIUS server checks the identity of the client by calculating a value from the same data.
  • RADIUS for EAP MD5-Challenge exist and work separately.
  • an EAP MD5-Challenge client can not authenticate to a RADIUS server that supports the PPP CHAP authentication method but does not have an EAP function that is required for EAP MD5 authentication. Challenge.
  • Many servers already installed in the network do not have the EAP function that allows the server to authenticate an EAP MD5-Challenge client.
  • the object of the present invention is to solve the disadvantages of the prior art by proposing a translation method adapted to authenticate an EAP MD5-Challenge client with a CHAP-RADIUS PPP server that does not support the EAP authentication protocol.
  • a step of generating a challenge and sending said challenge a step of receiving a first response which is an answer to said challenge, generating a network access request compliant with the second authentication protocol and sending said asks the authentication server,
  • an EAP MD5-Challenge client can authenticate to a RADIUS server that does not have the EAP function, - no modification of the EAP MD5-Challenge client is necessary,
  • the translation method comprises a step of choosing an authentication method supported by the first authentication protocol.
  • methods based on the encapsulation of EAP MD5-Challenge in a tunnel such as for example EAP-TTLS, are compatible with the translation process.
  • the generation of the challenge comprises: a step consisting in asking the authentication server for said challenge,
  • the ability to generate the challenge by an external server provides compatibility with standard authentication methods and used by the authentication method.
  • the invention also relates to a method for authenticating a peer having an identity and for accessing a resource of a network connects to an authenticator-translator according to a first authentication protocol, said authenticator-translator authorizing access to the network based on an identity check and peer rights performed by an authentication server based on authentication data received in messages conforming to a second authentication protocol, comprising:
  • a step consisting in generating a challenge and sending said challenge characterized in that the authentication method integrates message translation functions conforming to the first authentication protocol into messages conforming to the second authentication protocol and that it includes:
  • the invention also relates to a translator device intended to translate messages conforming to a first authentication protocol into messages conforming to a second authentication protocol during an authentication phase during which a peer, with an identity and who wishes to access a resource of a network connects to an authenticator, said authenticator authorizing access to the network based on an identity check and peer rights made by an authentication server as a function of authentication data received in messages conforming to the second authentication protocol, characterized in that it comprises:
  • the translator device comprises a module for selecting an authentication method supported by the first authentication protocol.
  • the invention also relates to an authentication-translator device intended to authenticate a peer having an identity and which, to access a resource of a network, dialogue with said device in accordance with a first authentication protocol, said device authorizing the access to the network based on an authentication check and peer rights performed by an authentication server based on authentication data received in messages conforming to the second authentication protocol, comprising: getting a challenge,
  • the invention also relates to an authentication system comprising a peer wishing to access a resource of a network and who must authenticate with an authenticating system by sending authentication data conforming to a first authentication protocol, received and verified by an authentication server according to a second authentication protocol, characterized in that it comprises:
  • the means for translating the authentication data of the first protocol into authentication data of the second protocol are performed by the translator device.
  • the means for translating the authentication data of the first protocol into authentication data of the second protocol are performed by the authenticator-translator device.
  • the invention also relates to a computer program comprising instructions for implementing the translation method according to the invention when it is executed by a microprocessor.
  • the invention also relates to a computer program comprising instructions for implementing the authentication method according to the invention when it is executed by a microprocessor.
  • FIG. 1 is a diagram presenting the format of the PPP CHAP challenge and response messages according to the state of the art, exchanged between a client to be authenticated and an authentication system in the authentication phase.
  • FIG. 2 is a diagram presenting the format of EAP MD5-Challenge type EAP request or response messages, according to the state of the art, exchanged between a client to authenticate and authentication system in the authentication phase.
  • FIG. 3 is a diagram representing an authentication method according to the state of the art in accordance with the PPP CHAP protocol.
  • FIG. 4 is a diagram representing a method of authentication according to the state of the art in accordance with the EAP protocol and the EAP MD5-Challenge authentication method.
  • Figure 5 is a diagram showing a first variant of a translation method according to the invention.
  • Figure 6 is a diagram showing a second variant of the translation method according to the invention.
  • Figure 7 is a network architecture diagram according to a first variant of the invention.
  • FIG. 8 is a network architecture diagram according to a second variant of the invention.
  • Figure 9 is a diagram showing the functional organization of a translator and an authenticator-translator according to the invention.
  • Figure 10 is a diagram showing the main components of a translator according to the invention.
  • an authenticating system controls a physical resource through a network access point.
  • the client to authenticate wishes to access the resource and must for that, to authenticate itself.
  • the authentication server is the machine that will verify, on request of the authentication system, if the client to authenticate is the one he claims to be, and if he has the right to access the requested resource. If the authentication succeeds, the authenticating system gives access to the resource it controls.
  • the authentication server manages the authentication itself, interacting with the client to authenticate on the basis of an established authentication protocol.
  • the client to authenticate consists of a machine and a user.
  • the authentication system is a network equipment, such as for example a wireless access point or access point (the acronym commonly used is the acronym AP for Access Point), a switch / IP router called NAS (Network Access Server) during access RTC (Switched Telephone Network) or ADSL (Asymmetric Digital Subscriber One).
  • NAS Network Access Server
  • RTC Switchched Telephone Network
  • ADSL Asymmetric Digital Subscriber One
  • the client to be authenticated is called peer (the term commonly used is the term "peer") and the authenticating system is called authenticator (the term commonly used is the term "authenticator").
  • the authentication server is typically a RADIUS server or other equipment capable of authentication.
  • the RADIUS server is the most used equipment for authentication, especially by ISPs.
  • the RADIUS protocol operates in a client / server mode.
  • the authenticating system functions as a RADIUS client.
  • a RADIUS client issues RADIUS requests and acts based on the responses received.
  • a RADIUS server can act as a RADIUS proxy for other RADIUS servers, as well as for other authentication systems.
  • the operating principle of the RADIUS protocol lies in the use of a secret held by the RADIUS server and the peer to be authenticated which is not transmitted on the network in the case of a PPP CHAP authentication.
  • An example of a secret is a password.
  • the RADIUS protocol allows user / password or user / challenge / response authentication.
  • the protocol is based on an exchange of queries / responses that can be of four different types: "Access-Request", "Access- Accept", "Access-Reject” and "Access-Challenge".
  • a RADIUS client sends an access authorization request to the RADIUS server. This is a RADIUS request of type "Access-Request”.
  • the RADIUS server sends a response of acceptance, rejection or request for additional information.
  • An acceptance response is a RADIUS response of the type "Access-Accept”
  • a rejection response is a RADIUS response of the type "Access-Reject”
  • an additional information request response is a RADIUS request of the type "Access- Challenge "sent by the RADIUS server that sends a challenge and is waiting for an answer.
  • the RADIUS protocol carries authentication and authorization information in RADIUS request fields, for example in information elements called attributes.
  • the number of attributes in a RADIUS message is variable. There may be none, one or more.
  • Each attribute has a type that qualifies it, a value and a size. For example and in a non-limiting manner, a "User-Name" type attribute corresponds to a user identifier or login to be authenticated, a "CHAP Challenge" type attribute corresponds to a CHAP PPP challenge generated by an authenticating system.
  • an attribute of the type "CHAP-Password” corresponds to a response to a PPP CHAP challenge sent by the client to authenticate
  • a "Reply-Message” attribute when it is sent in a RADIUS request of "Access-Challenge” type contains a challenge.
  • Authentication elements may also be contained in a field of a RADIUS request / response called "Authenticator”.
  • FIG. 1 presents the format of the PPP CHAP compliant challenge and response messages according to the state of the art. Challenge and response messages are exchanged between a peer and an authenticator.
  • a first field d qualifies the type of a message depending on whether it is a challenge or an answer to the challenge.
  • the field is called “Code”.
  • a second field c2, called “Identifier” contains a value that identifies an exchange of messages. It must be changed each time a new challenge is sent. For a challenge response message, the value of the field is the same as the value of the "Identify” field of the challenge message.
  • a fourth field c4 corresponds to the length of a fifth field c5 called “Value” defined below.
  • the fifth field c5 contains the value of the challenge or challenge response.
  • a challenge is a random value that is changed each time a new challenge is sent.
  • the response to the challenge is calculated using a hash function, by applying the hash function to a byte stream composed of the value of the c2 field "Identifier”, followed by a known secret of the user associated with the peer and the authentication server, followed by the value of the challenge.
  • the hash function is MD5.
  • the secret is a password specific to the user.
  • a sixth field c6, called "Name" corresponds to the identification of the system that transmits the message.
  • FIG. 2 illustrates the format of an EAP request or response according to the state of the art. EAP requests and responses are exchanged between a peer and an authenticator.
  • a first field c7 specifies whether it is a request or a response to the request.
  • a third field c9 specifies the length of the EAP message.
  • a fourth field d 0, called “Type” specifies the type of the request or response. For example, a particular type called “Identity” is a request for an identity request or a response to the identity request.
  • a Identity request response message contains in a fifth field c1 1 called “Type-Data" the identity of the user associated with the peer.
  • Another type of request that is specified in the c10 field corresponds to an EAP authentication method.
  • a type called “MD5-Challenge” specifies that the EAP authentication method is EAP MD5-Challenge.
  • the type "MD5-Challenge” is analogous to the PPP CHAP protocol with MD5 as a hash function.
  • the field c1 1, called “Type-Data” is composed of the following fields:
  • a sixth field c12 comparable to the field c4 of FIG. 1, corresponds to the length of the field c13.
  • a seventh field c13 comparable to the field c5 of FIG. 1 corresponds to a challenge or an answer to this challenge.
  • an eighth field c14 comparable to the field c6 of FIG. 1, corresponds to the identification of a system that transmits the request or the EAP response.
  • FIG. 3 illustrates the CHAP-RADIUS PPP authentication mechanism according to the state of the art by describing message exchanges between three entities concerned by the authentication process.
  • a peer 100 designates the client to authenticate.
  • a network access server (the expression commonly used is the English expression “Network Access Server” or “NAS") 1 10 designates the authenticating system.
  • the "NAS” 1 10 controls the peer's access 100 to a physical resource of the network.
  • a RADIUS server 120 is the authentication server in charge of the authentication of the peer 100.
  • the format of the PPP CHAP challenge and reply messages exchanged between the peer 100 and the "NAS" 1 10 is in accordance with that illustrated by FIG. figure 1 .
  • the peer 100 and the "NAS” 1 10 are in a PPP negotiation phase during which the peer 100 and the "NAS” 1 10 establish a PPP link and agree on the authentication to use. In particular, it is in this phase that the choice of the PPP CHAP authentication method is made.
  • the "NAS” 1 10 generates a challenge and sends the par 100 a PPP CHAP challenge message if that includes the challenge.
  • the CHAP-RADIUS PPP authentication not shown in FIG.
  • the "NAS” 110 delegates the generation of the challenge to the RADIUS server 120: the “NAS” server 110 sends a RADIUS request "Access- Requ is "to the RADIUS server 120 that responds with a RADIUS” Access-Challenge “response that contains the challenge in a RADIUS” Reply-Message "attribute.
  • the challenge message PPP CHAP if it is possible to specify in the field c6 the identification of the "NAS” 1 10 that sends the message.
  • a step 3 subsequent to receiving the PPP CHAP challenge message if, the peer 100 retrieves the challenge value of the PPP CHAP challenge message if and calculates a response to that challenge.
  • the response is calculated by applying an MD5 hash function to a data consisting of the value of the c2 field of the PPP CHAP challenge message if, followed by a secret held by the peer 100, followed by the value of the challenge received in the PPP CHAP challenge message if and which appears in the c5 field of the message if.
  • the peer 100 sends the response in a PPP CHAP response message s2.
  • the field c6 is used to specify the identifier of the peer 100 which sends the message.
  • the "NAS” 1 10 In a step 4, following receipt of the PPP CHAP response message s2, the "NAS” 1 10 generates a RADIUS request "Access-Request" s3 for the RADIUS server 120.
  • the request includes the following RADIUS attributes:
  • RADIUS attribute "User-name” whose value is the identifier of the peer 100.
  • the value of the RADIUS attribute "User-name” is retrieved in the c6 field of the PPP CHAP response message s2, - a RADIUS attribute "CHAP-Challenge” whose value corresponds to the challenge calculated by the "NAS" 1 10 in step 2.
  • the attribute "CHAP-Challenge" may not be sent,
  • a "CHAP-Password" RADIUS attribute whose value consists of the identifier of the PPP CHAP message if specified in the c2 field of the PPP CHAP message if and of the response to the challenge received in step 4 in the response message PPP CHAP s2.
  • the "NAS” 110 sends the RADIUS server 120 the RADIUS request "Access-Request” s3.
  • the "NAS” 110 sends the RADIUS server 120 the RADIUS request "Access-Request” s3.
  • a step 5 following the receipt of the RADIUS request
  • the RADIUS server 120 verifies the authentication of the user. For this purpose, it calculates an authentication value using the same MD5 hash function as that used by the peer 100 that it applies to a byte stream consisting of the challenge present in the "CHAP Challenge” attribute. of the RADIUS request "Access-Request” s3, followed by the secret of the user it holds and the identifier of the PPP CHAP message if present in the "CHAP-password” attribute of the RADIUS request "Access-Request "s3. The RADIUS server 120 compares the authentication value with the challenge response present in the "CHAP-Challenge” attribute of the RADIUS request "Access-Request” s3.
  • the authentication server uses the challenge it has to calculate the authentication value and the content of the "User-Password” attribute that contains the challenge response to verify authentication. If the authentication value is equal to the response to the challenge then the authentication succeeded, otherwise it failed. In both cases, the RADIUS server 120 returns, at the end of step 5, a message s4 to "NAS" 1 10 specifying the result of the authentication. In the case of successful authentication the message s4 is a RADIUS response "Access-Accept". In the case where the authentication has failed, the message s4 is a RADIUS response "Access-Reject". In a step 6, following the receipt of the message s4, the "NAS"
  • the message s5 is a PPP CHAP message of the type "CHAP-Success” if the authentication has succeeded and a PPP CHAP message “CHAP-Failure” if the authentication failed.
  • the "NAS" 110 sends the response message s5 to the peer 100.
  • a step 7 following the receipt of the response message s5, the peer 100 is authorized or not to access the physical resource.
  • Figure 4 illustrates the authentication mechanism according to the EAP MD5-Challenge method according to the state of the art by describing the message exchanges between the three entities involved in the authentication process.
  • a peer 130 wishes to access a physical resource of the network and addresses an authenticator 140 that performs access control to the physical resource.
  • An authentication server 150 is in charge of the authentication of the peer 130.
  • the format of an EAP request or response message is in the format shown in Figure 2.
  • the authenticator 140 sends the peer 130 an EAP request s10 request identity.
  • the message contains in field c10 a value that corresponds to the type "Identity”.
  • the peer 130 builds an EAP response message if 1 which contains the identity of the peer 130 in the field d 1 of the EAP response message if 1.
  • the peer 130 sends the EAP response message if 1 to the authenticator 140.
  • a step 13 subsequent to receiving the response message
  • the authenticator relays the EAP response message s1 1 to the authentication server 150 in an EAP response message s12.
  • the authentication server 150 In a step 14, following the receipt of the EAP response message s12, the authentication server 150 generates a challenge and an EAP request message s13 type EAP MD5-Challenge.
  • the EAP request message s13 contains the challenge in the message field c13. In addition to the challenge it is possible to specify the identity of the authentication server at the origin of the request message in the c14 field.
  • the authentication server 150 sends the EAP request message s13 to the authenticator 140.
  • a step 15 following the receipt of the request message
  • the authenticator 140 relays the EAP request message s13 to par 130 in an EAP request message s14.
  • the peer 130 extracts the challenge from the EAP request message s13 and uses it to construct a response.
  • the response is calculated by applying the hash function MD5 to a byte stream consisting of the challenge, followed by the secret held by the peer 130 and the identifier of the request message s14 retrieved in the message field c8.
  • the peer 130 sends an EAP response s15 to the authenticator 140 which contains the answer to the challenge in the field c13.
  • the field c14 of the EAP response s15 can be used to specify the identity of the peer 130 that issues the response.
  • step 17 subsequent to receiving the EAP response s15, the authenticator 140 relays the EAP response s15 to the authentication server 150 in an EAP response message if 6.
  • step 18 following the receipt of the message Answer
  • the authentication server 150 checks the authentication of the peer 130. For this it calculates an authentication value by applying the function of MD5 hash to a byte stream consisting of the challenge it generated in step 14, followed by the peer-specific secret 130 that it holds and the identifier of the request and response messages that appears in the field c8 of the EAP response message s16. If the authentication value is equal to the response to the challenge in field c17 of the EAP response message s16, then the authentication of the peer 130 has succeeded, otherwise it has failed. In both cases, the authentication server 150 generates an EAP message s17 specifying the result of the authentication. In the case of successful authentication the EAP message s17 is an EAP message of type "EAP Success". In the case where the authentication has failed, the EAP message s17 is an EAP message of type "EAP Failure". The authentication server 150 sends the EAP message s17 to the authenticator 140.
  • step 19 subsequent to the receipt of the EAP message s17 sent by the authentication server 150 in step 18, the authenticator 140 relays the EAP message s17 to the peer 130 in an EAP message " s18.
  • a step 20 following the receipt of the EAP message s18, the peer 130 is accessed or not to the physical resource.
  • all the EAP messages exchanged between the authenticator 140 and the authentication server 150 are encapsulated in messages conforming to an AAA protocol (Authentication, Authorization and Accounting), for example RADIUS .
  • AAA protocol Authentication, Authorization and Accounting
  • FIG. 5 illustrates an authentication mechanism that implements an EAP MD5-Challenge authentication message translation method in CHAP-RADIUS PPP authentication messages according to the invention by describing messages exchanges that occur between the entities affected by the authentication process as well as processing.
  • EAP terminology we use terms from the EAP terminology to refer to the entities involved in the authentication process.
  • An EAP peer 160 is the client to authenticate who wishes to access a physical resource and for this to authenticate.
  • Authenticator 170 is the authenticating system that performs access control to the physical resource.
  • a translator 180 which is specific to the present invention, implements the method according to the invention and translates authentication messages conforming to the EAP protocol and the EAP MD5-Challenge method into messages conforming to the CHAP-RADIUS PPP authentication protocol.
  • a translation module 181 is a program intended to be stored in a memory of the translator 180; it comprises instructions for implementing the translation method according to the invention.
  • a current EAP conversation context intended to store information of the current EAP conversation, for example and in a non-exhaustive way an identifier of the current EAP conversation, the EAP authentication method chosen for the conversation. common.
  • This information is received during exchanges with the authenticator 170 and a RADIUS server 190.
  • the RADIUS server 190 is in charge of the authentication of the peer EAP 160. This RADIUS server does not have the EAP function enabling it to authenticate. EAP clients.
  • all the messages exchanged between the peer 160 and the authenticator 170 are encapsulated in a secure tunnel, for example in messages conforming to EAP-TTLS.
  • all the messages exchanged between the authenticator 170 and the translator 180 are encapsulated in messages conforming to a protocol of AAA type, for example RADIUS.
  • the authenticator 170 In an initial step 22, the authenticator 170 generates and sends an identity request message s20 to the peer EAP 160.
  • the message contains in the field c10 a value corresponding to the type "Identity”.
  • a step 23 subsequent to receiving the identity request EAP message s20, the peer EAP 160 generates and sends an EAP response message s21 containing its identity in the field d 1.
  • a step 24 subsequent to receiving the response message
  • the authenticator 170 relays the EAP response message s21 to the translator 180 in an EAP message s22.
  • the translator 180 analyzes the EAP response message s22.
  • the translator 180 retrieves in the field c1 1 of the EAP response message s22 the identity of the peer EAP 160 to authenticate and stores this identity in the context of the current EAP conversation 182.
  • the context of the current EAP conversation 182 is identified unique, thanks to an identifier that appears in the field c8 of the EAP response message s22 of type "Identity".
  • the translator 180 selects an authentication method for the current EAP conversation that is EAP MD5-Challenge.
  • the choice of the EAP MD5-Challenge method results from various considerations: the identity of the peer EAP 160, an identifier of the authenticator 170 and any other complementary information that the translator 180 has and which enables it to characterize the user associated with the peer 160 and authenticator 170 which is the access point.
  • the information characterizing the user and the network access point are advantageously recorded in the context of the current EAP conversation 182.
  • the translator 180 records the choice of the EAP MD5-Challenge method in the context of current EAP conversation 182.
  • the translator 180 chooses to translate the EAP MD5-Challenge authentication into a CHAP-RADIUS PPP in order to outsource the authentication to a RADIUS server 190 which does not have the EAP function.
  • the translator chooses the RADIUS server by which he wishes to perform the authentication.
  • the translator 180 relies on various information that it has on the EAP peer: the identity of the peer EAP stored in the context of the current EAP conversation 182 and any other information available to the translator 180 via an access to another server or to a database that characterizes the user associated with the EAP peer 160 and the authenticator 170 which is the access point to the network. This information is stored in the context of the current EAP conversation 182.
  • the translator 180 determines that it must request the RADIUS server 190 to generate a challenge and send a RADIUS request "Access-Request" s23 to the RADIUS server 190.
  • the translator 180 chooses to generate the challenge itself. In this case, no message exchange takes place with the RADIUS server 190.
  • the RADIUS server 190 In a step 26 following the receipt of the RADIUS request "Access Request” s23, the RADIUS server 190 generates the challenge and sends the translator 180 a RADIUS response "Access-Challenge” s24 which contains the challenge in a RADIUS attribute "Reply -Message".
  • the translator 180 In a step 27 subsequent to receiving the RADIUS response s24, the translator 180 generates an EAP challenge message s25.
  • the challenge received from the RADIUS server 190 in the RADIUS response s24 is inserted in the field c13 of an EAP challenge message s25.
  • the challenge is inserted into the field c13 of the challenge EAP message s25 and stored in the context of the current EAP conversation 182.
  • the translator 180 stores how the challenge was generated in the context of the current EAP conversation 182.
  • the c14 field of the challenge EAP message s25 is advantageously used to specify the identity of the authentication server 190 that generated the challenge.
  • the field c14 of the challenge EAP message s25 is advantageously used to specify the identity of the translator 180 at the origin of the challenge EAP message. s25.
  • the translator 180 sends the challenge EAP message s25 to the authenticator 170 at the end of step 27.
  • the authenticator 170 relays the challenge EAP message s25 to the EAP peer 160 in an EAP challenge message s26.
  • the peer EAP 160 retrieves the challenge from the field c13 of the challenge EAP message s26 and generates an EAP response message s27. For this, the peer EAP 160 calculates a response to the challenge by applying the hash function MD5 to a stream of bytes consisting of the challenge value, followed by a secret specific to the peer EAP 160, followed by the message identifier s26 extracted from field c8 of the EAP challenge message s26.
  • the answer to the challenge is inserted in the field c13 of the EAP response message s27.
  • the field c14 of the EAP response message s27 can advantageously be used to specify the identity of the peer EAP 160.
  • the peer EAP 160 sends the EAP response message s27 to the authenticator 170.
  • the authenticator 170 relays the EAP response message s27 to the translator 180 in a message s28.
  • the translator 180 analyzes the EAP response message s28. It retrieves in the field c13 the response to the challenge and in the field c14, if it is filled in, the name of the entity that sent the message. The translator stores the response to the challenge and possibly the identity of the entity that issued the message in the context of the current EAP conversation 182. In an alternative embodiment of the invention, where the choice to externalize the authentication to a RADIUS server was not done during step 25, this choice is made now as well as the choice of RADIUS server.
  • the translator 180 relies on various information that it has on the peer EAP 160: the identity of the peer EAP 160 stored in the context of the current EAP conversation 182, the transmitter of the response message to the challenge request and any other information available to the translator 180 via access to another server or to a database and which characterizes the user associated with the peer EAP 160 and the authenticator 170 which is the access point to the network.
  • the translator 180 constructs a RADIUS request "Access Request" s29 which contains authentication information necessary for the RADIUS server 190 to perform the authentication of the peer EAP 160.
  • authentication information retrieved in previous steps are used by the translator 180 to generate the following authentication RADIUS attributes:
  • a "User-Name” attribute which corresponds to the identity of the user associated with the EAP peer 160.
  • the identity of the user is for example and non-exhaustively a MAC address (Media Access Control for control of access to the media), an IP address of the peer EAP 160 or the identity inserted in the field c14 of the message s27 by the peer EAP.
  • the value of this attribute is obtained from information contained in message fields previously exchanged and stored progressively in the context of current EAP conversation 182.
  • the translator 180 uses all or part of this information to construct the attribute "User-Name": the field d 1 of the EAP response message s22 to the request for identity received by the translator 180 in step 25.
  • the EAP response message s22 has been encapsulated in a RADIUS message
  • a copy of the field c1 1 is contained in the attribute "User-Name" of the RADIUS message s22.
  • the field c14 of the EAP response message s28 which advantageously contains the identity of the peer EAP 160. any other information making it possible to identify the user.
  • the EAP messages exchanged between the authenticator 170 and the translator 180 are encapsulated in a protocol of the AAA type, such as for example RADIUS, attributes of this protocol are advantageously used.
  • the translator 180 completes the attribute "User-Name” or creates an identifier from information specific to the user it holds, for example information stored in a database to which the translator 180 has access.
  • a "CHAP-Password” attribute which specifies the identifier of the EAP response message s28 and the response to the challenge extracted from the field c13 of the response message s28.
  • the "CHAP-Password” attribute is filled in the case where the challenge is stored by the translator 180 and sent to the RADIUS server 190 in the RADIUS request s29, in a RADIUS attribute "CHAP-Challenge” or in the "Authenticator” field. the RADIUS s29 request.
  • a "User-Password” attribute which contains the identifier of the EAP response message s28 and the response to the challenge extracted from the field c13 of the EAP response message s28.
  • the "User-Password” attribute is filled in the case where the challenge is not sent by the translator 180 to the RADIUS server 190 in the RADIUS request S29.
  • the translator 180 specifies in a "CHAP-Challenge” attribute or in the "Authenticator” field of the RADIUS request s29, the value of the challenge and in a "CHAP-Password” attribute the identifier of the EAP response message s28 and the response to the challenge extracted from the field c13 of the EAP response message s28.
  • proxy-type complementary processing is also implemented by the translator 180.
  • known information from the translator 180 is sent to the RADIUS server 190 in RADIUS attributes. The information is for example and non-exhaustive the accuracy by the translator 180 of information associated with the authenticator 170 or EAP 160 and that could be useful to the RADIUS server.
  • the RADIUS request "Access-Request" s29 constructed by the translator 180 is sent at the end of step 31 to the RADIUS server 190.
  • a step 32 subsequent to receiving the RADIUS request "Access-Request" s29 the authentication server 190 verifies the authentication of the user in the same way as for the PPP CHAP method.
  • the RADIUS server 190 sends a result message of the authentication s30 to the translator 180.
  • the result message of the authentication s30 is a RADIUS response "Access-Accept” in the case where the authentication has succeeded and a RADIUS response " Access- Reject "in case of failure.
  • a step 33 subsequent to the reception of the result message of the authentication s30, the translator 180 analyzes the result message of the authentication s30 and prepares the translation of said message s30 into an EAP message.
  • the preparation of the translation consists in choosing a message to send to the authenticating system as a result of the authentication.
  • the translator chooses the response message based on the received RADIUS response, and / or RADIUS attribute values of the RADIUS response, and / or internal conditions to the translator.
  • the translator generates an answer message s31 which is an EAP message "EAP-Success” in the case where the message s30 is a RADIUS response "Access- Accept” and an EAP message “EAP -Failure "in the event that the message s30 is a RADIUS response "Access- Reject”.
  • proxy-type processing is also possible to adapt the response message s31 according to criteria defined in the translator 180.
  • the response message s31 is sent to the authenticator 170 at the end of step 33.
  • the authenticator 170 relays the EAP response message s31 "EAP-Success” or "EAP-Failure" to the peer EAP 160 in an s32 message.
  • the peer EAP 160 accesses or not the physical resource.
  • FIG. 6 illustrates the message exchanges that take place in a second variant of the translation method according to the invention in which the functions of the translator as shown in FIG. 5 are integrated into the authenticating system.
  • An EAP 200 peer is the client to authenticate.
  • An authenticator-translator 210 is the authenticating system that performs access control to the physical resource and integrates the functions of the translator.
  • a RADIUS server 220 performs the access control of the peer EAP 200.
  • the steps 41, 42, 44, 46, 48, 50 are identical / of the same type as the steps 22, 23, 26, 29, 32, 35 described with reference to FIG.
  • the authenticator-translator 210 determines that the EAP authentication method to be used is EAP MD5-Challenge and that it must ask the RADIUS server 220 to generate a challenge.
  • the authenticator-translator 210 sends a RADIUS request "Access Request" s42 to the RADIUS server 220.
  • the authenticator-translator 210 chooses to generate the challenge itself. In this case, no message exchange takes place with the RADIUS server 220.
  • a step 45 following the receipt of a RADIUS response "Access-Challenge" s43 (which is of the same type as the response s24 according to FIG.
  • the authenticator-translator 210 generates an EAP challenge message s44.
  • the challenge received from the RADIUS server 220 in the RADIUS response "Access-Challenge" s43 is inserted into the field c13 of an EAP challenge message s44.
  • the challenge is inserted in the field c13 of the challenge EAP message s44.
  • the identity of the authenticator-translator 210 is specified in the field c14 of the challenge EAP message s44.
  • the challenge EAP message s44 is sent to the peer EAP 200 at the end of step 45.
  • a processing comparable to that performed by the translator in step 31 according to FIG. is realised.
  • the authenticator-translator 210 generates a RADIUS request "Access Request" s46 from the authentication information contained in the EAP messages exchanged in previous steps.
  • the RADIUS request "Access Request" s46 includes several attributes RADIUS: - a "User-Name" attribute in which the authenticator-translator 210 inserts the identifier of the user associated with the peer EAP 200 which can consist of information retrieved in the field d 1 of the EAP message s41 and in the field c14 of the EAP message s41.
  • the authenticator-translator 210 completes the attribute "User-Name" or creates an identifier from information specific to the user that it holds, for example information stored in a file. database to which the authenticator-translator 210 has access.
  • a "CHAP-Password” attribute in which the authenticator-translator 210 copies the identifier of the EAP response message s45 which is the identifier of the current EAP conversation and the response to the challenge extracted from the field c13 of the EAP response message s45.
  • the attribute "CHAP-Password” is filled in the case where the challenge is stored by the authenticator-translator 210 and sent to the RADIUS server 220 in the RADIUS request s46, in a RADIUS attribute "CHAP-Challenge” or in the "Authenticator” field of said request.
  • a "User-Password” attribute which contains the identifier of the response message s45 and the response to the challenge extracted from the field c13 of the EAP response message s45.
  • the "User-Password” attribute is filled in the case where the challenge is not sent by the authenticator-translator 210 to the RADIUS server 220 in the RADIUS request s46.
  • the authenticator-translator 210 specifies in a "CHAP-Challenge” attribute or in the "Authenticator” field of the RADIUS request s46, the value of the challenge and in a "CHAP-Password” attribute the identifier of the EAP response message s45 and the response to the challenge extracted from the field c13 of the EAP response message s45.
  • proxy-type complementary processing is also implemented by the authenticator-translator 210 which sends information in RADIUS attributes to the RADIUS server 220.
  • the EAP response message s46 is sent to the RADIUS server. 220.
  • a step 49 subsequent to the receipt of an authentication result message s47 (which is of the same type as the message s30), the authenticator-translator 210 generates a response message s48 to the attention of the peer.
  • EAP 200 which is an EAP message "EAP-Success” in case the message s47 is a RADIUS response "Access-Accept” and an EAP message “EAP-Failure” in case the message s47 is a RADIUS response "Access -reject ".
  • proxy-type processing is also possible to adapt the response message s48 according to criteria defined in the authenticator-translator 210.
  • FIG. 7 is a diagram showing an exemplary network architecture in which the entities involved in the translation method according to the invention are represented.
  • the peer EAP 160 (the term commonly used is the term "peer") wishes to access a physical resource of an IP type network 250 controlled by the authenticator 170 which constitutes a network access point.
  • the peer EAP 160 must first authenticate.
  • the RADIUS server 190 verifies that the peer EAP 160 is authenticated and has the right to access the physical resource of the network 250.
  • the RADIUS server 190 does not have the EAP function.
  • the peer EAP 160 to authenticate, dialogs with the authenticator 170 in accordance with the authentication method EAP MD5-Challenge.
  • the authenticator 170 requests the RADIUS server 190 to check whether the peer EAP 160 has the right to access the resource.
  • the peer EAP 160 dialog with the translator 180, specific to the invention, which translates the EAP MD5-Challenge authentication messages into CHAP-RADIUS PPP authentication messages understandable by the RADIUS server 190.
  • the translator 180 provides the RADIUS server 190 the authentication data specific to the EAP peer 160 and received from the authenticator 170. It receives from the RADIUS server 190 the result of the authentication. It translates this result to the attention of the authenticator 170.
  • the authenticator 170 informs the peer EAP 160 of the result of the authentication.
  • FIG. 8 is a diagram representing a second variant of the network architecture in which the entities involved in the translation method according to the invention are represented.
  • the authenticator-translator 210 specific to the invention is the authenticating system that performs the functions of the authenticator 170 and the translator 180 according to FIG.
  • FIG. 9 is a diagram illustrating the functional organization of a translator and an authenticator-translator according to the invention.
  • the translator 180 is composed of the following main functional modules: a module for obtaining a challenge 281 which is a random value.
  • the challenge is generated by the module or obtained by the module following a generation request made to an authentication server.
  • a module 282 for sending messages This module is responsible for sending messages prepared by a message processing module or the module for obtaining a challenge 281 to an external entity. It has several external interfaces for this purpose: an i282-1 interface for sending messages to an authentication server and an i282-3 interface for sending messages to an authenticator. a module for receiving messages 283. This module receives messages from external entities via several interfaces: an interface i283-1 for receiving the messages sent by the authenticator and an interface i283-3 for receiving messages from the server of the server. 'authentication. It transmits the received messages to a processing module. a processing module 284. This module analyzes messages received from the message receiving module 283, translates authentication data from one protocol to another and generates messages to be sent by the message transmission module 282.
  • a communication channel 288 allows the modules to exchange information.
  • the challenge module 281 may transmit to the message issuing module 282 a challenge request request that the message sending module 282 sends to an authentication server.
  • the authenticator-translator 210 comprises the same functional modules as the translator 180.
  • the message transmission module 282 differs from that of the translator 180 in that it has an interface i282-2 enabling it to send messages to the user. attention of a peer and that it does not have the i282-3 interface with the authenticator.
  • the message receiving module 283 of the authenticator-translator 210 differs from that of the translator 180 in that it does not have the interface i283-1 with the authenticator and in that it has an i283-2 interface that allows it to receive peer messages.
  • the functional blocks described above and the interfaces are advantageously implemented in the form of programs stored in a memory of the translator 180, respectively of the authenticator-translator 210, and executed by a processor of said translator, respectively said authenticator-translator.
  • Figure 10 is a diagram showing the main components of a translator 180 according to the invention.
  • a processor 360 (the commonly used term is “CPU”: “Central Processing Unit” for CPU) is a central component where the main calculations are performed. In particular, it executes programs loaded in a RAM 365 (the commonly used term is “RAM” for “Random Access Memory”) which stores the data that will be processed by the processor 360.
  • 370 devices provide communications between the processor and the outside world. They are not detailed in the diagram for the sake of clarity.
  • a device is a network connection module, a removable disk.
  • a bus 375 allows the transfer of data between the components of the translator 180.
  • a translation program 380 specific to the invention is stored in a device not shown in the diagram. It includes functional modules as described in Figure 9 and implemented as program instructions. It is loaded into RAM 365 for execution of the instructions by the processor.
  • FIG. 10 also applies to an authenticator-translator 210 according to FIG. 6.
  • the main components of the authenticator-translator are identical to those of the translator 180. Only the translation program 380 is different.
  • a specific program comprises functional modules as described in FIG. 9, implemented in the form of program instructions. Said program is loaded into RAM 365 for execution of the instructions by the processor.

Landscapes

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

Abstract

La présente invention concerne un procédé de traduction de messages conformes à un premier protocole d'authentification en messages conformes à un deuxième protocole d'authentification au cours d'une phase d'authentification pendant laquelle un pair, doté d'une identité et qui souhaite accéder à une ressource d'un réseau se connecte à un authentifiant, ledit authentifiant autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, caractérisé en ce que le procédé de traduction comprend : - une étape consistant à recevoir l'identité du pair dans un message conforme au premier protocole d'authentification, - une étape consistant à générer un défi et à envoyer ledit défi, - une étape consistant à recevoir une première réponse qui est une réponse audit défi, à générer une demande d'accès au réseau conforme au deuxième protocole d'authentification et à envoyer ladite demande au serveur d'authentification, - une étape consistant à recevoir une deuxième réponse qui est une réponse à ladite demande, à traduire la deuxième réponse pour générer un résultat d'authentification conforme au premier protocole d'authentification.

Description

Procédé de traduction d'un protocole d'authentification
L'invention concerne un procédé de traduction de messages conformes à un premier protocole d'authentification en messages conformes à un deuxième protocole d'authentification au cours d'une phase d'authentification pendant laquelle un pair, doté d'une identité et qui souhaite accéder à une ressource d'un réseau se connecte à un authentifiant, ledit authentifiant autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification.
La présente invention se situe dans le domaine des télécommunications et des réseaux. II est connu que des utilisateurs qui souhaitent accéder à un réseau IP et qui ont souscrit un service d'accès auprès d'un Fournisseur d'Accès Internet (FAI) doivent au préalable s'authentifier auprès du FAI. L'authentification permet de contrôler qu'une personne identifiée est bien celle qu'elle prétend être, par l'usage d'un mot de passe par exemple. Cela permet ensuite de vérifier qu'elle dispose de droits pour accéder à une ressource physique.
L'authentification d'un client, composé d'une machine et d'un utilisateur, est réalisée par un serveur d'authentification qui récupère des données d'authentification du client au cours d'un dialogue basé sur un protocole d'authentification. Le protocole le plus utilisé et le plus implanté par des équipementiers réseau est le protocole RADIUS (Remote Authentication Dial In User Service) avec PPP (Point to Point Protocol), tous deux issus de NETF (Internet Engineering Task Force) http://wwwJetf.org/rfc/rfc2865.txt, http://wwwJetf.org/rfc/rfc1661.txt. Les serveurs d'authentification qui supportent le protocole RADIUS sont appelés serveurs RADIUS.
Le protocole PPP supporte différentes méthodes d'authentification, par exemple, et de façon non exhaustive, PPP CHAP (Point to Point Protocol Challenge Handshake Authentication Protocol) issu de I1IETF http://www.ietf.org/rfc/rfc1994.txt, et PPP EAP (Point to Point Protocol Extensible Authentication Protocol) issu de NETF http://www.ietf.org/rfc/rfc3748.txt. PPP CHAP permet de vérifier périodiquement l'identité d'un client par envoi au client d'une requête PPP CHAP contenant un défi qui est une valeur aléatoire. Le client envoie en retour une valeur calculée à partir de plusieurs données dont le défi et un secret qu'il détient, permettant ainsi au serveur RADIUS de contrôler l'identité du client en calculant une valeur à partir des mêmes données. Le secret est un mot de passe propre à l'utilisateur et connu du serveur RADIUS.
EAP permet l'authentification d'un client souhaitant s'associer à un réseau d'accès. EAP a ceci de particulier qu'il définit des échanges génériques permettant de transporter diverses méthodes d'authentification EAP. EAP supporte une douzaine de méthodes d'authentification EAP, par exemple et de façon non exhaustive EAP MD5-Challenge issue de I1IETF http://www.ietf.org/rfc/rfc3748.txt, EAP-TTLS (Tunneled Transport Layer Security) en discussion à I1IETF http://www.ietf.org/internet-drafts/draft-funk- eap-ttls-v1 -00.txt. La généricité qui caractérise EAP en fait un protocole très flexible qui est de plus en plus utilisé.
EAP MD5-Challenge est la plus simple des méthodes d'authentification EAP à mettre en œuvre : l'authentification se fait par envoi au client d'une requête de type EAP MD5-Challenge contenant un défi. Le client répond en hachant le défi à l'aide d'une fonction de hachage MD5 (Message Digest-5), définie par I1IETF http://www.ietf.org/rfc/rfc1321 .txt et en utilisant comme paramètre un secret qui est le mot de passe de l'utilisateur. Le serveur RADIUS contrôle l'identité du client en calculant une valeur à partir des mêmes données.
Les deux mécanismes d'authentification RADIUS pour PPP CHAP et
RADIUS pour EAP MD5-Challenge existent et fonctionnent séparément. Cependant un client EAP MD5-Challenge ne peut pas s'authentifier auprès d'un serveur RADIUS supportant la méthode d'authentification PPP CHAP mais ne disposant pas d'une fonction EAP nécessaire à une authentification EAP MD5- Challenge. De nombreux serveurs, déjà installés dans le réseau ne disposent pas de la fonction EAP permettant au serveur d'authentifier un client EAP MD5- Challenge.
La présente invention a pour but de résoudre les inconvénients de la technique antérieure en proposant un procédé de traduction adapté pour authentifier un client EAP MD5-Challenge auprès d'un serveur PPP CHAP- RADIUS ne supportant pas le protocole d'authentification EAP.
Le but est atteint avec un procédé selon l'invention tel que décrit dans le paragraphe introductif et caractérisé en ce qu'il comprend :
- une étape consistant à recevoir l'identité du pair dans un message conforme au premier protocole d'authentification,
- une étape consistant à générer un défi et à envoyer ledit défi, - une étape consistant à recevoir une première réponse qui est une réponse audit défi, à générer une demande d'accès au réseau conforme au deuxième protocole d'authentification et à envoyer ladite demande au serveur d'authentification,
- une étape consistant à recevoir une deuxième réponse qui est une réponse à ladite demande, à traduire la deuxième réponse pour générer un résultat d'authentification conforme au premier protocole d'authentification. Les avantages de ce procédé sont considérables :
- un client EAP MD5-Challenge peut s'authentifier auprès d'un serveur RADIUS ne disposant pas de la fonction EAP, - aucune modification du client EAP MD5-Challenge n'est nécessaire,
- aucune modification du serveur RADIUS n'est nécessaire. C'est un avantage lorsque le serveur RADIUS est déjà opérationnel dans le réseau.
Avantageusement, le procédé de traduction comprend une étape de choix d'une méthode d'authentification supportée par le premier protocole d'authentification. Ainsi, des méthodes basées sur l'encapsulation de EAP MD5-Challenge dans un tunnel, comme par exemple EAP-TTLS, sont compatibles avec le procédé de traduction.
Avantageusement, la génération du défi comprend : - une étape consistant à demander ledit défi au serveur d'authentification,
- une étape consistant à recevoir ledit défi.
La possibilité de faire générer le défi par un serveur externe assure une compatibilité avec les méthodes d'authentification normalisées et utilisées par le procédé d'authentification.
L'invention concerne aussi un procédé d'authentification d'un pair doté d'une identité et qui pour accéder à une ressource d'un réseau se connecte à un authentifiant-traducteur conformément à un premier protocole d'authentification, ledit authentifiant-traducteur autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification en fonction de données d'authentification reçues dans des messages conformes à un deuxième protocole d'authentification, comprenant :
- une étape consistant à envoyer une demande d'identité au pair,
- une étape consistant à recevoir l'identité du pair dans un message conforme au premier protocole d'authentification,
- une étape consistant à générer un défi et à envoyer ledit défi, caractérisé en ce que le procédé d'authentification intègre des fonctions de traduction de messages conformes au premier protocole d'authentification en messages conformes au deuxième protocole d'authentification et qu'il comprend :
- une étape consistant à recevoir une première réponse qui est une réponse audit défi, à générer une demande d'accès au réseau conforme au deuxième protocole d'authentification et à envoyer ladite demande au serveur d'authentification, - une étape consistant à recevoir une deuxième réponse qui est une réponse à ladite demande, à traduire la deuxième réponse pour générer un résultat d'authentification conforme au premier protocole d'authentification et à envoyer ledit résultat d'authentification.
L'invention concerne aussi un dispositif traducteur prévu pour traduire des messages conformes à un premier protocole d'authentification en messages conformes à un deuxième protocole d'authentification au cours d'une phase d'authentification pendant laquelle un pair, doté d'une identité et qui souhaite accéder à une ressource d'un réseau se connecte à un authentifiant, ledit authentifiant autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, caractérisé en ce qu'il comprend :
- un module d'obtention d'un défi,
- un module d'émission dudit défi et d'une demande d'accès au réseau,
- un module de réception de l'identité du pair, d'une première réponse qui est une réponse audit défi et d'une deuxième réponse qui est une réponse à ladite demande d'accès au réseau,
- un module de traitement qui génère la demande d'accès au réseau conforme au deuxième protocole d'authentification et traduit un résultat d'authentification conformément au premier protocole d'authentification. De façon avantageuse, le dispositif traducteur comprend un module de choix d'une méthode d'authentification supportée par le premier protocole d'authentification.
L'invention concerne aussi un dispositif authentifiant-traducteur prévu pour authentifier un pair doté d'une identité et qui pour accéder à une ressource d'un réseau, dialogue avec ledit dispositif conformément à un premier protocole d'authentification, ledit dispositif autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, comprenant : - un module d'obtention d'un défi,
- un module d'émission d'une demande d'identité du pair, dudit défi, d'une demande d'accès au réseau et d'un résultat d'authentification, - un module de réception de ladite identité, d'une première réponse qui est une réponse audit défi et d'une deuxième réponse qui est une réponse à ladite demande d'accès au réseau, caractérisé en ce qu'il est prévu pour traduire des messages conformes au premier protocole d'authentification en messages conformes au deuxième protocole d'authentification et qu'il comprend :
- un module de traitement qui génère la demande d'accès au réseau conforme au deuxième protocole d'authentification et traduit le résultat d'authentification conformément au premier protocole d'authentification. L'invention concerne également un système d'authentification comprenant un pair souhaitant accéder à une ressource d'un réseau et qui doit s'authentifier auprès d'un système authentifiant en envoyant des données d'authentification conformes à un premier protocole d'authentification, reçues et vérifiées par un serveur d'authentification selon un deuxième protocole d'authentification caractérisé en ce qu'il comprend :
- des moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole,
- des moyens pour authentifier le client.
Avantageusement, les moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole sont réalisés par le dispositif traducteur.
Avantageusement, les moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole sont réalisés par le dispositif authentifiant-traducteur. L'invention concerne aussi un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de traduction selon l'invention lorsqu'il est exécuté par un microprocesseur.
L'invention concerne aussi un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'authentification selon l'invention lorsqu'il est exécuté par un microprocesseur. De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un mode particulier de réalisation en référence aux schémas annexés donnés à titre non limitatif et dans lesquels :
La figure 1 est un schéma présentant le format des messages de défi et de réponse PPP CHAP selon l'état de la technique, échangés entre un client à authentifier et un système authentifiant en phase d'authentification.
La figure 2 est un schéma présentant le format des messages de type requête ou réponse EAP de type EAP MD5-Challenge, selon l'état de la technique, échangés entre un client à authentifier et système authentifiant en phase d'authentification.
La figure 3 est un schéma représentant une méthode d'authentification selon l'état de la technique conforme au protocole PPP CHAP.
La figure 4 est un schéma représentant une méthode d'authentification selon l'état de la technique conforme au protocole EAP et à la méthode d'authentification EAP MD5-Challenge.
La figure 5 est un schéma représentant une première variante d'un procédé de traduction selon l'invention.
La figure 6 est un schéma représentant une seconde variante du procédé de traduction selon l'invention. La figure 7 est un schéma d'architecture réseau conforme à une première variante de l'invention.
La figure 8 est un schéma d'architecture réseau conforme à une seconde variante de l'invention.
La figure 9 est un schéma présentant l'organisation fonctionnelle d'un traducteur et d'un authentifiant-traducteur selon l'invention.
La figure 10 est un schéma où figurent les principaux composants d'un traducteur selon l'invention.
Dans un processus d'authentification réseau classique trois entités interagissent : un système authentifiant, un client à authentifier et un serveur d'authentification. Le système authentifiant contrôle une ressource physique via un point d'accès au réseau. Le client à authentifier souhaite accéder à la ressource et doit pour cela, s'authentifier. Le serveur d'authentification est la machine qui va vérifier, sur demande du système authentifiant, si le client à authentifier est bien celui qu'il prétend être, et s'il a le droit d'accéder à la ressource demandée. Si l'authentification réussit, le système authentifiant donne l'accès à la ressource qu'il contrôle. Le serveur d'authentification gère l'authentification proprement dite, en dialoguant avec le client à authentifier sur la base d'un protocole d'authentification établi.
Le client à authentifier est constitué d'une machine et d'un utilisateur. Dans la plupart des implantations réseau actuelles, le système authentifiant est un équipement réseau, comme par exemple une borne d'accès sans fil ou Point d'Accès (l'acronyme couramment utilisé est l'acronyme anglais AP pour Access Point), un commutateur/routeur IP appelé NAS (Network Access Server) lors d'un accès RTC (Réseau Téléphonique Commuté) ou ADSL (Asymmetric Digital Subscriber Une). Dans les terminologies EAP et PPP CHAP, le client à authentifier s'appelle pair (le terme couramment utilisé est le terme anglais "peer") et le système authentifiant s'appelle authentifiant (le terme couramment utilisé est le terme anglais "authenticator"). Le serveur d'authentification est typiquement un serveur RADIUS ou tout autre équipement capable de faire de l'authentification. Le serveur RADIUS est l'équipement le plus utilisé pour l'authentification notamment par les fournisseurs d'accès Internet.
Le protocole RADIUS fonctionne selon un mode client/serveur. Le système authentifiant fonctionne comme un client RADIUS. Un client RADIUS émet des requêtes RADIUS et agit en fonction des réponses reçues. Un serveur RADIUS peut agir en tant que mandataire RADIUS pour d'autres serveurs RADIUS, ainsi que pour d'autres systèmes d'authentification. Le principe de fonctionnement du protocole RADIUS réside dans l'utilisation d'un secret détenu par le serveur RADIUS et le pair à authentifier qui n'est pas transmis sur le réseau dans le cas d'une authentification PPP CHAP. Un exemple de secret est un mot de passe. Le protocole RADIUS permet une authentification utilisateur/mot de passe ou utilisateur/défi/réponse. Le protocole est basé sur un échange de requêtes/réponses pouvant être de quatre types différents : "Access-Request", " Access- Accept", "Access- Reject" et "Access-Challenge".
Un client RADIUS envoie une requête d'autorisation d'accès au serveur RADIUS. C'est une requête RADIUS de type "Access-Request". Le serveur RADIUS envoie une réponse d'acceptation, de rejet ou de demande d'informations complémentaires. Une réponse d'acceptation est une réponse RADIUS de type "Access-Accept", une réponse de rejet est une réponse RADIUS de type "Access- Reject" et une réponse de demande d'informations complémentaires est une requête RADIUS de type "Access-Challenge" envoyée par le serveur RADIUS qui envoie un défi et qui attend une réponse.
Le protocole RADIUS transporte des informations d'authentification et d'autorisation dans des champs de requêtes RADIUS, par exemple dans des éléments d'informations appelés attributs. Le nombre d'attributs dans un message RADIUS est variable. Il peut n'y en avoir aucun, un ou plusieurs. Chaque attribut possède un type qui le qualifie, une valeur et une taille. Par exemple et de façon non limitative, un attribut de type "User-Name" correspond à un identifiant ou un login d'utilisateur à authentifier, un attribut de type "CHAP- Challenge" correspond à un défi PPP CHAP généré par un système authentifiant et envoyé au client à authentifier, un attribut de type "CHAP- Password" correspond à une réponse à un défi PPP CHAP envoyée par le client à authentifier, un attribut "Reply-Message", lorsqu'il est envoyé dans un requête RADIUS de type "Access-Challenge" contient un défi. Des éléments d'authentification peuvent également être contenus dans un champ d'une requête/réponse RADIUS appelé "Authenticator".
La figure 1 présente le format des messages de défi et de réponse conforme au protocole PPP CHAP selon l'état de la technique. Les messages de défi et de réponse sont échangés entre un pair et un authentifiant.
Un premier champ d permet de qualifier le type d'un message selon qu'il s'agit d'un défi ou d'une réponse au défi. Le champ d porte le nom de "Code". Un deuxième champ c2, appelé "Identifier", contient une valeur qui identifie un échange de messages. Il doit être changé à chaque fois qu'un nouveau défi est envoyé. Pour un message de réponse au défi, la valeur du champ est la même que la valeur du champ "Identifier" du message de défi. Un troisième champ c3, appelé "Length", contient la taille du message
PPP CHAP.
Un quatrième champ c4, appelé "Value-Size", correspond à la longueur d'un cinquième champ c5 appelé "Value" défini ci-dessous.
Le cinquième champ c5, appelé "Value", contient la valeur du défi ou de la réponse au défi. Un défi est une valeur aléatoire qui est changée chaque fois qu'un nouveau défi est envoyé. La réponse au défi est calculée à l'aide d'une fonction de hachage, par application de la fonction de hachage à un flux d'octets composé de la valeur du champ c2 "Identifier", suivie d'un secret connu de l'utilisateur associé au pair et du serveur d'authentification, suivie de la valeur du défi. Dans le cas de PPP CHAP la fonction de hachage est MD5. Le secret est un mot de passe propre à l'utilisateur.
Un sixième champ c6, appelé "Name", correspond à l'identification du système qui transmet le message.
La figure 2 illustre le format d'une requête ou d'une réponse EAP selon l'état de la technique. Les requêtes et réponses EAP sont échangées entre un pair et un authentifiant.
Un premier champ c7, appelé "Code", précise s'il s'agit d'une requête ou d'une réponse à la requête. Un deuxième champ c8, appelé "Identifier", identifie un échange de messages : le champ c8 d'une réponse sera le même que le champ c8 de la requête à l'origine de la réponse.
Un troisième champ c9, appelé "Length", précise la longueur du message EAP. Un quatrième champ d 0, appelé "Type" précise le type de la requête ou de la réponse. Par exemple, un type particulier appelé "Identity" correspond à une requête de demande d'identité ou une réponse à la demande d'identité. Un message de réponse à une demande d'identité contient dans un cinquième champ c1 1 appelé "Type-Data" l'identité de l'utilisateur associé au pair. Un autre type de requête qui est précisé dans le champ c10, correspond à une méthode d'authentification EAP. Par exemple, un type appelé "MD5-Challenge" précise que la méthode d'authentification EAP est EAP MD5-Challenge. Le type "MD5-Challenge" est analogue au protocole PPP CHAP avec MD5 comme fonction de hachage. Dans ce cas, le champ c1 1 , appelé "Type-Data", est composé des champs suivants :
- un sixième champ c12, appelé "Value-Size", comparable au champ c4 de la figure 1 , correspond à la longueur du champ c13.
- un septième champ c13, appelé "Value", comparable au champ c5 de la figure 1 correspond à un défi ou à une réponse à ce défi.
- un huitième champ c14, appelé "Name", comparable au champ c6 de la figure 1 correspond à l'identification d'un système qui transmet la requête ou la réponse EAP.
La figure 3 illustre le mécanisme d'authentification PPP CHAP-RADIUS selon l'état de la technique en décrivant des échanges de messages entre trois entités concernées par le processus d'authentification. Un pair 100 désigne le client à authentifier. Un serveur d'accès au réseau (l'expression couramment utilisée est l'expression anglaise "Network Access Server" ou "NAS") 1 10 désigne le système authentifiant. Le "NAS" 1 10 contrôle l'accès du pair 100 à une ressource physique du réseau. Un serveur RADIUS 120 est le serveur d'authentification en charge de l'authentification du pair 100. Le format des messages de défi et de réponse PPP CHAP échangés entre le pair 100 et le "NAS" 1 10 est conforme à celui illustré par la figure 1 .
Dans un état initial 1 , le pair 100 et le "NAS" 1 10 sont dans une phase de négociation PPP au cours de laquelle le pair 100 et le "NAS" 1 10 établissent une liaison PPP et se mettent d'accord sur l'authentification à utiliser. En particulier, c'est dans cette phase qu'il est fait le choix de la méthode d'authentification PPP CHAP. Dans une étape 2, consécutive à la phase de négociation PPP qui s'est déroulée dans l'état initial 1 , le "NAS" 1 10 génère un défi et envoie au pair 100 un message de défi PPP CHAP si qui inclut le défi. Dans une réalisation alternative de l'authentification PPP CHAP-RADIUS, non représentée sur la figure 3, le "NAS" 1 10 délègue la génération du défi au serveur RADIUS 120 : le serveur "NAS" 1 10 envoie une requête RADIUS "Access- Requ est" au serveur RADIUS 120 qui répond par une réponse RADIUS "Access-Challenge" qui contient le défi dans un attribut RADIUS "Reply-Message". Dans le message de défi PPP CHAP si il est possible de préciser dans le champ c6 l'identification du "NAS" 1 10 qui envoie le message. Dans la réalisation alternative de l'authentification où le défi est généré par le serveur RADIUS 120, il est possible de préciser dans le champ c6 l'identification du serveur RADIUS 120 qui a généré le défi.
Dans une étape 3, consécutive à la réception du message de défi PPP CHAP si , le pair 100 extrait la valeur du défi du message de défi PPP CHAP si et calcule une réponse à ce défi. La réponse est calculée par application d'une fonction de hachage MD5 à une donnée constituée de la valeur du champ c2 du message de défi PPP CHAP si , suivie d'un secret détenu par le pair 100, suivie de la valeur du défi reçue dans le message de défi PPP CHAP si et qui figure dans le champs c5 du message si . En fin d'étape 3, le pair 100 envoie la réponse dans un message de réponse PPP CHAP s2. Le champ c6 est utilisé pour préciser l'identifiant du pair 100 qui émet le message.
Dans une étape 4, consécutive à la réception du message de réponse PPP CHAP s2, le "NAS" 1 10 génère une requête RADIUS "Access-Request" s3 à l'attention du serveur RADIUS 120. La requête comprend les attributs RADIUS suivants :
- un attribut RADIUS "User-name" dont la valeur est l'identifiant du pair 100. La valeur de l'attribut RADIUS "User-name" est récupérée dans le champ c6 du message de réponse PPP CHAP s2, - un attribut RADIUS "CHAP-Challenge" dont la valeur correspond au défi calculé par le "NAS" 1 10 au cours de l'étape 2. Dans la réalisation alternative de l'authentification où le défi a été généré par le serveur RADIUS 120 à l'étape 2, l'attribut "CHAP-Challenge" peut ne pas être envoyé,
- un attribut RADIUS "CHAP-Password" dont la valeur est constituée de l'identifiant du message PPP CHAP si précisé dans le champ c2 du message PPP CHAP si et de la réponse au défi reçue à l'étape 4 dans le message de réponse PPP CHAP s2. Dans la réalisation alternative de l'authentification où le défi a été généré par le serveur RADIUS 120 à l'étape 2, et dans le cas où l'attribut "CHAP-Challenge" n'est pas envoyé dans la requête RADIUS "Access- Request" s3, l'attribut "CHAP-Password" n'est pas inséré dans la requête RADIUS "Access-Request" s3,
- dans la réalisation alternative de l'authentification où le défi a été généré par le serveur RADIUS 120 à l'étape 2, et dans le cas où l'attribut "CHAP-Challenge" n'est pas envoyé dans la requête RADIUS "Access-Request" s3, ladite requête comprend un attribut "User-Password". La valeur de l'attribut "User-Password" est constituée de l'identifiant du message PPP CHAP si précisé dans le champ c2 du message PPP CHAP si et de la réponse au défi reçue à l'étape 4 dans le message de réponse PPP CHAP s2.
En fin d'étape 4, le "NAS" 1 10 envoie au serveur RADIUS 120 la requête RADIUS "Access-Request" s3. Dans une étape 5, consécutive à la réception de la requête RADIUS
"Access-Request" s3 émise en étape 4, le serveur RADIUS 120 vérifie l'authentification de l'utilisateur. Pour cela il calcule une valeur d'authentification à l'aide de la même fonction de hachage MD5 que celle utilisée par le pair 100 qu'il applique à un flux d'octets constitué du défi présent dans l'attribut "CHAP- Challenge" de la requête RADIUS "Access-Request" s3, suivi du secret de l'utilisateur qu'il détient et de l'identifiant du message PPP CHAP si présent dans l'attribut "CHAP-password" de la requête RADIUS "Access-Request" s3. Le serveur RADIUS 120 compare la valeur d'authentification à la réponse au défi présente dans l'attribut "CHAP-Challenge" de la requête RADIUS "Access- Request" s3. Dans la réalisation alternative de l'authentification où le défi a été généré par le serveur RADIUS 120 à l'étape 2 et où le défi n'a pas été envoyé dans la requête RADIUS "Access-Request" s3, le serveur d'authentification utilise le défi qu'il détient pour calculer la valeur d'authentification et le contenu de l'attribut "User-Password" qui contient la réponse au défi pour vérifier l'authentification. Si la valeur d'authentification est égale à la réponse au défi alors l'authentification a réussi, sinon, elle a échoué. Dans les deux cas, le serveur RADIUS 120 renvoie, en fin d'étape 5, un message s4 au "NAS" 1 10 précisant le résultat de l'authentification. Dans le cas d'une authenti fi cation réussie le message s4 est une réponse RADIUS " Access- Accept". Dans le cas où l'authentification a échoué, le message s4 est une réponse RADIUS "Access-Reject". Dans une étape 6, consécutive à la réception du message s4, le "NAS"
1 10 génère un message de réponse s5 à l'attention du pair 100. Le message s5 est un message PPP CHAP de type "CHAP-Success" si l'authentification a réussi et un message PPP CHAP "CHAP-Failure" si l'authentification a échoué. A la fin de l'étape 6, le "NAS" 1 10 envoie le message de réponse s5 au pair 100.
Dans une étape 7, consécutive à la réception du message de réponse s5, le pair 100 est autorisé ou non à accéder à la ressource physique.
La figure 4 illustre le mécanisme d'authentification conforme à la méthode EAP MD5-Challenge selon l'état de la technique en décrivant les échanges de messages entre les trois entités concernées par le processus d'authentification. Un pair 130 souhaite accéder à une ressource physique du réseau et s'adresse à un authentifiant 140 qui réalise le contrôle d'accès à la ressource physique. Un serveur d'authentification 150 est en charge de l'authentification du pair 130.
Le format d'un message de requête ou de réponse EAP est conforme au format illustré par la figure 2.
Dans une étape initiale 1 1 , l'authentifiant 140 envoie au pair 130 une requête EAP s10 de demande d'identité. Conformément au format de messages EAP décrit dans la figure 2, le message contient dans le champ c10 une valeur qui correspond au type "Identity". Dans une étape 12, consécutive à la réception de la requête EAP s10 de demande d'identité, le pair 130 construit un message de réponse EAP si 1 qui contient l'identité du pair 130 dans le champ d 1 du message de réponse EAP si 1 . Le pair 130 envoie le message de réponse EAP si 1 à l'authentifiant 140. Dans une étape 13, consécutive à la réception du message de réponse
EAP s1 1 , l'authentifiant relaie le message de réponse EAP s1 1 au serveur d'authentification 150 dans un message de réponse EAP s12.
Dans une étape 14, consécutive à la réception du message de réponse EAP s12, le serveur d'authentification 150 génère un défi et un message de requête EAP s13 de type EAP MD5-Challenge. Le message de requête EAP s13 contient le défi dans le champ c13 du message. En plus du défi il est possible de préciser l'identité du serveur d'authentification à l'origine du message de requête dans le champ c14. Le serveur d'authentification 150 envoie le message de requête EAP s13 à l'authentifiant 140. Dans une étape 15, consécutive à la réception du message de requête
EAP s13, l'authentifiant 140 relaie le message de requête EAP s13 au pair 130 dans un message de requête EAP s14.
Dans une étape 16, consécutive à la réception du message de requête EAP s14, le pair 130 extrait le défi du message de requête EAP s13 et l'utilise pour construire une réponse. La réponse est calculée par application de la fonction de hachage MD5 à un flux d'octets constitué du défi, suivi du secret détenu par le pair 130 et de l'identifiant du message de requête s14 récupéré dans le champ c8 du message. Le pair 130 envoie une réponse EAP s15 à l'authentifiant 140 qui contient la réponse au défi dans le champ c13. Le champ c14 de la réponse EAP s15 peut être utilisé pour préciser l'identité du pair 130 qui émet la réponse.
Dans une étape 17, consécutive à la réception de la réponse EAP s15, l'authentifiant 140 relaie la réponse EAP s15 au serveur d'authentification 150 dans un message de réponse EAP si 6. Dans une étape 18, consécutive à la réception du message de réponse
EAP s16, le serveur d'authentification 150 vérifie l'authentification du pair 130. Pour cela il calcule une valeur d'authentification en appliquant le fonction de hachage MD5 à un flux d'octets constitué du défi qu'il a généré à l'étape 14, suivi du secret propre au pair 130 qu'il détient et de l'identifiant des messages de requête et de réponse qui figure dans le champ c8 du message de réponse EAP s16. Si la valeur d'authentification est égale à la réponse au défi qui figure dans le champ c17 du message de réponse EAP s16, alors l'authentification du pair 130 a réussi, sinon elle a échoué. Dans les deux cas, le serveur d'authentification 150 génère un message EAP s17 précisant le résultat de l'authentification. Dans le cas d'une authentification réussie le message EAP s17 est un message EAP de type "EAP Success". Dans le cas où l'authentification a échoué, le message EAP s17 est un message EAP de type "EAP Failure". Le serveur d'authentification 150 envoie le message EAP s17 à l'authentifiant 140.
Dans une étape 19 consécutive à la réception du message EAP s17 envoyé par le serveur d'authentification 150 à l'étape 18, l'authentifiant 140 relaie le message EAP s17 au pair 130 dans un message EAP"s18.
Dans une étape 20, consécutive à la réception du message EAP s18, le pair 130 est accède ou non à la ressource physique.
Dans une réalisation particulière de l'authentification EAP, tous les messages EAP échangés entre l'authentifiant 140 et le serveur d'authentification 150 sont encapsulés dans des messages conformes à un protocole de type AAA (Authentication, Authorization and Accounting), par exemple RADIUS.
La figure 5 illustre un mécanisme d'authentification qui met en œuvre un procédé de traduction de messages d'authentification EAP MD5-Challenge en messages d'authentification PPP CHAP-RADIUS selon l'invention en décrivant des échanges de messages qui interviennent entre les entités concernées par le processus d'authentification ainsi que des traitements. Nous reprenons des termes de la terminologie EAP pour désigner les entités concernées par le processus d'authentification.
Un pair EAP 160 correspond au client à authentifier qui souhaite accéder à une ressource physique et qui pour cela doit s'authentifier. Un authentifiant 170 est le système authentifiant qui réalise le contrôle d'accès à la ressource physique. Un traducteur 180, spécifique à la présente invention met en œuvre le procédé selon l'invention et traduit des messages d'authentification conformes au protocole EAP et à la méthode EAP MD5-Challenge en messages conformes au protocole d'authentification PPP CHAP-RADIUS. Un module de traduction 181 est un programme destiné à être stocké dans une mémoire du traducteur 180 ; il comporte des instructions pour mettre en œuvre le procédé de traduction selon l'invention. Il gère une donnée interne 182 appelée contexte de conversation EAP courante destinée à stocker des informations de la conversation EAP en cours comme par exemple et de façon non exhaustive un identifiant de la conversation EAP en cours, la méthode d'authentification EAP choisie pour la conversation courante. Ces informations sont reçues au cours des échanges avec l'authentifiant 170 et un serveur RADIUS 190. Le serveur RADIUS 190 est en charge de l'authentification du pair EAP 160. Ce serveur RADIUS ne dispose pas de la fonction EAP lui permettant d'authentifier des clients EAP.
Dans une réalisation particulière de l'invention, tous les messages échangés entre le pair 160 et l'authentifiant 170 sont encapsulés dans un tunnel sécurisé, par exemple dans des messages conformes à EAP-TTLS. Dans une réalisation particulière de l'invention, tous les messages échangés entre l'authentifiant 170 et le traducteur 180 sont encapsulés dans des messages conformes à un protocole de type AAA, par exemple RADIUS.
Dans une étape initiale 22, l'authentifiant 170 génère et envoie un message de demande d'identité s20 au pair EAP 160. Conformément au format de messages EAP décrit dans la figure 2, le message contient dans le champ c10 une valeur qui correspond au type "Identity".
Dans une étape 23, consécutive à la réception du message EAP de demande d'identité s20, le pair EAP 160 génère et envoie un message de réponse EAP s21 contenant son identité dans le champ d 1 . Dans une étape 24, consécutive à la réception du message de réponse
EAP s21 , l'authentifiant 170 relaie le message de réponse EAP s21 au traducteur 180 dans un message EAP s22. Dans une étape 25, consécutive à la réception du message de réponse EAP s22, le traducteur 180 analyse le message de réponse EAP s22. Le traducteur 180 récupère dans le champ c1 1 du message de réponse EAP s22 l'identité du pair EAP 160 à authentifier et stocke cette identité dans le contexte de la conversation EAP courante 182. Le contexte de la conversation EAP courante 182 est identifié de façon unique, entre autre grâce à un identifiant qui figure dans le champ c8 du message de réponse EAP s22 de type "Identity". Le traducteur 180 fait le choix d'une méthode d'authentification pour la conversation EAP courante qui est EAP MD5-Challenge. Le choix de la méthode EAP MD5-Challenge résulte de diverses considérations : l'identité du pair EAP 160, un identifiant de l'authentifiant 170 et toute autre information complémentaire dont le traducteur 180 dispose et qui lui permet de caractériser l'utilisateur associé au pair 160 et l'authentifiant 170 qui est le point d'accès. Les informations qui caractérisent l'utilisateur et le point d'accès au réseau sont avantageusement enregistrées dans le contexte de la conversation EAP courante 182. Le traducteur 180 enregistre le choix de la méthode EAP MD5- Challenge dans le contexte de conversation EAP courante 182. Le traducteur 180 choisit de traduire l'authentification EAP MD5-Challenge en PPP CHAP- RADIUS afin d'externaliser l'authentification vers un serveur RADIUS 190 qui ne dispose pas de la fonction EAP. Le traducteur choisit le serveur RADIUS par lequel il souhaite faire réaliser l'authentification. Pour faire ce choix, le traducteur 180 s'appuie sur différentes informations dont il dispose sur le pair EAP : l'identité du pair EAP stockée dans le contexte de la conversation EAP courante 182 et toute autre information dont dispose le traducteur 180 via un accès à un autre serveur ou à une base de données et qui permet de caractériser l'utilisateur associé au pair EAP 160 et l'authentifiant 170 qui est le point d'accès au réseau. Ces informations sont stockées dans le contexte de la conversation EAP courante 182. Le traducteur 180 détermine qu'il doit demander au serveur RADIUS 190 de générer un défi et envoie une requête RADIUS "Access-Request" s23 au serveur RADIUS 190. Dans une réalisation alternative de l'invention, le traducteur 180 choisit de générer lui-même le défi. Dans ce cas, aucun échange de messages n'a lieu avec le serveur RADIUS 190.
Dans une étape 26 consécutive à la réception de la requête RADIUS "Access- Request" s23, le serveur RADIUS 190 génère le défi et envoie au traducteur 180 une réponse RADIUS "Access-Challenge" s24 qui contient le défi dans un attribut RADIUS "Reply-Message".
Dans une étape 27 consécutive à la réception de la réponse RADIUS s24, le traducteur 180 génère un message EAP de défi s25. Le défi reçu du serveur RADIUS 190 dans la réponse RADIUS s24 est inséré dans le champ c13 d'un message EAP de défi s25. Dans la réalisation alternative de l'invention où le traducteur 180 choisit de générer lui-même le défi, le défi est inséré dans le champ c13 du message EAP de défi s25 et stocké dans le contexte de la conversation EAP courante 182. Le traducteur 180 stocke la façon dont a été généré le défi dans le contexte de la conversation courante EAP 182. Le champ c14 du message EAP de défi s25 est avantageusement utilisé pour préciser l'identité du serveur d'authentification 190 qui a généré le défi. Dans la réalisation alternative de l'invention où le traducteur 180 choisit de générer lui-même le défi, le champ c14 du message EAP de défi s25 est avantageusement utilisé pour préciser l'identité du traducteur 180 à l'origine du message EAP de défi s25. Le traducteur 180 envoie le message EAP de défi s25 à l'authentifiant 170 en fin d'étape 27.
Dans une étape 28, consécutive à la réception du message EAP de défi s25, l'authentifiant 170 relaie le message EAP de défi s25 au pair EAP 160 dans un message EAP de défi s26. Dans une étape 29, consécutive à la réception du message EAP de défi s26, le pair EAP 160 extrait le défi du champ c13 du message EAP de défi s26 et génère un message de réponse EAP s27. Pour cela, le pair EAP 160 calcule une réponse au défi en appliquant la fonction de hachage MD5 à un flux d'octets constitué de la valeur du défi, suivi d'un secret propre au pair EAP 160, suivi de l'identifiant du message s26 extrait du champ c8 du message EAP de défi s26. La réponse au défi est insérée dans le champ c13 du message de réponse EAP s27. Le champ c14 du message de réponse EAP s27 peut avantageusement être utilisé pour préciser l'identité du pair EAP 160. Le pair EAP 160 envoie le message de réponse EAP s27 à l'authentifiant 170.
Dans une étape 30, consécutive à la réception du message de réponse EAP s27, l'authentifiant 170 relaie le message de réponse EAP s27 au traducteur 180 dans un message s28.
Dans une étape 31 , consécutive à la réception du message de réponse EAP s28, le traducteur 180 analyse le message de réponse EAP s28. Il récupère dans le champ c13 la réponse au défi et dans le champ c14, s'il est renseigné, le nom de l'entité qui a émis le message. Le traducteur stocke la réponse au défi et, éventuellement l'identité de l'entité qui a émis le message dans le contexte de la conversation EAP courante 182. Dans une réalisation alternative de l'invention, où le choix d'externaliser l'authentification vers un serveur RADIUS n'a pas été fait au cours de l'étape 25, ce choix est fait maintenant ainsi que le choix du serveur RADIUS. Pour faire ce choix, le traducteur 180 s'appuie sur différentes informations dont il dispose sur le pair EAP 160 : l'identité du pair EAP 160 stockée dans le contexte de la conversation EAP courante 182, l'émetteur du message de réponse à la requête de défi et toute autre information dont dispose le traducteur 180 via un accès à un autre serveur ou à une base de données et qui permet de caractériser l'utilisateur associé au pair EAP 160 et l'authentifiant 170 qui est le point d'accès au réseau. Le traducteur 180 construit une requête RADIUS "Access- Request" s29 qui contient des informations d'authentification nécessaires au serveur RADIUS 190 pour réaliser l'authentification du pair EAP 160. En particulier des informations d'authentification récupérées dans des étapes précédentes sont utilisées par le traducteur 180 afin de générer des attributs RADIUS d'authentification suivants :
- un attribut "User-Name" qui correspond à l'identité de l'utilisateur associé au pair EAP 160. L'identité de l'utilisateur est par exemple et de façon non exhaustive une adresse MAC (Media Access Control pour contrôle d'accès au média), une adresse IP du pair EAP 160 ou l'identité insérée dans le champ c14 du message s27 par le pair EAP. La valeur de cet attribut est obtenue à partir d'informations contenues dans des champs de messages précédemment échangés et stockées au fur et à mesure dans le contexte de conversation EAP courante 182. Le traducteur 180 utilise tout ou partie de ces informations pour construire l'attribut "User-Name" : le champ d 1 du message de réponse EAP s22 à la demande d'identité reçu par le traducteur 180 dans l'étape 25. Dans une réalisation particulière de l'invention où le message de réponse EAP s22 a été encapsulé dans un message RADIUS, une copie du champ c1 1 est contenue dans l'attribut "User-Name" du message RADIUS s22. le champ c14 du message de réponse EAP s28 qui contient avantageusement l'identité du pair EAP 160. toute autre information permettant d'identifier l'utilisateur. Dans une réalisation particulière de l'invention où les messages EAP échangés entre l'authentifiant 170 et le traducteur 180 sont encapsulés dans un protocole de type AAA, comme par exemple RADIUS, des attributs de ce protocole sont avantageusement utilisés.
Dans une réalisation particulière de l'invention, le traducteur 180 complète l'attribut "User-Name" ou crée un identifiant à partir d'informations propres à l'utilisateur qu'il détient, par exemple des informations stockées dans une base de données à laquelle le traducteur 180 a accès. - un attribut "CHAP-Password" qui précise l'identifiant du message de réponse EAP s28 et la réponse au défi extraite du champ c13 du message de réponse s28. L'attribut "CHAP-Password" est renseigné dans le cas où le défi est stocké par le traducteur 180 et envoyé au serveur RADIUS 190 dans la requête RADIUS s29, dans un attribut RADIUS "CHAP-Challenge" ou dans le champ "Authenticator" de la requête RADIUS s29.
- un attribut "User-Password" qui contient l'identifiant du message de réponse EAP s28 et la réponse au défi extraite du champ c13 du message de réponse EAP s28. L'attribut "User-Password" est renseigné dans le cas où le défi n'est pas envoyé par la traducteur 180 au serveur RADIUS 190 dans la requête RADIUS S29.
Dans la réalisation alternative de l'invention où le traducteur 180 génère lui- même le défi, le traducteur 180 précise dans un attribut "CHAP-Challenge" ou dans le champ "Authenticator" de la requête RADIUS s29, la valeur du défi et dans un attribut "CHAP-Password" l'identifiant du message de réponse EAP s28 et la réponse au défi extraite du champ c13 du message de réponse EAP s28. Dans une réalisation particulière de l'invention des traitements complémentaires de type proxy sont également mis en œuvre par le traducteur 180. Ainsi, des informations connues du traducteur 180 sont envoyées au serveur RADIUS 190 dans des attributs RADIUS. Les informations sont par exemple et de façon non exhaustive la précision par le traducteur 180 d'informations associées à l'authentifiant 170 ou au pair EAP 160 et qui pourraient être utiles au serveur RADIUS.
La requête RADIUS "Access-Request" s29 construite par le traducteur 180 est envoyée en fin d'étape 31 au serveur RADIUS 190.
Dans une étape 32, consécutive à la réception de la requête RADIUS "Access-Request" s29 le serveur d'authentification 190 vérifie l'authentification de l'utilisateur de la même manière que pour la méthode PPP CHAP.
Le serveur RADIUS 190 envoie un message de résultat de l'authentification s30 au traducteur 180. Le message de résultat de l'authentification s30 est une réponse RADIUS "Access-Accept" dans le cas où l'authentification a réussi et une réponse RADIUS "Access- Reject" en cas d'échec.
Dans une étape 33, consécutive à la réception du message de résultat de l'authentification s30, le traducteur 180 analyse le message de résultat de l'authentification s30 et prépare la traduction dudit message s30 en un message EAP. La préparation de la traduction consiste à choisir un message à envoyer au système authentifiant comme résultat de l'authentification. Le traducteur fait le choix du message de réponse en fonction de la réponse RADIUS reçue, et/ou de valeurs d'attributs RADIUS de la réponse RADIUS, et/ou de conditions internes au traducteur. Dans un exemple de réalisation de l'invention, le traducteur génère un message de réponse s31 qui est un message EAP "EAP- Success" dans le cas où le message s30 est une réponse RADIUS "Access- Accept" et un message EAP "EAP-Failure" dans le cas où le message s30 est une réponse RADIUS "Access- Reject". Dans une réalisation particulière de l'invention, des traitements de type proxy sont également possibles pour adapter le message de réponse s31 en fonction de critères définis dans le traducteur 180. Le message de réponse s31 est envoyé à l'authentifiant 170 en fin d'étape 33.
Dans une étape 34, consécutive à la réception du message de réponse s31 , l'authentifiant 170 relaie le message de réponse EAP s31 "EAP-Success" ou "EAP-Failure" au pair EAP 160 dans un message s32.
Dans une étape 35 consécutive à la réception du message s32, le pair EAP 160 accède ou non à la ressource physique.
Pour des raisons de clarté, les mécanismes propres aux protocoles EAP et RADIUS liés à des réémissions de messages et à des stockages d'informations nécessaires aux réémissions ne sont pas décrits.
La figure 6 illustre les échanges de messages qui ont lieu dans une seconde variante du procédé de traduction selon l'invention dans laquelle les fonctions du traducteur tel que présenté à la figure 5 sont intégrées dans le système authentifiant. Un pair EAP 200 est le client à authentifier. Un authentifiant-traducteur 210 est le système authentifiant qui réalise le contrôle d'accès à la ressource physique et qui intègre les fonctions du traducteur. Un serveur RADIUS 220 réalise le contrôle d'accès du pair EAP 200.
Les étapes 41 , 42, 44, 46, 48, 50 sont identiques/de même type que les étapes 22, 23, 26, 29, 32, 35 décrites en référence à la figure 5.
Dans une étape 43, comparable à l'étape 25 de la figure 6, l'authentifiant- traducteur 210 détermine que la méthode d'authentification EAP à utiliser est EAP MD5-Challenge et qu'il doit demander au serveur RADIUS 220 de générer un défi. L'authentifiant-traducteur 210 envoie une requête RADIUS "Access- Request" s42 au serveur RADIUS 220. Dans une réalisation alternative de l'invention, l'authentifiant-traducteur 210 choisit de générer lui-même le défi. Dans ce cas, aucun échange de messages n'a lieu avec le serveur RADIUS 220. Dans une étape 45 consécutive à la réception d'une réponse RADIUS "Access-Challenge" s43 (qui est de même type que la réponse s24 selon la figure 5) qui contient le défi demandé à l'étape 43, l'authentifiant-traducteur 210 génère un message EAP de défi s44. Le défi reçu du serveur RADIUS 220 dans la réponse RADIUS "Access-Challenge" s43 est inséré dans le champ c13 d'un message EAP de défi s44.
Dans une réalisation alternative de l'invention où l'authentifiant-traducteur 210 génère lui-même le défi, le défi est inséré dans le champ c13 du message EAP de défi s44. De façon avantageuse l'identité de l'authentifiant-traducteur 210 est précisée dans le champ c14 du message EAP de défi s44. Le message EAP de défi s44 est envoyé au pair EAP 200 en fin d'étape 45.
Dans une étape 47, consécutive à la réception d'un message de réponse EAP s45 (qui est de même type que le message s27 selon la figure 5) un traitement comparable à celui réalisé par le traducteur à l'étape 31 selon la figure 5 est réalisé. L'authentifiant-traducteur 210 génère une requête RADIUS "Access- Request" s46 à partir des informations d'authentification contenues dans les messages EAP échangés dans des étapes précédentes. La requête RADIUS "Access- Request" s46 comprend plusieurs attributs RADIUS : - un attribut "User-Name" dans lequel l'authentifiant-traducteur 210 insère l'identifiant de l'utilisateur associé au pair EAP 200 qui peut être constitué d'informations récupérées dans le champ d 1 du message EAP s41 et dans le champ c14 du message EAP s41 . Dans une réalisation particulière de l'invention, l'authentifiant-traducteur 210 complète l'attribut "User-Name" ou crée un identifiant à partir d'informations propres à l'utilisateur qu'il détient, par exemple des informations stockées dans une base de données à laquelle l'authentifiant-traducteur 210 a accès. - un attribut "CHAP-Password" dans lequel l'authentifiant-traducteur 210 copie l'identifiant du message de réponse EAP s45 qui est l'identifiant de la conversation EAP courante et la réponse au défi extraite du champ c13 du message de réponse EAP s45. L'attribut "CHAP-Password" est renseigné dans le cas où le défi est stocké par l'authentifiant-traducteur 210 et envoyé au serveur RADIUS 220 dans la requête RADIUS s46, dans un attribut RADIUS "CHAP-Challenge" ou dans le champ "Authenticator" de ladite requête. - un attribut "User-Password" qui contient l'identifiant du message de réponse s45 et la réponse au défi extraite du champ c13 du message de réponse EAP s45. L'attribut "User-Password" est renseigné dans le cas où le défi n'est pas envoyé par l'authentifiant-traducteur 210 au serveur RADIUS 220 dans la requête RADIUS s46.
Dans la réalisation alternative de l'invention où l'authentifiant-traducteur 210 génère lui-même le défi, l'authentifiant-traducteur 210 précise dans un attribut "CHAP-Challenge" ou dans le champ "Authenticator" de la requête RADIUS s46, la valeur du défi et dans un attribut "CHAP-Password" l'identifiant du message de réponse EAP s45 et la réponse au défi extraite du champ c13 du message de réponse EAP s45.
Dans une réalisation particulière de l'invention des traitements complémentaires de type proxy sont également mis en œuvre par l'authentifiant-traducteur 210 qui envoie des informations dans des attributs RADIUS au serveur RADIUS 220. Le message de réponse EAP s46 est envoyé au serveur RADIUS 220.
Dans une étape 49, consécutive à la réception d'un message de résultat de l'authentification s47 (qui est de même type que le message s30), l'authentifiant-traducteur 210 génère un message de réponse s48 à l'attention du pair EAP 200 qui est un message EAP "EAP-Success" dans le cas où le message s47 est une réponse RADIUS "Access-Accept" et un message EAP "EAP-Failure" dans le cas où le message s47 est une réponse RADIUS "Access-Reject". Dans une réalisation particulière de l'invention, des traitements de type proxy sont également possibles pour adapter le message de réponse s48 en fonction de critères définis dans l'authentifiant-traducteur 210.
Dans une étape 50 consécutive à la réception du message de réponse s48 le pair EAP 200 accède ou non à la ressource physique. La figure 7 est un schéma représentant un exemple d'architecture de réseau où sont représentées les entités qui interviennent dans le procédé de traduction selon l'invention.
Le pair EAP 160 (le terme couramment utilisé est le terme anglais "peer") souhaite accéder à une ressource physique d'un réseau 250 de type IP contrôlée par l'authentifiant 170 qui constitue un point d'accès au réseau. Le pair EAP 160 doit au préalable s'authentifier. Le serveur RADIUS 190 vérifie que le pair EAP 160 est authentifié et a le droit d'accéder à la ressource physique du réseau 250. Le serveur RADIUS 190 ne dispose pas de la fonction EAP.
Le pair EAP 160, pour s'authentifier, dialogue avec l'authentifiant 170 conformément à la méthode d'authentification EAP MD5-Challenge. L'authentifiant 170 demande au serveur RADIUS 190 de vérifier si le pair EAP 160 a le droit d'accéder à la ressource. Pour cela, le pair EAP 160 dialogue avec le traducteur 180, spécifique à l'invention, qui traduit les messages d'authentification EAP MD5-Challenge en des messages d'authentification PPP CHAP-RADIUS compréhensibles par le serveur RADIUS 190. Le traducteur 180 fournit au serveur RADIUS 190 les données d'authentification propres au pair EAP 160 et reçues de l'authentifiant 170. Il reçoit du serveur RADIUS 190 le résultat de l'authentification. Il traduit ce résultat à l'attention de l'authentifiant 170. L'authentifiant 170 informe le pair EAP 160 du résultat de l'authentification.
La figure 8 est un schéma représentant une seconde variante de l'architecture de réseau où sont représentées les entités qui interviennent dans le procédé de traduction selon l'invention. Dans cette variante l'authentifiant- traducteur 210, spécifique à l'invention est le système authentifiant qui réalise les fonctions de l'authentifiant 170 et du traducteur 180 selon la figure 7.
La figure 9 est un schéma illustrant l'organisation fonctionnelle d'un traducteur et d'un authentifiant-traducteur selon l'invention.
Le traducteur 180 est composé des modules fonctionnels principaux suivants : - un module d'obtention d'un défi 281 qui est une valeur aléatoire. Le défi est généré par le module ou obtenu par le module suite à une requête de génération faite auprès d'un serveur d'authentification.
- un module d'émission de messages 282. Ce module est chargé d'envoyer des messages préparés par un module de traitement de messages ou le module d'obtention d'un défi 281 vers une entité externe. Il dispose pour cela de plusieurs interfaces externes : une interface i282-1 pour émettre des messages vers un serveur d'authentification et une interface i282-3 pour émettre des messages vers un authentifiant. - un module de réception des messages 283. Ce module reçoit des messages d'entités externes via plusieurs interfaces : une interface i283-1 pour recevoir les messages envoyés par l'authentifiant et une interface i283-3 pour recevoir des messages de du serveur d'authentification. Il transmet les messages reçus à un module de traitement. - un module de traitement 284. Ce module analyse des messages reçus du module de réception de messages 283, traduit des données d'authentification d'un protocole en un autre et génère des messages à envoyer par le module d'émission de messages 282.
- un module de choix d'une méthode d'authentification 285 supportée par EAP.
Un canal de communication 288 permet aux modules d'échanger des informations. Par exemple le module d'obtention d'un défi 281 peut transmettre au module d'émission de messages 282 une requête de demande de défi que le module d'émission de messages 282 envoie à un serveur d'authentification. L'authentifiant-traducteur 210 comprend les mêmes modules fonctionnels que le traducteur 180. Le module d'émission de messages 282 diffère de celui du traducteur 180 en ce qu'il possède une interface i282-2 lui permettant d'émettre des messages à l'attention d'un pair et en ce qu'il ne dispose pas de l'interface i282-3 avec l'authentifiant. Le module de réception de messages 283 de l'authentifiant-traducteur 210 diffère de celui du traducteur 180 en ce qu'il ne dispose pas de l'interface i283-1 avec l'authentifiant et en ce qu'il dispose d'une interface i283-2 lui permettant de recevoir des messages du pair.
Les blocs fonctionnels décrits ci-avant et les interfaces sont avantageusement implémentés sous forme de programmes stockés dans une mémoire du traducteur 180, respectivement de l'authentifiant-traducteur 210, et exécutés par un processeur dudit traducteur, respectivement dudit authentifiant- traducteur.
La figure 10 est un schéma qui présente les principaux composants d'un traducteur 180 selon l'invention.
Un processeur 360 (le terme couramment utilisé est "CPU" : "Central Processing Unit" pour unité centrale de traitement) est un composant central où sont effectués les principaux calculs. En particulier, il exécute des programmes chargés dans une mémoire vive 365 (le terme couramment utilisé est "RAM" pour "Random Access Memory") qui stocke les données qui vont être traitées par le processeur 360.
Des périphériques 370 assurent les communications entre le processeur et le monde extérieur. Ils ne sont pas détaillés sur le schéma pour des raisons de clarté. Par exemple et de façon non exhaustive un périphérique est un module de raccordement au réseau, un disque amovible.
Un bus 375 permet le transfert des données entre les composants du traducteur 180.
Un programme 380 de traduction propre à l'invention, est stocké dans un périphérique non représenté sur le schéma. Il comprend des modules fonctionnels tels que décrits à la figure 9 et implémentés sous forme d'instructions du programme. Il est chargé en mémoire vive 365 pour exécution des instructions par le processeur.
La figure 10 s'applique également à un authentifiant-traducteur 210 selon la figure 6. Les principaux composants de l'authentifiant-traducteur sont identiques à ceux du traducteur 180. Seul le programme 380 de traduction est différent. Dans le cas de l'authentifiant-traducteur, un programme spécifique comprend des modules fonctionnels tels que décrits à la figure 9, implémentés sous forme d'instructions du programme. Ledit programme est chargé en mémoire vive 365 pour exécution des instructions par le processeur.

Claims

REVENDICATIONS
1 . Procédé de traduction de messages conformes à un premier protocole d'authentification en messages conformes à un deuxième protocole d'authentification au cours d'une phase d'authentification pendant laquelle un pair (160), doté d'une identité et qui souhaite accéder à une ressource d'un réseau (250) se connecte à un authentifiant (170), ledit authentifiant autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification (190) en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, caractérisé en ce que le procédé de traduction comprend :
- une étape (25) consistant à recevoir l'identité du pair dans un message conforme au premier protocole d'authentification,
- une étape (27) consistant à générer un défi et à envoyer ledit défi, - une étape (31 ) consistant à recevoir une première réponse qui est une réponse audit défi, à générer une demande d'accès au réseau conforme au deuxième protocole d'authentification et à envoyer ladite demande au serveur d'authentification,
- une étape (33) consistant à recevoir une deuxième réponse qui est une réponse à ladite demande, à traduire la deuxième réponse pour générer un résultat d'authentification conforme au premier protocole d'authentification.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comprend une étape de choix d'une méthode d'authentification supportée par le premier protocole d'authentification.
3. Procédé selon l'une des revendications précédentes, caractérisé en ce que la génération du défi comprend :
- une étape consistant à demander (25) ledit défi au serveur d'authentification (190),
- recevoir (27) ledit défi.
4. Procédé d'authentification d'un pair (200), doté d'une identité et qui pour accéder à une ressource d'un réseau (250) se connecte à un authentifiant- traducteur (210) conformément à un premier protocole d'authentification, ledit authentifiant-traducteur autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification (220) en fonction de données d'authentification reçues dans des messages conformes à un deuxième protocole d'authentification, comprenant :
- une étape (41 ) consistant à envoyer une demande d'identité au pair,
- une étape (43) consistant à recevoir l'identité du pair dans un message conforme au premier protocole d'authentification,
- une étape (45) consistant à générer un défi et à envoyer ledit défi, caractérisé en ce que le procédé d'authentification intègre des fonctions de traduction de messages conformes au premier protocole d'authentification en messages conformes au deuxième protocole d'authentification et qu'il comprend :
- une étape (47) consistant à recevoir une première réponse qui est une réponse audit défi, à générer une demande d'accès au réseau conforme au deuxième protocole d'authentification et à envoyer ladite demande au serveur d'authentification, - une étape (49) consistant à recevoir une deuxième réponse qui est une réponse à ladite demande, à traduire la deuxième réponse pour générer un résultat d'authentification conforme au premier protocole d'authentification et à envoyer ledit résultat d'authentification.
5. Dispositif traducteur prévu pour traduire des messages conformes à un premier protocole d'authentification en messages conformes à un deuxième protocole d'authentification au cours d'une phase d'authentification pendant laquelle un pair (160), doté d'une identité et qui souhaite accéder à une ressource d'un réseau (250) se connecte à un authentifiant (170), ledit authentifiant autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification (190) en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, caractérisé en ce qu'il comprend :
- un module d'obtention d'un défi 281 ,
- un module d'émission 282 dudit défi et d'une demande d'accès au réseau,
- un module de réception 283 de l'identité du pair, d'une première réponse qui est une réponse audit défi et d'une deuxième réponse qui est une réponse à ladite demande d'accès au réseau,
- un module de traitement 284 qui génère la demande d'accès au réseau conforme au deuxième protocole d'authentification et traduit un résultat d'authentification conformément au premier protocole d'authentification.
6. Dispositif selon la revendication 4, caractérisé en ce qu'il comprend un module de choix 281 d'une méthode d'authentification supportée par le premier protocole d'authentification.
7. Dispositif authentifiant-traducteur (210) prévu pour authentifier un pair (200) doté d'une identité et qui pour accéder à une ressource d'un réseau (250), dialogue avec ledit dispositif conformément à un premier protocole d'authentification, ledit dispositif autorisant l'accès au réseau en fonction d'une vérification de l'identité et de droits du pair faite par un serveur d'authentification (220) en fonction de données d'authentification reçues dans des messages conformes au deuxième protocole d'authentification, comprenant :
- un module d'obtention d'un défi 281 , - un module d'émission 282 d'une demande d'identité du pair, dudit défi, d'une demande d'accès au réseau et d'un résultat d'authentification,
- un module de réception 283 de ladite identité, d'une première réponse qui est une réponse audit défi et d'une deuxième réponse qui est une réponse à ladite demande d'accès au réseau, caractérisé en ce qu'il est prévu pour traduire des messages conformes au premier protocole d'authentification en messages conformes au deuxième protocole d'authentification et qu'il comprend : - un module de traitement 284 qui génère la demande d'accès au réseau conforme au deuxième protocole d'authentification et traduit un résultat d'authentification conformément au premier protocole d'authentification.
8. Système d'authentification comprenant un pair (160, 200) souhaitant accéder à une ressource d'un réseau (250) et qui doit s'authentifier auprès d'un système authentifiant (170, 210) en envoyant des données d'authentification conformes à un premier protocole d'authentification, reçues et vérifiées par un serveur d'authentification (190, 220) selon un deuxième protocole d'authentification caractérisé en ce qu'il comprend :
- des moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole,
- des moyens pour authentifier le client.
9. Système d'authentification comprenant un pair (160, 200) souhaitant accéder à une ressource d'un réseau (250) et qui doit s'authentifier auprès d'un système authentifiant (170, 210) en envoyant des données d'authentification conforme à un premier protocole d'authentification, reçues et vérifiées par un serveur d'authentification (190, 220) selon un deuxième protocole d'authentification caractérisé en ce que les moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole sont réalisés par le dispositif traducteur selon la revendication 4.
10. Système d'authentification comprenant un pair (160, 200) souhaitant accéder à une ressource d'un réseau (250) et qui doit s'authentifier auprès d'un système authentifiant (170, 210) en envoyant des données d'authentification conforme à un premier protocole d'authentification, vérifiées par un serveur d'authentification (190, 220) selon un second protocole d'authentification caractérisé en ce que les moyens pour traduire les données d'authentification du premier protocole en données d'authentification du deuxième protocole et les moyens pour authentifier le client sont réalisés par le dispositif authentifiant- traducteur selon la revendication 5.
1 1 . Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé selon la revendication 1 lorsqu'il est exécuté par un microprocesseur (360).
12. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé selon la revendication 4 lorsqu'il est exécuté par un microprocesseur (360).
EP06764849A 2005-06-16 2006-06-07 Procede de traduction d'un protocole d'authentification Withdrawn EP1891771A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506136 2005-06-16
PCT/FR2006/050529 WO2006134291A1 (fr) 2005-06-16 2006-06-07 Procede de traduction d'un protocole d'authentification

Publications (1)

Publication Number Publication Date
EP1891771A1 true EP1891771A1 (fr) 2008-02-27

Family

ID=35788385

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06764849A Withdrawn EP1891771A1 (fr) 2005-06-16 2006-06-07 Procede de traduction d'un protocole d'authentification

Country Status (4)

Country Link
US (1) US20090113522A1 (fr)
EP (1) EP1891771A1 (fr)
CN (1) CN101204038A (fr)
WO (1) WO2006134291A1 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4479703B2 (ja) * 2006-08-29 2010-06-09 ブラザー工業株式会社 通信システムと管理装置
JP4305481B2 (ja) * 2006-08-29 2009-07-29 ブラザー工業株式会社 通信システムと管理装置と情報処理装置
JP4869033B2 (ja) * 2006-11-13 2012-02-01 キヤノン株式会社 ネットワークデバイス、ネットワークデバイス管理装置、ネットワークデバイスの制御方法、ネットワークデバイス管理方法、プログラム、記憶媒体
US20090288138A1 (en) * 2008-05-19 2009-11-19 Dimitris Kalofonos Methods, systems, and apparatus for peer-to peer authentication
JP5408910B2 (ja) * 2008-06-10 2014-02-05 キヤノン株式会社 ネットワーク機器管理装置およびその制御方法、プログラム、記憶媒体
US20110167477A1 (en) * 2010-01-07 2011-07-07 Nicola Piccirillo Method and apparatus for providing controlled access to a computer system/facility resource for remote equipment monitoring and diagnostics
KR20120072032A (ko) * 2010-12-23 2012-07-03 한국전자통신연구원 모바일 단말의 상호인증 시스템 및 상호인증 방법
CN103313239B (zh) * 2012-03-06 2018-05-11 中兴通讯股份有限公司 一种用户设备接入融合核心网的方法及系统
CN104378333B (zh) * 2013-08-15 2018-09-21 华为终端有限公司 调制解调器拨号方法及宽带设备
US10397233B2 (en) 2015-04-20 2019-08-27 Bomgar Corporation Method and apparatus for credential handling
US10129244B2 (en) * 2016-06-20 2018-11-13 Princeton SciTech, LLC Securing computing resources

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
US5537474A (en) * 1994-07-29 1996-07-16 Motorola, Inc. Method and apparatus for authentication in a communication system
JP2977476B2 (ja) * 1995-11-29 1999-11-15 株式会社日立製作所 機密保護方法
JPH10200524A (ja) * 1997-01-08 1998-07-31 Fujitsu Ltd ターミナルアダプタ
US6067623A (en) * 1997-11-21 2000-05-23 International Business Machines Corp. System and method for secure web server gateway access using credential transform
JP3570310B2 (ja) * 1999-10-05 2004-09-29 日本電気株式会社 無線ｌａｎシステムにおける認証方法と認証装置
US7287156B2 (en) * 2001-06-29 2007-10-23 International Business Machines Corporation Methods, systems and computer program products for authentication between clients and servers using differing authentication protocols
US6996714B1 (en) * 2001-12-14 2006-02-07 Cisco Technology, Inc. Wireless authentication protocol
US20040054905A1 (en) * 2002-09-04 2004-03-18 Reader Scot A. Local private authentication for semi-public LAN
US7350077B2 (en) * 2002-11-26 2008-03-25 Cisco Technology, Inc. 802.11 using a compressed reassociation exchange to facilitate fast handoff
EP1606904B1 (fr) * 2003-03-14 2018-11-28 Thomson Licensing Architecture de point d'accès wlan souple permettant d'adapter différents dispositifs d'utilisateurs
MXPA05009882A (es) * 2003-03-14 2006-03-13 Thomson Licensing Configuracion automatica de terminal del cliente en un punto publico de trabajo.
JP4173866B2 (ja) * 2005-02-21 2008-10-29 富士通株式会社 通信装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006134291A1 *

Also Published As

Publication number Publication date
CN101204038A (zh) 2008-06-18
WO2006134291A1 (fr) 2006-12-21
US20090113522A1 (en) 2009-04-30

Similar Documents

Publication Publication Date Title
EP3008872B1 (fr) Procédé d'authentification d'un terminal par une passerelle d'un réseau interne protégé par une entité de sécurisation des accès
EP1733533B1 (fr) Procede et systeme de gestion d'autorisation d'acces d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur a un reseau ip
EP1891771A1 (fr) Procede de traduction d'un protocole d'authentification
WO2015097357A1 (fr) Obtention de donnees de connexion a un equipement via un reseau
WO2005034468A1 (fr) Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation
EP2710779A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
EP1649665A2 (fr) PROCEDE ET SYSTEME DE DOUBLE AUTHENTIFICATION SECURISEE D UN UTILISATEUR LORS DE L ACCES A UN SERVICE PAR L’INTERM EDIAIRE D UN RESEAU DE TRANSMISSION DE DONNEES.
EP1762037A2 (fr) Procede et systeme de certification de l'identite d'un utilisateur
EP3041192B1 (fr) Infrastructure d'authentification de téléphones ip d'un système toip propriétaire par un système eap-tls ouvert
EP1964359B1 (fr) Procede et systeme de mise a jour des conditions d'acces d'un dispositif de telecommunication a des services delivres par un reseau de telecommunication
EP4387167A1 (fr) Procédé et système d'authentification d'un utilisateur auprès d'un serveur d'authentification
EP3679499B1 (fr) Enrôlement perfectionné d'un équipement dans un réseau sécurisé
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
EP4362391B1 (fr) Procédé de gestion d'accès d'un utilisateur à au moins une application, programme d'ordinateur et système associés
WO2007012786A2 (fr) Procede de mise en oeuvre d'une sequence d'authentifications
WO2007054657A2 (fr) Procede et dispositif de fourniture d'un identifiant de federation reseau a un fournisseur de service
WO2026021850A1 (fr) Authentification automatique par une passerelle pour l'accès à une ressource par un équipement
FR2947686B1 (fr) Systeme et procede evolutif de gestion et d'agregation de plusieurs identifiants autour d'un authentifiant polymorphe
WO2015181484A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
EP3360293A1 (fr) Moyens de gestion d'accès à des données
FR2872978A1 (fr) Procede d'authentification securise sur un reseau sans fil conforme a la norme 802.11, systeme et dispositif pour la mise en oeuvre du procede
FR2923110A1 (fr) Authentification securisee perfectionnee d'un client mobile.
WO2007034091A1 (fr) Procede d'enregistrement relativement a un service de communication, terminal et serveur associes
FR2943811A1 (fr) Procede d'authentification, entite electronique portable comportant un serveur d'authentification et station hote fonctionnant avec une telle entite electronique portable.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20071211

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: DURANTON, CLAIRE

Inventor name: CRASSOUS, MAGALI

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20120925

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130103