JP5599910B2 - Authentication delegation based on re-verification of cryptographic evidence - Google Patents

Description

  An organization can have a set of entities that together provide a service to users. For example, access to resources such as data, web pages, and functional software operations should be limited to certain users who are familiar and authorized. Various access control schemes to prevent unauthorized users or malicious attackers from accessing computer resources, including the mechanisms used to authenticate the identity of users attempting to access web resources Has been developed. In particular, two-factor authentication is becoming common due to an increase in attacks on theft of personal information (for example, phishing and farming).

  T-FA (Two-factor authentication) is an arbitrary authentication protocol that requires two different methods for establishing identity and authority. A typical implementation of T-FA uses “what you know” (eg, password or personal identification number) as one of the factors and “what you have” (eg, credit card or Hardware token) or “what you are” (eg fingerprint or retina pattern). For example, smart cards are one way to provide T-FA. A smart card is an example of a hardware token and typically includes a microprocessor that is capable of various security operations, such as performing cryptographic functions on given data. A smart card is typically one or more ITU-T (International Telecommunication Union) X.X, which can be used for protocols that require certificate-based authentication. 509 certificates (and their associated private keys). Secure Socket Layer (SSL), Transport Layer Security (TLS), and Kerberos (using PKINIT, which is an abbreviation for “Public Key Cryptography for Initial Authentication in Kerberos”) are all examples of such protocols.

  A smart card is not required to use the certificate. Many devices (eg, computers, mobile phones) can store and use certificates (and their associated private keys). For example, Windows Mobile 5.0 uses certificates to synchronize email and calendar information (via the Exchange ActiveSync protocol that runs on top of SSL or TLS) Can authenticate against Exchange 2003 SP2 server.

  For example, to prevent identity theft attacks against a series of entities in an organization's network, including gateway devices at the edge of the network that provide web-based access to web servers located on the organization's internal network (intranet) ,is important.

  Authentication delegation is a resource where a client delegates authentication to a server or, more specifically, by a third party authentication service (or gateway) on behalf of a user (in effect, impersonating that user). Widely defined as being able to access and authenticate (or server). The accessed server bases the authorization decision on the user's identity rather than on the authentication service account.

  This background is provided to introduce a brief context to the following summary and detailed description of the invention. This background art is not intended to assist in determining the scope of the claimed subject matter, and any or all of the above presented subject matter is claimed or claimed. It is not intended to be considered limited to only those implementations that can solve all the shortcomings or problems.

  Authentication delegation based on revalidation or cryptographic evidence utilizes a record of at least a portion of the TLS handshake between the gateway device and the user when the user desires access to a particular server in a set of entities. Cryptographic evidence can be recorded by either the recorded part of the TLS handshake (1) the desired server when the server verifies the recorded part to verify authentication, or (2) the third party entity. Re-validate and verify the authentication by providing user credentials to the gateway, and then use that credential to forward to one of the third-party entities when authenticating to the server as a user Provided by. In either case, the server and third party entities use the recorded portion of the TLS handshake to determine whether to allow user access without involving the authentication between the user and the gateway device. .

  In various illustrative examples, the cryptographic evidence includes a time stamp to provide additional security measures by ensuring that the TLS handshake is timely (ie, “fresh”). . In addition, after confirming a valid TLS handshake, the third-party entity can create a temporary that the gateway can authenticate to the desired server on behalf of the user, for example using Kerberos with PKINIT. Can be configured to issue user credentials (ie, with a time limit).

  This summary is provided to introduce a selection of concepts in a simplified form. This concept is further explained in the detailed description section. Elements or steps other than those described in this summary are feasible and elements or steps are not necessarily required. This summary is not intended to reveal key features or essential features of the claimed subject matter, but is intended to determine the scope of the claimed subject matter. It is not intended to be used as a supplement. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

FIG. 6 is a simplified functional block diagram of an illustrative architecture for authentication delegation based on revalidation of TLS handshake messages. FIG. 2 is an illustrative flow diagram showing the steps of an authentication process utilizing the exemplary architecture of FIG. FIG. 4 is a simplified functional block diagram of an illustrative architecture for authentication delegation provided by a third party entity whose user credentials receive at least a portion of a TLS handshake. It is a figure which shows explanatory message exchange between the key distribution center in a client and Kerberos (version 5) protocol. FIG. 4 is an illustrative flow diagram illustrating the steps of the authentication process utilizing the exemplary architecture of FIG. FIG. 4 is a schematic message flow diagram illustrating the exchange of messages between a client and a server in a typical TLS handshake phase.

  The descriptive context of this authentication delegation based on revalidation or cryptographic evidence is that the client / user accesses one or more service providers through the gateway. However, it is emphasized that this context is merely illustrative and can be applied in other contexts and environments. For example, this authentication delegation is optional when the web server needs to authenticate as a user to a backend application or database, or alternatively when there is a set of entities and authentication is required between chained entities Can be used in the setting of

  In the access context, the gateway device provides access to the web server to which the user submits requests, and these requests reach the gateway and ultimately the internal web server. However, both gateways and web servers typically require some form of authentication in order to determine whether a user connected to them can access the desired resource.

  When a gateway is incorporated and FBA (form-based authentication) is used, the user needs to input a user name and a password in a logon format. The user then submits this form and the gateway receives the user's username and password. The gateway can then use those credentials to authenticate against an internal web server on behalf of the user. This is very simple and feasible because the gateway can receive the password and use it as desired. However, this cannot be done with some authentication schemes. For example, if a user authenticates to the gateway using an authentication method that does not provide a password, the gateway may use any credential that can be reused to authenticate to an internal web server on behalf of the user. Does not have.

  Several solutions to this problem have been proposed. For example, one solution involves a “trusted third party”. Here, a trusted third party is incorporated prior to “trusting” the gateway to authenticate against a defined set of web servers (or services in general) on behalf of all users. This technology can be implemented as a protocol that allows a gateway (or front-end server) to request tickets for use with other servers on behalf of a client. The trusted third party then proceeds to provide the service ticket to the gateway on behalf of any user so that the gateway can then impersonate any user.

  A trusted third party can also be incorporated to provide service tickets under specific conditions. For example, in the Kerberos protocol, the client authenticates to the gateway via a service ticket, and delegation constrained by Kerberos may incorporate a trusted third party (key distribution center) to impose its conditions. Provide a way to do it. In this case, the gateway must provide evidence that the claimed user was actually authenticated (via a service ticket) to the gateway. This is important to enhance the security of the entire system. For example, the advantage of requesting such evidence is that a compromised gateway cannot access the server on behalf of the user unless the user is first properly authenticated to that gateway.

  While these proposals provide a way to deal with passwordless authentication, in some cases they implement an authentication delegation model that does not involve the KDC (Key Distribution Center) or other trusted third party entities. May be desirable. In such a model, the gateway authenticates against an internal web server on behalf of the user without any communication with the KDC. There are many solutions that provide this kind of functionality. For example, some products may return a token (HTTP (sometimes a cookie)) trusted by an internal web server once the user authenticates to the gateway. It can be installed / embedded on the gateway and any number of internal web servers as possible. As with other proposals, one problem with this model is that it reduces the overall security of the system because the gateway is a fully trusted entity.

  This arrangement provides authentication delegation based on cryptographic evidence revalidation. A gateway (or front-end server) provides access to a web server (or back-end server). The client / user authenticates to the gateway using a TLS handshake with client authentication. A record of the TLS handshake, or at least a record of a TLS handshake sufficient to prove that the user has been authenticated to the gateway, is then sent to the web server (re-validating the handshake) or Provided to any of the three party entities (after verifying the record, provide user credentials to the gateway, which then authenticates to the web server).

  With reference now to the figures in which like reference numbers refer to like elements, FIG. 1 illustrates an exemplary network architecture that utilizes the present authentication delegation. By operatively connecting the client / user computer system 10 to a gateway 20 (also called an authentication server), communication between the network of the client / user 10 and the web server 30 (also called a network server) can be made. The gateway 20 includes a database / directory (not shown) that contains the information necessary to authenticate the user (alternatively, the gateway can communicate over the network using an external user database / directory). ). In response to the logon, the user / client 10 authenticates to the gateway 20 via a TLS handshake that initially has client authentication, as indicated by reference numeral 35. Note that client authentication is intentionally stated here, as client authentication is optional in the TLS handshake protocol.

  The TLS protocol provides communication privacy over the Internet and allows client / server applications to communicate in a manner designed to prevent eavesdropping, tampering, or message forgery. The TLS handshake protocol allows the server and client to authenticate each other and negotiate cryptographic algorithms and keys before the application protocol sends or receives the first byte of that data.

  One advantage of TLS is that there is an application protocol independent. Thus, higher level protocols can be transparently placed on top of the TLS protocol. The TLS handshake protocol can be summarized as follows. That is, the user / client sends the client hello message to the server (gateway 20 in FIG. 1) that must respond with the server hello message. Otherwise, a fatal error will occur and this connection will fail. Establish enhanced security between client and server using client hello and server hello.

  FIG. 6 is a schematic message flow diagram illustrating message exchange between a client and a server in a typical TLS handshake phase. The TLS protocol is described in detail in RFC 2246 TLS Protocol Version 1.0, the disclosure of which is hereby incorporated by reference. The client / user communicates with the gateway device in a client-server relationship.

  More specifically, as shown in FIG. 6, the actual key exchange uses up to four messages. That is, server certificate, server key exchange, client certificate, and client key exchange. A new key exchange method is created by specifying a format for these messages and defining the use of the messages, so that the client and server can agree on a shared secret. After the hello message, the server sends a certificate for the message if the message is to be authenticated. In addition, a server key exchange message can be sent if required (eg, if the server does not have a certificate or is only for signatures).

  If the server is authenticated, the server can request a certificate from the client if the cipher suite selection is appropriate. The server then sends a server hello completion message indicating that the hello message phase of the handshake is complete. The server then waits for a client response. If the server sends a certificate request message, the client must send the certificate message. A client key exchange message is sent, and the message content depends on the public key algorithm selected between the client hello and the server hello. When the client sends a certificate with a signature function, it sends a digitally signed certificate verification message to clearly verify this certificate.

  Returning to FIG. 1, in this illustrative example, gateway 20 creates a record of data exchanged as part of this handshake (shown as THR with reference number 45 in FIG. 1). More specifically, this record consists of a signature for all previous messages in the TLS handshake, up to a certificate verification message that proves that the user / client 10 actually owns a private key that matches the certificate. At least.

  A record of the TLS handshake, or THR, is then provided directly to the internal web server 30 as authentication proof that the user / client 10 has been authenticated by the gateway 20 (ie, “proof”).

  The internal web server 30 is not involved in authentication between the client / user 10 and the gateway 20 and is simply provided with authentication evidence (ie, THR) of authentication between the client / user 10 and the gateway 20 and then the desired It only makes a decision on whether to provide access to the resource.

Note that the proposed scheme can only be used if the TLS handshake includes a certificate verification message. This message is not used if any of the following conditions are true: 1) TLS handshake does not include client authentication.
2) The client and gateway decide to resume the previous TLS session or repeat the current session (instead of negotiating new security parameters). In this case, the TLS handshake does not include a certificate verification message (see RFC 3046, pages 30-31).
3) The client certificate has a signature function (ie, all certificates except those that contain fixed Diffie-Hellman parameters). For example, the cipher suites ECDH_ECDSA and ECDH_RSA (see RFC 4492) support client authentication but do not use certificate verification messages.

  FIG. 2 is an illustrative flow diagram of an authentication process performed when a client / user attempts to access a web server in the exemplary architecture shown in FIG. This process begins when the client / user desires a web server resource and accesses the gateway 20 (step 200). If the client / user is not logged into the web server, the client / user must be authenticated before the web server grants access.

  The client / user then requests the desired web server resource (step 210). To authenticate the client / user, the gateway 20 and the client / user 10 then perform a TLS handshake with client authentication according to the method described in detail above (step 220). It will be appreciated that the client / user 10 can be authenticated immediately before the client / user requests the desired resource or after the client / user requests the resource). A record of at least a portion of the TLS handshake is created and provided to the requested web server (step 230).

  After receiving the THR, the web server 30 verifies that the client / user has been authenticated to the gateway (by enabling the client / user signature in the certificate, the THR message and in some embodiments the THR The time stamp (discussed below) is also verified) (step 240). Assuming the client / user is authorized to access the web server, if the THR is verified, access to the requested web server is allowed (step 250), and if the THR is not verified, the access is Rejected (step 260).

  Some possible assumptions to prevent, or at least suppress, such a “replay attack” if an attacker can obtain a THR and attempt to reuse the THR to impersonate a client / user There are techniques and schemes. First, assuming that the server and / or client / user has incorporated time-related data (eg, a timestamp) into their handshake message, the service provider (eg, an internal web server) received The THR can be examined to confirm that it is “fresh”. This solution typically requires the gateway 20 and web server 30 (or user / client 10 and web server 30) to have synchronized clocks. Nonetheless, those skilled in the art will appreciate that there are many possible workarounds.

  Alternatively, the gateway 20 can ask the service provider (web server 30) for a nonce and incorporate the nonce into one of the messages sent to the user / client 10 as part of the TLS handshake. The service provider can then examine the received THR to confirm that it contains a nonce that was previously created and passed through the gateway 20.

In either of these two possibilities, the gateway 20 (or user / client 10) incorporates some data into the TLS handshake message (and the handshake protocol basically sets the security parameters for the data transfer session). A series of ordered messages to negotiate). Such data incorporation is typically performed by one of the following methods. (1) The server places a timestamp or nonce in the server's hello message as part of the random field of this message (details of this aspect of the handshake protocol are described in RFC 2246 7.4.1.3). Can be found in the section)
(2) The server places a timestamp or nonce in the server's halo extension (details can be found in section 2.2 of RFC 3546)
(3) The client / user places the time stamp in the client's hello message as part of the random field of this message (details of this aspect of the handshake protocol are described in RFC 2246, section 7.4.1.2 Can be found in)
(4) The client / user places the timestamp in the client's halo extension (details can be found in section 2.1 of RFC 3546)
Finally, in addition to each of the above alternatives, the service provider (web server 30) can store all received THRs to ensure that the same THR is not used more than once. . This storage can also be shared between service providers via some shared storage device or communication mechanism.

  In another illustrative implementation, a “double” TLS handshake can be used as a further defense against attackers that compromise the gateway or the communication channel between the client and the gateway. In this case, the client / user 10 and the gateway 20 perform a first TLS handshake without client authentication. When the first TLS handshake is successfully completed, the client / user 10 and gateway 20 perform a second TLS handshake with client authentication. A second handshake that is later used as evidence (THR) is encrypted for transmission by the session key that the client / user 10 and gateway 20 have obtained from the first handshake. Therefore, the THR is protected from being transmitted unencrypted (eg, in unencrypted text), so even if an attacker can breach the gateway 20, it is more likely to obtain the THR. It will be difficult.

  The embodiment discussed so far and illustrated in FIG. 1 consists of a user / client 10, a gateway 20, and a service provider (web server 30). An alternative embodiment shown in FIG. 3 and discussed in more detail below utilizes a third party entity 40. In this case, the service provider (web server 30) “trusts” the third party entity 40 to provide the user's real identity. Such a third party entity 40 can be a Kerberos KDC (S4U2Self + S4U2Proxy, etc.) or a CA (Certificate Authority). Note that although the third party entity 40 is illustrated in FIG. 3 as a separate entity, in some configurations, the third party entity (KDC or CA) resides on the same machine as the gateway 20.

  Prior to discussing the embodiment shown in FIG. 3 more specifically, the Kerberos protocol involved in the use of a trusted third party known as KDC negotiates a shared session key between the client and service, and the client and service. Discuss providing mutual authentication between.

  The basis of Kerberos is a ticket and an authentication code. A ticket encapsulates a symmetric key of an envelope (public message) intended for a specific service (ticket session key—the only key shared between two endpoints). The contents of the ticket are encrypted using a symmetric key shared between the service principal and the issued KDC. The encrypted portion of the ticket contains the client's principal name, among other items. The authentication code is a record that can indicate that it was most recently created using the ticket session key of the associated ticket. The ticket session key is known by the client that requested the ticket. The content of the authentication code is encrypted using the associated ticket session key. The encrypted part of the authentication code includes, among other items, a timestamp and the principal name of the client.

As shown in FIG. 4, the Kerberos (version 5) protocol consists of the following message exchanges between the client 405 and the KDC 410 and between the client 405 and the application server 415. That is, an AS (Authentication Service) exchange client obtains the “first” ticket from a Kerberos AS (authentication server), which is typically a TGT (Ticket Granting Ticket). The AS-REQ message 420 and the AS-REP 425 message are a request message and a response message between the client and the AS, respectively.
TGS (Ticket Granting Service) exchange Subsequently, the client uses the TGT to authenticate and requests a service ticket for a specific service from a Kerberos TGS (ticket-granting server). The TGS-REQ message 430 and the TGS-REP 435 message are a request message and a response message between the client and the TGS, respectively.
Client / Server AP (Authentication Protocol) Exchange Next, the client makes a request using an AP-REQ message 440 composed of a service ticket and an authentication code for authenticating the possession of the client's ticket session key. The server can optionally respond with an AP-REP message 445. AP exchanges typically negotiate session specific symmetric keys.

  AS and TGS are typically incorporated within a single device, also known as KCD.

  In the AS exchange, the KDC response, among other items, includes the ticket session key and is encrypted using a key (AS response key) shared between the client and the KDC. The AS response key is typically obtained from a client password for a human user. Thus, for human users, the resistance of the Kerberos protocol to attacks is not as strong as the effectiveness of human user passwords.

  To facilitate data origin authentication and complete secrecy, X. The use of asymmetric cryptography in the 509 certificate format (see RFC 3280 in the section of the document series “Request for Comments” managed by the “ISOC (Internet Society)”) has become widespread. An established PKI (Public Key Infrastructure) provides a key management and key distribution mechanism that can be used to establish authentication and secure communications. Adding public key cryptography to Kerberos provides a good congruence to the public key protocol, removes the burden of human users managing strong passwords, and allows kerberized applications to work with existing key services and identities. Make management available.

  The advantage provided by Kerberos TGT is that the client exposes the long-term secret only once. The TGT and its associated session key can then be used for any subsequent service ticket requests. In one result, all additional authentication is independent of the way in which the initial authentication was performed. As a result, the initial authentication provides a convenient place to incorporate public key cryptography into Kerberos authentication. In addition, the use of symmetric cryptography after the initial exchange is suitable for performance considerations.

  RFC4456 negotiates an AS response key known only by the client and the KDC using a public / private key pair that the client and the KDC mutually authenticate by an AS exchange, and sends an AS-REP sent by the KDC. Describes the methods and data formats that can be encrypted.

  Referring to FIG. 3, after completion of the TLS handshake (which can be a “double” handshake, as discussed with reference to FIG. 1), gateway 20 makes THR 45 a third party. Provide to the entity 40. As in the case of FIG. 1, again, the “trusting entity” (in this case, the third party entity 40) determines without being involved in the authentication between the client / user 10 and the gateway 20. Rather, the relying entity relies on THR to determine whether to provide user credentials to the gateway.

  More specifically, in a valid TLS handshake (ie, THR) exchange, the third party entity 40 returns the form of UC (user credential) to the gateway 20 as shown at reference numeral 55. The gateway 20 now authenticates to the web server 30 using the US, as indicated by reference numeral 65. In the case of KDC, the user credential is a Kerberos service ticket or TGT in the name of the user 10. In the case of CA, the user credentials are certificates in the user's name (usually with a short lifetime).

  FIG. 5 is an illustrative flow diagram illustrating the steps of the authentication process that are performed when a client / user attempts to access a web server of a system that includes a third party entity. In this system, the process begins when the client / user 10 accesses the gateway 20 (step 500). The client / user 10 then requests the desired web server 30 resources (step 510). If the client / user 10 is not logged into the web server, the client / user 10 must be authenticated before the web server 30 grants access.

  Client / user 10 and gateway 20 then perform a TLS handshake with client authentication in the manner detailed above (step 520). A record (THR) of at least a portion of the TLS handshake is created and provided to a third party entity (“trusting entity”) 40 (step 530).

  After receiving the THR, the third party entity 40 verifies that the user has been authenticated to the gateway (by enabling the THR certificate verification message) (step 540). If the THR is verified to be valid and fresh (step 550), the user credentials (eg, a temporary certificate in the case of CA or a Kerberos service ticket in the case of KDC) are provided to the gateway 20. (Step 560). The gateway 20 then authenticates to the web server 30 as a real client / user using the user credentials (step 570). However, if the THR is valid and cannot be verified as fresh (in step 550), the user credentials are not provided to the gateway 20 and access is denied (step 555).

  Assuming the client / user is authorized to access the web server, if the user credentials (eg, client certificate) are authenticated by the web server 30, the requested access to the web server is If the user is granted (step 580) and the client certificate cannot be verified, access is typically denied (step 590).

  User credentials are provided to the gateway 20 which consists of either a service ticket (in a KDC based deployment) or a temporary certificate (in a CA based deployment). The KDC-based deployment is almost the same as the Kerberos-constrained delegation (S4U2Self + S4U2Proxy) discussed above and will not be discussed further. Instead, CA-based deployment is discussed.

  In a CA-based deployment, when a valid and “fresh” THR is provided, the client certificate is issued using one or more CAs. In this scenario, the service provider (web server 30) is built to trust the CA (which typically has its own certificate installed in a certain location on the service provider's operating system. It must be provided) and provide the user's real identity.

  Once a client certificate is provided in the name of the user (and its associated private key), the gateway 20 then uses those credentials to authenticate to the service provider 30 as an actual user. In order to authenticate to a service provider (eg, web server 30) using the certificate and private key, the gateway 20 and the service provider must use an authentication protocol that supports client certificates. Two known authentication protocols that support client certificates are TLS (or SSL), or Kerberos (w / PKINIT). As discussed in more detail above, TLS (or SSL) can include client authentication (based on certificates). The PKINIT mechanism (RFC4556), entitled “Public Key Cryptography for Initial Authentication in Kerberos”, allows Kerberos-enabled clients via public key cryptography (ie, via a certificate and its associated private key). ) Protocol extension mechanism to Kerberos protocol that can obtain TGT. More specifically, such an extension provides a way to incorporate public key cryptography into the initial authentication exchange by using asymmetric key signatures and / or cryptographic algorithms in the pre-authentication data field.

  Assuming the client / user is authorized to access the web server, once the credentials (client certificate) are authenticated by the web server 30, the requested access to the web server is granted to the client / user. Is done. Of course, if the client certificate cannot be verified (ie if the web server is not built to trust the CA), the user is denied access to the web server.

  As in the embodiment of FIG. 1, a “double” TLS handshake can be implemented in the embodiment of FIG. 3 for further additional protection against attackers who compromise the gateway 20.

  Although the subject matter of the invention herein has been described in language specific to structural features and / or methodological actions, the subject matter of the invention as defined in the claims refers to the specific features or acts described above. It should also be understood that it is not necessarily limited. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

  For example, throughout this document we refer to a set of entities consisting of service providers accessed by clients / users via a gateway. However, this is only one possible scenario and is only used throughout this document for convenience. Another possible scenario involves a web server that needs to authenticate as a user to a backend application or database. The novel aspects of the present disclosure can be applied to a series of entities that require authentication between entities in a chain. There can be any number of entities in the chain where each entity must authenticate to the next entity in the chain as the original client.

  It is further understood that when one element is displayed as reacting to another element, the elements can be connected directly or indirectly. The connections illustrated herein can actually be logical or physical to provide a coupling or communication interface between elements. The connection can be implemented as inter-process communication between software processes or machine-to-machine communication between network computers, among others.

  The terms “exemplary” and “descriptive” as used herein are meant to serve as examples, instances, or illustrations. Any implementation or aspect thereof described herein as “exemplary” or “descriptive” is not necessarily configured to be preferred or advantageous over other implementations or aspects thereof.

  It is understood that embodiments other than the specific embodiments described above can be devised without departing from the spirit and scope of the appended claims, so the scope of the subject matter herein is set forth in the following claims. It is intended to comply with the scope of

Claims (18)

A method of authentication delegation between a client / user accessing a service provider via a gateway,
Performing a TLS handshake with client authentication between the client / user and the gateway, wherein the TLS handshake is defined by a protocol identifying a plurality of message exchanges;
Recording the message exchanged in the TLS handshake as authentication evidence certifying that the client / user has been authenticated by the gateway, wherein the message exchanged in the TLS handshake is a certificate verification Including all messages identified in the protocol up to a message, wherein the certificate verification message comprises a signature for all previous messages of the TLS handshake;
Providing the record from the gateway to the service provider;
The service provider determining, based on the record, whether to allow access from the client / user .   The method of claim 1, wherein the service provider is not involved in authentication between the client / user and the gateway.   The method of claim 1, wherein the providing step provides a record directly from the gateway to the service provider.   The method of claim 1, further comprising incorporating time-related data into the TLS handshake message.   The method of claim 4, wherein the client / user incorporates data related to the time.   The method of claim 4, wherein the gateway incorporates data related to the time.   The method of claim 1, further comprising incorporating a nonce provided by the service provider into a message from the gateway to the client / user as part of the TLS handshake.   The method of claim 1, wherein the service provider maintains a memory of all received records and verifies that the same record has not been used more than once. The step of performing a TLS handshake includes:
Performing a first handshake without client authentication;
The method of claim 1, further comprising: performing a second handshake with client authentication after successful completion of performing the first handshake.   The method of claim 9, wherein the second handshake between the client / user and the gateway is encrypted with a session key obtained from the first handshake.   The method of claim 10, wherein the record provided to the service provider is not encrypted. A method of granting access to a service on an end server using authentication delegation,
The end server receiving a request to access a service requested by a user;
Said end server, to prove that the recording of the messages exchanged in the TLS handshake with client authentication performed between the user and the gateway / intermediate server, the user is authenticated to the gateway / intermediate server Receiving from the gateway / intermediate server as authentication evidence, wherein the TLS handshake is defined by a protocol specifying a plurality of message exchanges, and the messages exchanged in the TLS handshake are certificate verification messages Including all messages specified in the protocol, wherein the certificate verification message comprises a signature for all previous messages of the TLS handshake;
Said end server, using the recording, the re-verify the TLS handshake, make sure that the method comprising the steps to verify the identity of the user, the step is, the same record is not used more than once A method comprising the steps of : A method of authentication delegation between a client / user accessing a service provider via a gateway,
Performing a TLS handshake with client authentication between the client / user and the gateway, wherein the TLS handshake is defined by a protocol identifying a plurality of message exchanges , the step having client authentication. Performing a first handshake that does not, and performing a second handshake with client authentication after successful completion of the step of performing the first handshake ;
Recording the message exchanged in the second handshake as authentication evidence proving that the client / user has been authenticated to the gateway, wherein the message exchanged in the second handshake is Including all messages specified in the protocol up to a certificate verification message, the certificate verification message comprising a signature for all previous messages of the second handshake;
Providing the record from the gateway to a third party entity;
Receiving a user credential from the third party entity after the validity of the record by the third party entity;
Authenticating the user to the service provider using the user credential, the gateway performing the method.   The method of claim 13, wherein the third party entity is a Certificate Authority.   The method of claim 14, wherein the step of receiving user credentials comprises receiving a temporary certificate and associated private key.   The method of claim 14, wherein the step of authenticating the user to the service provider is performed using Kerberos using PKINIT.   14. The method of claim 13, wherein the third party entity is a KDC and the step of receiving user credentials comprises receiving a Kerberos service ticket from the KDC.   The method of claim 13, wherein the third party entity resides with a single device gateway.

Images