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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=35788385

Family Applications (1)

Country Status (4)

Families Citing this family (11)

Family Cites Families (13)

• 2006
  • 2006-06-07 US US11/922,463 patent/US20090113522A1/en not_active Abandoned
  • 2006-06-07 WO PCT/FR2006/050529 patent/WO2006134291A1/fr active Application Filing
  • 2006-06-07 EP EP06764849A patent/EP1891771A1/de not_active Withdrawn
  • 2006-06-07 CN CNA2006800215647A patent/CN101204038A/zh active Pending

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events