Method, system and devices for transferring accounting information

IS 2 289 114 T3

DESCRIPTION

Method, system and devices for transferring accounting information.

Technical field of the invention

The present invention relates to a method in a system and to a system for transferring accounting information. Furthermore, the invention relates to a method in a terminal, to a terminal, to an Extensible Authentication Protocol (EAP) service authorization server, to a method in an EAP service authorization server, to a computer program and to a subtype of EAP.

Background of the invention

In Local Area Networks, a service operator may be interested in providing themselves with a variety of accounting information related to the users who use the network to access different services. Examples of such accounting information include a value that indicates how long a user has used a specific service, a value that indicates the amount of data received from and / or sent to a specific service, information regarding when it used the user the service, and / or the number of and / or the type of transactions carried out.

Currently there are systems in which the network access points collect accounting information for each user / terminal that connects to the network through the access point. The access points then send the information to an Authentication, Authorization and Accounting (AAA) server through an AAA protocol such as RADIUS or DIAMETER.

However, there may be a lack of trust between the service provider, which manages the services used by a user, and the operator of a home network, which bills the user for the services used. Thus, the accounting information of the service provider must be verified and authorized before it is sent to the AAA server of the operator of the originating network.

Summary of the invention

One of the objectives of the present invention is to provide improved delivery of accounting information.

This object is achieved by means of a method in a system for transferring accounting information according to claim 1, a system for transferring accounting information according to claim 11, a method in a terminal according to claim 19, a terminal according to claim 22 , a method in an Extensible Authentication Protocol (EAP) service authorization server according to claim 25, an EAP service authorization server according to claim 31, a computer program according to claim 35, a computer program according to claim 36, an Extensible Authentication Protocol response packet (EAP response) according to claim 37. In the Dependent claims disclose preferred embodiments of the invention.

More particularly, according to one of the aspects, a method in a system for transferring accounting information comprises:

evaluate data related to a service used by at least one terminal, provide the evaluated data as accounting information to at least one Extensible Authentication Protocol (EAP) service authorization server, send, by means of an Extensible Authentication Protocol (EAP) request, Extensible Authentication (EAP request), a service authorization request from said at least one EAP service authorization server to said at least one terminal, digitally signing accounting information, in said at least one terminal, including, in said at least one terminal, the digitally signed accounting information in an Extensible Authentication Protocol response (EAP response), and sending the information of accounting digitally signed to a AAA server.

According to another aspect, a system for transferring accounting information comprises: an evaluation server to evaluate data related to a service,

ES 2 289 114 T3 an Extensible Authentication Protocol (EAP) service authorization server that includes a generator for generating service authorizations for the Extensible Authentication Protocol request (EAP request), and a network connection means, a terminal including a signature module arranged to digitally sign verified accounting information, a generator of Extensible Authentication Protocol responses (EAP responses) arranged to insert in EAP responses a verified and digitally signed accounting information, and network connection means, and an Authentication Authorization and Accounting server arranged to manage accounting information pertaining to at least one terminal.

According to yet another aspect, a method in a terminal comprises:

collect data corresponding to relevant accounting information for at least one service currently used in the terminal, receive an Extensible Authentication Protocol request (EAP request) that includes relevant accounting information for said at least one service currently used in the terminal , compare said accounting information received with the data collected, and, if the data collected corresponds to the accounting information, Said method also comprises: the digital signature of said received accounting information, and the sending of the digitally signed accounting information in an Extensible Authentication Protocol response (EAP response).

According to a further aspect, a terminal comprises:

a collector arranged to collect data corresponding to relevant accounting information for at least one service currently used in the WLAN terminal, a comparison device arranged to compare the collected data with received accounting information, a signature module arranged to digitally sign information verified accounting, an Extensible Authentication Protocol response generator (EAP responses) arranged to insert digitally signed accounting information into EAP responses, and a network connection means.

According to yet another aspect, a method in an Extensible Authentication Protocol (EAP) service authorization server comprises:

receiving accounting information related to at least one terminal, inserting said accounting information into an Extensible Authentication Protocol request (EAP request), and sending said EAP request to said at least one terminal.

According to yet another aspect, an Extensible Authentication Protocol (EAP) service authorization server comprises:

an accounting information receiver for receiving accounting information regarding at least one terminal, an Extensible Authentication Protocol request generator (EAP requests) arranged to insert accounting information from at least one terminal into an EAP request, and a network connection means.

IS 2 289 114 T3

By getting the terminal / user to authorize the accounting information by using the EAP to initiate such authorization and to carry signed accounting information for said terminal / user, it enables the user or the user's terminal to provide an authorization of the information. accounting without the need for excessive additional effort by an access network operator, service operator, or the user in connection with the modification of existing systems. In many cases it may be an advantage that the EAP already exists, and therefore there is no need to implement or develop additional protocols. In addition, the EAP services authorization server establishes contact with the terminal during the establishment of a connection with the access network, and therefore there is no need to use server discovery protocols, client IP address discoveries, or other. similar procedures. In addition, the EAP message that includes the authorization of the service can pass through personal firewalls and Virtual Private Network (VPN) clients at the terminal.

By making it possible for the user / terminal to authorize the accounting information, it can be ensured that the accounting information is correct, and the uncertainty of accounting information sent directly from an access network operator, which it may or may not be trustworthy. In this way, an operator of the access network, or any other service, cannot falsify the accounting information and therefore the user cannot subsequently reject said accounting information. In addition, this situation can also make a user feel more comfortable when using services that cost money, since the user has control to some extent of the debiting procedure in their account and it is not entirely in the hands of the operators .

In the context of the invention, the term service means a service that can be accessed by means of a terminal through a service provider. For example, a service may include access to one or a plurality of network environments, for example, a local network, a private network, the Internet, a network controlled by a specific operator, or a virtual local area network, and the It may include different access capabilities, for example email capabilities, Short Message Service (SMS) capabilities, Multimedia Service (MMS) capabilities, e-commerce capabilities, printing capabilities, and so on.

According to one of the embodiments, the evaluation server and the EAP service authorization server are included in the same device, for example an access point. This option can increase the available bandwidth in an access network since the exchange of information between the evaluation server and the EAP services authorization server no longer needs to use the network, and, for example, the number of protocol messages sent.

According to another embodiment, the evaluation server and the EAP service authorization server are included in different devices. This feature can make it easier to introduce an EAP services authorization server into a network system that already includes an evaluation server. For example, in a Wireless LAN that includes access points that support Radius accounting or any other accounting protocol.

In one embodiment, the EAP request and the EAP response are sent over a WLAN connection.

In another embodiment, the EAP response that includes the signed accounting information from the terminal is sent to, or received by, the EAP service authorization server. This option enables the access network operator to verify that the user of the terminal or the terminal has not altered the accounting information. Additionally, if necessary, the access network operator can control the identity of the terminal user.

In still another embodiment, the action of signing and verifying a signature are performed by means of a public key cryptographic system.

Other areas of applicability of the present invention will become apparent from the detailed description that follows. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are offered by way of illustration only, as various changes and modifications within the scope of the art will be apparent to those skilled in the art. the invention, based on the present detailed description.

Brief description of the drawings

Other features and advantages of the present invention will become apparent from the following detailed description of a presently preferred embodiment, with reference to the accompanying drawings, in which Fig. 1 shows a schematic overview of a system according to one of the embodiments, Fig. 2 shows a schematic view of an embodiment of a terminal, Fig. 3 shows a flow chart of a process for managing accounting information in the terminal of Fig. 2,

ES 2 289 114 T3 Fig. 4 shows a schematic view of an embodiment of an EAP service authorization server, Fig. 5 shows a flow diagram of a process for managing accounting information, and Fig. 6 shows a timing diagram on messages sent during a transmission of accounting information according to one of the embodiments, Fig. 7 shows a timing diagram on messages sent during a transmission of accounting information according to another of the embodiments, Fig. 8 shows a schematic view of the format of one of the embodiments of an EAP Request / Service Authorization packet and an EAP Response / Service Authorization packet, Fig. 9 shows a schematic view of the format of another of the embodiments of an EAP Request / Service Authorization packet and of an EAP Response / Service Authorization packet, and Fig. 10 shows a schematic view of a Flags field of a package according to Fig. 9.

Detailed description of an embodiment

In Fig. 1, a schematic general view of a system according to one of the embodiments is shown. The system comprises an Extensible Authentication Protocol (EAP) service authorization server 10, an access point 12, an Authentication Authorization and Accounting (AAA) server 14, and a terminal 16.

In one of the embodiments, communication between an access point 12, an EAP Service Authorization Server 10, and an AAA server 14 is performed over a network 18.

The EAP Service Authorization Server 10 is arranged to provide the terminal 16 with accounting information that can be verified by said terminal. The EAP Service Authorization Server 10 can be arranged, for example, in the form of a separate server, included in the access point 12, included in the AAA server 14, or included in any other device that can communicate with the terminal 16 , AAA server 14, and access point 12.

The AAA server 14 can be any type of AAA server that is known to those of skill in the art.

Access point 12 can be any type of access point that is known to those of skill in the art. Access point 12 includes means for evaluating accounting information related to one or a plurality of terminals connecting through it. Thus, it can be said that it includes an evaluation server. The access point 12 is arranged to send and receive data by means of a wireless communication, for example, a communication of a Wireless Local Area Network, an infrared communication, Bluetooth, or any communication based on radio frequency. In one embodiment, the access point 12 is an access point that operates according to the IEEE 802 standard and uses an Extensible Authentication Protocol (EAP) according to IEEE 802.1x.

The terminal can be any device that has a user interface and means to perform communication. For example, the terminal can be a telephone, a Personal Digital Assistant (PDA), a handheld computer, a laptop, a desktop computer. The terminal may be arranged to communicate through a wireless communication channel, as shown in Fig. 1, or through wires, not shown in Fig. 1. The wireless communication can be, for example, a Wireless Local Area Network communication, an infrared communication, Bluetooth, or any communication based on radio frequency. The communication by wires can be, for example, a communication via a modem and a telephone network, a direct connection with a Local Area Network. In a system in which there are terminals connected to the network through wires, an independent evaluation server can be arranged to collect the accounting information.

In one embodiment, the access point 12 is part of an access network that is managed by an access network operator and the AAA server is part of an accounting management system managed by a server operator. AAA or a source operator. The access network operator and the home operator may be part of the same organization or different organizations.

The term service authorization can refer to a network access, although it can also refer to a printer service in which a user, for example, pays for company pages, an e-commerce service in which a user, for example, For example, pay for the requested service or product, and so on.

In Fig. 2 an embodiment of a terminal 16 is shown. Terminal 16 comprises connection means 202 for obtaining a wireless connection with and communicating through an access point, and a protocol stack 204 comprising a EAP 206. However, as mentioned above, the connection means can be a modem or a common network interface card to connect to said network by means of wires.

IS 2 289 114 T3

Furthermore, the terminal 16 comprises a collector 208 for collecting data corresponding to accounting information pertinent to at least one service currently used in the terminal, a verifier 210 to verify that the received accounting information corresponds to the collected data, a module signature 212 to sign accounting information that has been approved by the comparison media, and an EAP response generator 214 for inserting signed accounting information into an EAP response message.

In one of the embodiments the collector collects an input from a user that establishes whether or not the user accepts the accounting information. Then, in such an embodiment, the verifier only needs to check the input collected from the user to decide whether the verification is successful or not.

The signature module 212 can comprise means for making any type of digital signature known to those skilled in the art, for example, it can be a public key cryptographic system, which is normally used for signatures, or it can be an encryption system. symmetrical. In a public key cryptographic system, you have a private and a public key. The public key can be distributed to all parties involved. In this case, the signature module encrypts a message by means of the private key. If the message can then be decrypted using the public key, the signature is verified as the signature of the person who owns the public key.

The means 202 to 214 described above can be fully or partially implemented by means of software code.

The accounting information can be a value that indicates how long the terminal has been connected to a service, a value that indicates the amount of data sent and / or received using a specific service, information regarding when the user used the service, the number of and / or the type of transactions carried out, and / or the number of uses of the service.

In Fig. 3, a process is shown in one of the terminal embodiments. The process begins when the terminal receives an EAP request for a service authorization that includes accounting information, step 300. Next, the accounting information is extracted from the EAP request, step 302. When the accounting information is available in the terminal, a verification process begins, step 304.

The verification stage can be done in many ways. In one embodiment, the terminal collects data corresponding to accounting information for a service that is currently in use for essentially the entire period in which the service is used. Next, when the verification step 304 is performed, the terminal compares the collected data with the received accounting information and makes a decision based on the difference between the collected data and the received accounting information as to whether the verification of the accounting information is satisfactory or not.

In another embodiment, the terminal does not compare the received accounting information, but instead presents the accounting information and the collected data to the user who decides whether or not to verify the accounting information. If the user performs the verification, then the verification step 304 is successful, otherwise it results in a failure.

In still another embodiment, the terminal does not collect such data and therefore no collected data is available. In such a case, the verification step 304 may present the received accounting information to the user and wait for the user to verify the accounting information. If the user performs the verification, then the verification step 304 is successful, otherwise it results in a failure.

In a further embodiment, the terminal collects data and compares it with the received accounting information. However, the terminal provides a user interface whereby the user can select "ok" or "void" to accept the accounting information or avoid sending it. Signing of accounting information can be done before or after the user has notified the terminal of the selection.

In another embodiment, the service authorization EAP request, received at step 300, does not include any accounting information. In such a case, step 302 regarding the extraction of accounting information is not performed. After receiving the EAP request for service authorization, the terminal considers the data collected by itself as verified accounting information, and therefore the verification step is considered as successful.

In step 306, regardless of which of the previous embodiments of verification step 304 is used, the process checks whether verification step 304 gave a success or a failure. If the result is a failure, then the process ends, step 308. However, if the result is successful, then the process proceeds by signing the accounting information, step 310.

The signature, step 310, can be performed by any method known to those skilled in the art. For example, by means of public key encryption. Other signature schemes can also be used, for example, a symmetric cryptographic system can be used to encrypt the accounting information, although, in such a case, only the terminal and the originating operator can share the signature representation key.

IS 2 289 114 T3

The signed accounting information is then inserted into an EAP response, step 314, and the EAP response is sent over the network connection.

In Fig. 4, one of the embodiments of the EAP service authorization server is shown. The EAP service authorization server according to the figure comprises network connection means 402 for connecting to a network 403, and a protocol stack 404 including an EAP 406. If the EAP service authorization server 10 is not a device in which only the EAP service authorization server 10 is implemented, the network connection means 402 and the protocol stack 404 can be shared by the other devices, for For example, if the EAP 10 service authorization server is included in an access point, AAA server, or AAA proxy server. In one embodiment, the stack also includes an AAA protocol, for example the RADIUS protocol or a DIAMETER protocol.

Furthermore, the EAP service authorization server 10 includes an accounting information receiver 408, which is arranged to manage accounting information received from one or a plurality of access points, and an EAP request generator, which is arranged to use the EAP 406 to generate EAP requests for service authorizations. According to one of the embodiments, the EAP request includes accounting information for a specific terminal to be sent to said specific terminal, this option is implemented if the terminal or the user must make a decision regarding whether the accounting information from the EAP services authorization server is correct or not. According to another embodiment, the service authorization EAP request does not include any accounting information, this option is implemented if the EAP service authorization server must make the decision regarding whether or not the accounting information of the terminal is correct.

The time between sending two consecutive EAP requests that include accounting information from a specific terminal can be based on the time between receiving the accounting information, on a value of a specific property of the accounting information, for example, said EAP request must be sent when the time elapsed since the last request exceeds a specific value or when the amount of data sent and / or received since the last request exceeds a specific value, or in predetermined criteria set by one of the operators. The EAP service authorization may be arranged to manage accounting information regarding one or a plurality of terminals.

In addition, the EAP service authorization server 10 includes an extractor 412, a signature verifier 414, an access terminator 416, and an accounting message generator 418.

Extractor 412 is arranged to extract signed accounting information from an EAP response originating from a terminal.

Verifier 414 is arranged to verify the signature and content of the EAP response message. Content verification can be achieved by checking whether the received accounting information corresponds to the information sent from the EAP service authorization server to the terminal or whether the received information corresponds to the information collected from the EAP service authorization server. . Verification of the signature can be achieved by means of a public key stored in the EAP services authorization server 10. The public key may have been provided to the EAP services authorization server 10 from the terminal in the form of a certificate in a EAP reply, or from the AAA server in an EAP Diameter / Radius reply message during the access authorization process.

Access terminator 416 is arranged to terminate access to a specific service if one or a plurality of predetermined criteria are not met.

The accounting message generator is arranged to generate an AAA message including signed accounting information and to initiate forwarding of the message to an AAA server managing the service to which the accounting information is related.

In Fig. 5, a process of one of the embodiments of the EAP service authorization server 10 is shown. The process begins when the EAP service authorization server 10 receives accounting information related to a specific terminal, step 502 Next, an EAP request is generated, the EAP request includes said accounting information, step 504. Next, the EAP request is sent to said terminal, to which the accounting information refers, step 506. In one of the embodiments, the generation and dispatch of the EAP request that includes the accounting information is not performed until the accumulated value of a specific property in the accounting information has been reached, for example, a value of time, a value of data sent and / or received, or a value directly related to money, that is, the sending can be made periodically or once in a certain period of time.

When the EAP request is sent, a timer is started, step 508. In step 510, the timer value is compared to a predetermined time limit, t_limit. If the timer value does not exceed t_limitIn that case the process continues to check if an EAP response has been received from the terminal, step 514. If no eAp response has been received, the process returns to step 510 and compares the timer value with the t-limit value. If the timer value exceeds the value of tlimit, then no response has been received

IS 2 289 114 T3

EAP at the time limit and the process continues to step 512 and terminates access to the service to which the accounting information refers. However, if an EAP response is received, step 514, before the time limit expires, the EAP service authorization server 10 verifies the signature of the EAP response, step 516, by means of the signature of the terminal or the user of the terminal that is stored in a memory of the EAP service authorization server 10. The process can also verify that the accounting information received corresponds to the accounting information sent to the terminal. If the signature is invalid, step 518, the process continues to step 512 and terminates access to the service to which the accounting information refers. However, if the signature is valid, the process continues to step 520, where it prepares and sends the signed accounting information to a AAA server.

According to another embodiment, the EAP request generated in step 504 does not include the accounting information and, therefore, the accounting information received in the EAP response, step 514, is information collected by the terminal. Thus, the content verification in step 516 is performed by comparing the received accounting information with the corresponding accounting information collected from the service authorization server EAP.

In Fig. 6, a timing diagram according to one of the embodiments is shown, in which the EAP service authorization server is arranged in the form of a separate device, in a AAA proxy, or in another suitable device. According to this embodiment, an access point collects accounting information for one or a plurality of users / terminals. For each user / terminal, the access point collects data for at least the period of time that the terminal is accessing a service, 602. When accounting information has been collected during a predetermined period of time or in correspondence with a predetermined amount of data sent and / or received, the access point sends to an EAP service authorization server a Diameter 604 accounting request, which includes accounting information related to a specific terminal. The accounting request is not necessarily sent via the Diameter protocol, but can be sent via any protocol that can be used to achieve corresponding functionality, for example, the RADIUS protocol. This also applies to other streams mentioned below that use the Diameter protocol.

Next, the EAP service authorization server handles the Diameter accounting request, message 604, see Figs. 4 and 5, and the accounting information included and responds by sending an EAP Diameter reply, message 606, to the access point. The EAP Diameter response includes an EAP / Service Authorization request that carries accounting information. The EAP request / Service Authorization message that carries accounting information is then packaged using the EAP over LAN protocol (EAPOL) at the access point and sent like any other EAP request to said specific terminal, message 608. In the In the depicted embodiment, the terminal is a Wireless Local Area Networks (WLAN) enabled terminal. However, as mentioned above, the terminal may be arranged for communication via other methods. Next, the terminal manages the received EAP Request, checks the accounting information 609, see also Figs. 2 and 3, and sends an EAPOL that includes an EAP Response / Service Authorization that carries signed accounting information to the access point, message 610. The submission of the EAPOL that includes the EAP Response / Service Authorization carrying signed accounting information is performed only if the verification of the accounting information was successful. The access point then passes the EAP Response / Service Authorization, which carries the signed accounting information, to the EAP service authorization server via an EAP Diameter Request, message 612. The EAP services authorization server then generates an EAP success message and sends it in an EAP Diameter reply to the access point, message 614. The access point then passes the EAP success message to the terminal via means of an EAPOL, message 616. When the signed accounting information is received at the EAP service authorization server in message 612, the EAP service authorization server begins to verify the signature of the accounting information 617, see also Figs. 4 and 5. If the signature verification is successful, that is, the signature is valid, then the EAP service authorization server sends a Diameter Accounting Request that includes the signed accounting information to a AAA server that will manage the accounting information.

In Fig. 7 a timing diagram according to another embodiment in which the EAP service authorization server is included in the access point is shown. In this embodiment, the accounting information collected or evaluated 702 via the access point is accessible to the EAP services authorization server or is passed to the EAP services authorization server via internal communication within the access point. access. Next, the Access Point / EAP service authorization server generates and sends to the terminal an EAPOL message that includes an EAP Request / Service Authorization that carries the accounting information, message 704. In the embodiment shown, the terminal is a terminal enabled for WLANs. However, as mentioned above, the terminal may be arranged for communication via other methods. At the terminal 706 the accounting information is verified. If the verification is successful, the accounting information is then signed and the terminal sends to the access point an EAPOL 708 message that includes an EAP Response / Service Authorization, which carries the signed accounting information. In response to this message, the access point responds by sending an EAPOL message that includes an eAp 710 Success message. The EAP service authorization server / access point then generates and sends a Diameter 714 Accounting Request to the AAA server.

IS 2 289 114 T3

In Fig. 8, an embodiment of an EAP subtype is shown in the form of a specialized EAP packet format for EAP Request / Service Authorization and EAP Response / Service Authorization. The packet of both the EAP Request / Service Authorization and the EAP Response / Service Authorization includes a Code field 802, an Identifier field 804, a Length field 806, a Type field 808, a Type field Data 810, and a Data field 812.

As in the EAP specification, the length of the 802 Code field is 8 bits, that is, one octet, and identifies the type of EAP packet to be sent. EAP codes are assigned as follows:

Request

Answer

Other codes used in the 802 Code field of EAP packets are 3 for Success and 4 for Failure. However, for these codes, the EAP packet format does not necessarily correspond to the EAP Request / Service Authorization and EAP Response / Service Authorization format as shown in Fig. 8. A specific format for EAP Success Result and EAP Failure packets can be found in the EAP specification contained in IETF RFC 2284.

Identifier field 804 is also an octet and includes an identification code to match responses with requests. The generation of such identification codes is known to experts.

The Length field 806 is two octets and indicates the length of the EAP packet which includes the Code field 802, Identifier field 804, Length field 806, Type field 808, Data Type field 810, and Data field 812.

The Type 808 field is one octet and specifies the type of the EAP packet. For the EAP Request / Service Authorization and the EAP Response / Service Authorization, the Type 808 field is set to a code that identifies the packet as a Service Authorization packet.

The 810 Data Type field is an octet and specifies the data type of the 812 Data field. According to one of the EAP / Service Authorization Request embodiments, the data type may be, for example, Attribute pairs -Value, a Forced Display text string, or an XML document. According to one of the EAP Response / Service Authorization embodiments, the Data Type field identifies the type of the signed data, which can be, for example, a PKCS # 1 Signature, PKCS # 7 signed data, or an XML Signature. A description of PKCS # 7 is found in RSA Laboratories publication "PKCS # 1: RSA Cryptography Standard", Version 2.0, October 1998. A description of PKCS # 7 is found in RSA Laboratories publication "PKCS # 7: Cryptographic Message Syntax Standard", Version 1.5, November 1993. A description of the XML signature is found in the following document by D. Eastlake 3 °, J. Reagle, D. Solo, "(Extensible Markup Language) XML-signature Syntax and Processing", RFC 3275, March 2002.

Data field 812 may comprise any number of octets. According to one of the embodiments of the EAP Request / Service Authorization, the Data field 812 includes said accounting information, which can be presented, for example, in the form of Attribute-value pairs, a text string of Display Required, or an XML Document. According to one of the EAP Response / Service Authorization embodiments, the data field 812 includes said signed accounting information, which can be signed according to the method specified in the Data Type field 810.

The amount of data to be transmitted in a single Service Authorization message can be very large. In this way, the service authorization messages sent in a single round can be larger than that of a Point-to-Point Protocol Maximum Transmission unit (PPP MTU), the maximum size of RADIUS packets of 4096 octets, or even a Maximum Multilink Rebuilt Unit (MRRU). As described in the IETF RFC 1990, "The PPP Multilink Protocol (MP)", by Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, August 1996, the Multilink MMRU is negotiated through the MRRU LCP Multilink option, which includes an MRRU length field of two octets, and therefore can support MRRU units of up to 64 KB.

However, to protect against a blockage of reassembly and denial of service attacks, it may be desirable for one of the implementations to set a maximum size for such a group of Service Authorization messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to come anywhere near this value, a reasonable choice for the maximum acceptable message length might be 64 KB.

If this value is selected, then fragmentation can be managed through the multilink PPP fragmentation mechanisms described in the IETF RFC 1990. Although this is the desirable situation, there may be cases in which the multilink option cannot be negotiated. or MRRU LCP. As a consequence, one of the EAP Service Authorization implementations may be arranged, according to one of the embodiments, to provide its own support for fragmentation and reassembly.

IS 2 289 114 T3

Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple way. In the EAP, fragments that are lost or damaged in transit will be retransmitted, and since in the EAP the sequencing information is provided by the identifier field, there is no need for a fragment drift field like the one shown. provided in IPv4.

Support for EAP Service Authorization fragmentation can be provided through the addition of one octet flags within the EAP Response and EAP Request packets, as well as a four octet Service Authorization Message Length field. . For example, the flags octet may include Length Included (L) and More Fragments (M) bits. In such a case, the L flag can be set to indicate the presence of the four-octet Service Authorization Message Length field, and is set for the first fragment of a fragmented Service Authorization message or set of messages. . Consequently, the M flag is set on all fragments except the last one. The Service Authorization Message Length field can be four octets, and provides the total length of the Service Authorization message or set of messages being fragmented; This option can simplify the allocation of buffers.

When an EAP Service Authorization peer receives an EAP Request packet with the M bit set, it responds with an EAP Response with EAP Type EAP Service Authorization and no data. This element serves as an Acknowledgment (ACK) of the fragment. The EAP server waits until it receives the EAP Response before sending another chunk. To avoid errors in fragment processing, the EAP server can increment the Identifier field for each fragment contained within an EAP Request, and the peer can include this Identifier value in the ACK of the fragment contained in the EAP Response. Fragments that are re-transmitted can contain the same Identifier value.

Similarly, when the EAP server receives an EAP Response with the M bit set, it responds with an EAP Request with EAP Service Authorization of Type EAP and no data. This element serves as an ACK of the fragment. The EAP peer waits until it receives the EAP Request before sending another fragment. To avoid errors in the processing of fragments, the EAP server can increment the Identifier value for each ACK of the fragment contained in an EAP Request, and the peer can include this Identifier value in the subsequent fragment contained in an EAP Response.

According to one embodiment, an EAP Service Authorization implementation that is arranged to provide its own support for fragmentation and reassembly may use an EAP Request / Service Authorization packet format and a Response packet format. EAP / Service Authorization described later and shown in Fig. 9.

Regardless of whether the packet is an EAP Request / Service Authorization packet or an EAP Response / Service Authorization packet, the packet comprises a Code field 802, an Identifier field 804, a Length field 806, a field Type 808, a Flags field 902, a Service Authorization Message Length field 904. The Code field 802, Identifier field 804, Length field 806, and Type field 808 may be identical to the corresponding fields described in connection with FIG. 8.

The Flags field 902 may be one octet in length and includes flags to control fragmentation. In one of the embodiments, the Flags field can have the format shown in Fig. 10, in which the characters L, M, and R are one bit and indicate flags, and:

L = Length included

M = More fragments

R = Reserved

The L (length included) flag is set to indicate the presence of the four-octet Service Authorization Message Length field, and may be set for the first fragment of a Service Authorization message or fragmented set of messages. The M bit (more fragments) is set on all fragments except the last one.

The Service Authorization Message Length field 904 can be four octets, and is present only if the L bit has been set. This field provides the total length of the Service Authorization message or set of messages being fragmented.

The Service Authorization XXX Message field 906 is a Service Authorization Request Message field in an EAP Request / Service Authorization packet and a Service Authorization Response Message field in an EAP Response / Authorization packet of service.

The Service Authorization Request Message field in an EAP Request / Service Authorization packet may include data to be signed, ie, accounting information, and an indication of the format of such data. It can be implemented in a plurality of ways. For example, the Transport Layer Security (TLS) protocol can be used. The TSL protocol and the TLS presentation language

ES 2 289 114 T3 are described in IETF RFC 2246, “The TLS Protocol Version 1.0”, by T. Dierks, C. Allen, January 1999. Said format can indicate, for example, a text-based string, Attribute pairs -Value, or an XML document.

The Service Authorization Response Message field in an EAP Response / Service Authorization packet includes the signed data and if necessary an indication of the signature method. The signature methods can be, for example, one of the methods described in relation to Fig. 8.