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

Authentication delegation based on re-verification of cryptographic evidence Download PDF

Info

Publication number
JP5599910B2
JP5599910B2 JP2013024845A JP2013024845A JP5599910B2 JP 5599910 B2 JP5599910 B2 JP 5599910B2 JP 2013024845 A JP2013024845 A JP 2013024845A JP 2013024845 A JP2013024845 A JP 2013024845A JP 5599910 B2 JP5599910 B2 JP 5599910B2
Authority
JP
Japan
Prior art keywords
user
client
gateway
handshake
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013024845A
Other languages
Japanese (ja)
Other versions
JP2013138474A (en
Inventor
メドゥビンスキー ジェナディ
ナイス ニール
シラン トマー
テプリットスキー アレクサンダー
Original Assignee
マイクロソフト コーポレーション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US11/607,720 priority Critical
Priority to US11/607,720 priority patent/US9055107B2/en
Application filed by マイクロソフト コーポレーション filed Critical マイクロソフト コーポレーション
Publication of JP2013138474A publication Critical patent/JP2013138474A/en
Application granted granted Critical
Publication of JP5599910B2 publication Critical patent/JP5599910B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0884Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • H04L29/06551Arrangements for network security
    • H04L29/06945Security features implemented at a particular protocol layer
    • H04L29/06965Security features implemented at a particular protocol layer at the transport layer, e.g. SSL, TLS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0807Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • H04L9/3213Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 using tickets or tokens, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115Third party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/38Chaining, e.g. hash chain or certificate chain
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121Timestamp
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0823Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using certificates

Description

組織は、あるサービスをユーザーに一緒に提供する一連のエンティティを有することができる。例えば、データ、ウェブページ、機能的なソフトウェアオペレーションなどのリソースへのアクセスは、習熟かつ権限を与えられた一定のユーザーに限定する必要がある。権限のないユーザーや悪意のある攻撃者が、ウェブリソースにアクセスしようとしているユーザーのアイデンティティを認証するのに使用される機構を含むコンピューターリソースにアクセスすることを阻止するために、さまざまなアクセス制御方式が開発されている。特に、個人情報盗難の攻撃(例えば、フィッシング、ファーミング)の増加により、2要素認証が一般的になりつつある。   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)とは、アイデンティティと権限を確立するための異なる2つの方法を必要とする任意の認証プロトコルである。T−FAの一般的な実装は、要因の一つとして「あなたが知るもの」(例えば、パスワードまたは個人識別番号)を使用し、他の要因として「あなたが有するもの」(例えば、クレジットカードまたはハードウェアトークン)か、あるいは「あなたであるもの」(例えば、指紋または網膜のパターン)を使用する。例えば、スマートカードは、T−FAを提供する方法の1つである。スマートカードは、ハードウェアトークンの一例であり、典型的には、所与のデータ上の暗号化機能を実行するなどのさまざまなセキュリティ動作が可能であるマイクロプロセッサーを含む。スマートカードは通常、証明書ベースの認証を要求するプロトコルに使用できる1つまたは複数のITU−T(International Telecommunication Union)X.509証明書(およびそれらに関連する秘密鍵)を保持する。SSL(Secure Socket Layer)、TLS(Transport Layer Security)、およびKerberos(「Public Key Cryptography for Initial Authentication in Kerberos」の省略である、PKINITを用いる)は、そのようなプロトコルのすべての例である。   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.
証明書を使用するのにスマートカードは必要ない。多くのデバイス(例えば、コンピューター、携帯電話)は、証明書(およびそれらに関連する秘密鍵)を格納し、使用することが可能である。例えば、Windows(登録商標) Mobile 5.0 は、(SSLまたはTLSの最上部で起動する Exchange ActiveSynch プロトコルを経由して)Eメールやカレンダー情報を同期化するために、証明書を使用して、Exchange 2003 SP2 サーバー に対して認証することができる。   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.
再検証または暗号証拠に基づいた認証委任は、ユーザーが一連のエンティティ内の特定のサーバーにアクセスを望むとき、ゲートウェイデバイスとユーザー間のTLSハンドシェイクの少なくとも一部の記録を利用する。暗号証拠は、TLSハンドシェイクの記録された部分を(1)サーバーが記録された部分を再検証して認証を確認する場合の所望のサーバーか、または(2)第三者エンティティが、記録された部分を再検証し、ユーザー資格をゲートウェイに提供することによって認証を確認し、今度はその資格を使用して、ユーザーとしてサーバーに対して認証する場合の第三者エンティティのいずれかに転送することによって提供される。いずれの場合にも、サーバーおよび第三者エンティティは、ユーザーとゲートウェイデバイス間の認証に関与せずに、TLSハンドシェイクの記録された部分を使用してユーザーアクセスを許可するかどうかの判定をする。   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. .
さまざまな説明的な例において、暗号証拠は、TLSハンドシェイクが時宜にかなう(すなわち、「フレッシュ(fresh)」)ように保証することによって付加的なセキュリティ対策を提供するために、タイムスタンプを含む。加えて、有効なTLSハンドシェイクを確認した後、第三者エンティティは、ゲートウェイが、ユーザーに代わって、例えば、PKINITを用いたKerberosを使用して、所望のサーバーに対して認証できる一時的な(すなわち、期限付き)ユーザー資格を発行するように設定することができる。   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.
TLSハンドシェイクメッセージの再検証に基づく認証委任のための説明的なアーキテクチャの簡易化した機能的なブロック図である。FIG. 6 is a simplified functional block diagram of an illustrative architecture for authentication delegation based on revalidation of TLS handshake messages. 図1の例示的なアーキテクチャを利用して、認証プロセスのステップを示す説明的なフロー図である。FIG. 2 is an illustrative flow diagram showing the steps of an authentication process utilizing the exemplary architecture of FIG. ユーザー資格が、TLSハンドシェイクの少なくとも一部の記録を受信する第三者エンティティによって提供される認証委任のための説明的なアーキテクチャの簡易化した機能的なブロック図である。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. クライアントとKerberos(バージョン5)プロトコルにおける鍵配布センター間の説明的なメッセージ交換を示す図である。It is a figure which shows explanatory message exchange between the key distribution center in a client and Kerberos (version 5) protocol. 図3の例示的なアーキテクチャを利用して、認証プロセスのステップを示す説明的なフロー図である。FIG. 4 is an illustrative flow diagram illustrating the steps of the authentication process utilizing the exemplary architecture of FIG. 典型的なTLSハンドシェイクフェーズのクライアントとサーバー間のメッセージの交換を示す概略メッセージフロー図である。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.
再検証または暗号証拠に基づいた本認証委任の説明的なコンテキストは、クライアント/ユーザーがゲートウェイを通じて1つまたは複数のサービスプロバイダーにアクセスするものである。しかしながら、このコンテキストは単に説明的であり、他のコンテキストおよび環境でも適用できることを強調しておく。例えば、本認証委任は、ウェブサーバーがバックエンドアプリケーションまたはデータベースに対してユーザーとして認証する必要があるとき、もしくは代替的に一連のエンティティがあり連鎖するエンティティ間で認証が必要とされる場合の任意の設定において使用することができる。   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.
ゲートウェイを組み込んで、FBA(form-based authentication)を使用する場合、ユーザーは、ログオン形式でユーザー名およびパスワードを入力する必要がある。次にユーザーは、この形式を提出し、ゲートウェイは、ユーザーのユーザー名およびパスワードを受信する。次にゲートウェイは、それらの資格を使用して、ユーザーに代わって内部のウェブサーバーに対して認証することができる。ゲートウェイがパスワードを受信し、要望通りにパスワードを使用することができるため、これは非常に簡単であり実行可能である。しかしながら、ある認証方式と一緒にはこれは実行できない。例えば、ユーザーが、パスワードを提供しない認証方式を使用してゲートウェイに対して認証する場合、ゲートウェイは、ユーザーに代わって内部のウェブサーバーに対して認証するために再使用することができる何らの資格を有さない。   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.
信頼された第三者を組み込んで、具体的な条件の下にサービスチケットを提供することもできる。例えば、Kerberosプロトコルにおいて、クライアントは、サービスチケットを介してゲートウェイに対して認証し、Kerberosに制約された委任は、信頼された第三者(鍵配送センター)を組み込んで、その条件を課すことができる方法を提供する。この場合では、ゲートウェイは、主張したユーザーが実際にゲートウェイに認証(サービスチケットを介して)された証拠を提供しなければならない。これは、システム全体のセキュリティを強化するのに重要である。例えば、このような証拠を要求する利点は、侵害されたゲートウェイは、最初にユーザーがそのゲートウェイに正しく認証されなければユーザーに代わってサーバーにアクセスすることができないことである。   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.
これらの提案がパスワードなしの認証に対処するための方法を提供する一方で、場合によっては、KDC(Key Distribution Center)または他の信頼された第三者エンティティと関与しない認証委任モデルを実装するのが望ましいかもしれない。このようなモデルにおいて、ゲートウェイは、KDCとの通信を全く行わずに、ユーザーに代わって内部のウェブサーバーに対して認証する。この種の機能性を提供する多くの解決方法がある。例えば、一部の製品は、いったんユーザーがゲートウェイに対して認証すると、そのゲートウェイは、内部のウェブサーバーによって信頼されたトークン(HTTP(Hypertext Transfer Protocol) 場合によってはクッキー(cookie))を戻すことができるように、ゲートウェイおよび任意の数の内部のウェブサーバー上でインストール/組み込むことができる。他の提案と同様に、このモデルに対する1つの問題は、ゲートウェイは完全に信頼されたエンティティであるので、システムの全体のセキュリティを低下させることである。   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.
本配置は、暗号証拠の再検証に基づいた認証委任を提供する。ゲートウェイ(またはフロントエンドサーバー)は、ウェブサーバー(またはバックエンドサーバー)へのアクセスを提供する。クライアント/ユーザーは、クライアント認証を有するTLSハンドシェイクを使用してゲートウェイに対して認証する。TLSハンドシェイクの記録、または少なくともユーザーがゲートウェイに認証されたことを証明するのに十分なTLSハンドシェイクの記録は、次いで、ウェブサーバー(そのハンドシェイクの有効性を再検証する)か、または第三者エンティティ(その記録を検証した後、ユーザー資格をゲートウェイに提供し、次にゲートウェイは、ウェブサーバーに対して認証する)のいずれかに提供される。   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).
これより同様の参照番号が同様の要素を指す図を参照しながら、図1に本認証委任を利用する例示的なネットワークアーキテクチャを示す。クライアント/ユーザーコンピューターシステム10を、ゲートウェイ20(認証サーバとも呼ばれる)に動作可能につなげることによって、クライアント/ユーザー10とウェブサーバー30(ネットワークサーバーとも呼ばれる)のネットワーク間の通信ができるようになる。ゲートウェイ20は、ユーザーを認証するのに必要な情報を含むデータベース/ディレクトリ(図示せず)を含む(代替的に、ゲートウェイは、外部のユーザーデータベース/ディレクトリを用いてネットワーク上で通信することができる)。ログオンに応答して、ユーザー/クライアント10は、参照数字35に示すように、最初にクライアント認証を有するTLSハンドシェイクを経由してゲートウェイ20に対して認証する。TLSハンドシェイクプロトコルではクライアント認証が随意的であるため、クライアント認証は、ここで意図的に述べられていることに留意されたい。   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.
TLSプロトコルは、インターネット上で通信プライバシーを提供し、クライアント/サーバーアプリケーションが、盗聴、改ざん、またはメッセージ偽造を阻止するように設計された方法によって通信することを可能にする。TLSハンドシェイクプロトコルによって、アプリケーションプロトコルがそのデータの最初のバイトを送信または受信する前に、サーバーとクライアントは、互いに認証し合い、暗号アルゴリズムと暗号鍵を交渉することができる。   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.
TLSの1つの利点は、アプリケーションプロトコルインディペンデントがあることである。従って上位レベルプロトコルを、透過的にTLSプロトコルの最上層に置くことができる。TLSハンドシェイクプロトコルを、以下のように要約することができる。すなわち、ユーザー/クライアントは、クライアントのハローメッセージを、サーバーのハローメッセージによって応答しなければならないサーバー(図1のゲートウェイ20)に送信する。さもなければ、致命的なエラーが起こり、この接続が失敗する。クライアントのハローとサーバーのハローを使用して、クライアントとサーバー間のセキュリティ強化機能を確立する。   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.
図6は、典型的なTLSハンドシェイクフェーズのクライアントとサーバー間のメッセージ交換を示す概略メッセージフロー図である。TLSプロトコルは、RFC2246のTLSプロトコル バージョン1.0において詳細に記載されており、この開示は、参照することによって本明細書に組み込まれる。クライアント/ユーザーは、クライアント−サーバー関係においてゲートウェイデバイスと通信する。   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.
さらに具体的には、図6に示すように、実際の鍵交換は、メッセージを4つまで使用する。すなわち、サーバー証明書、サーバー鍵交換、クライアント証明書、およびクライアント鍵交換である。新しい鍵交換方法は、これらのメッセージに対しフォーマットを指定し、そのメッセージの使用を定義することによって作り出され、これによってクライアントとサーバーは、共有秘密に対して合意できる。ハローメッセージの後、サーバーは、そのメッセージが認証されるべきであるならば、メッセージの証明書を送信する。加えて、要求される場合は(例えば、サーバーが証明書を有しないか、または署名のみに対するものである場合)サーバー鍵交換メッセージを送信することができる。   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).
サーバーが認証された場合、暗号スイートの選択がふさわしければ、サーバーは、クライアントから証明書を要求することができる。次にサーバーは、ハンドシェイクのハローメッセージフェーズが完了したことを表示する、サーバーのハロー完了メッセージを送信する。次にサーバーは、クライアントの応答を待つ。サーバーが、証明書要求メッセージ(certificate request message)を送信した場合、クライアントは、その証明書メッセージを送信しなければならない。クライアント鍵交換メッセージが送信され、そのメッセージ内容は、クライアントハローとサーバーハロー間で選択した公開鍵アルゴリズムに依存する。クライアントが署名機能を有する証明書を送信した場合、デジタル署名された証明書検証メッセージを送信して、この証明書を明確に検証する。   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.
図1に戻ると、この説明的な例において、ゲートウェイ20は、このハンドシェイクの一部として交換されたデータの記録(図1では参照番号45とともにTHRとして示す)を作成する。より詳しくは、この記録は、TLSハンドシェイクの以前のすべてのメッセージに対する署名から成り、ユーザー/クライアント10がその証明書と一致する秘密鍵を実際に所有することを証明する、証明書検証メッセージまでのデータを少なくとも含む。   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.
TLSハンドシェイクの記録、またはTHRは次に、ユーザー/クライアント10がゲートウェイ20に認証された認証証拠(すなわち、「プルーフ(proof)」)として、内部のウェブサーバー30に直接提供される。   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”).
内部のウェブサーバー30は、クライアント/ユーザー10とゲートウェイ20間の認証に関与せずに、単にクライアント/ユーザー10とゲートウェイ20間の認証の認証証拠(すなわち、THR)を提供されて、次いで所望のリソースへのアクセスを提供するかどうかに関する判定をするにすぎない。   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.
提案された方式は、TLSハンドシェイクが証明書検証メッセージを含む場合しか使用できないことに留意されたい。このメッセージは、以下のいずれかの条件が真である場合は使用されない。すなわち
1)TLSハンドシェイクは、クライアント認証を含まない。
2)クライアントとゲートウェイは、(新しいセキュリティパラメータを交渉する代わりに)以前のTLSセッションを再開するまたは現在のセッションを繰り返す決定をする。この場合、TLSハンドシェイクは、証明書検証メッセージを含まない(RFC2246の30−31ページ参照)。
3)クライアント証明書は、署名機能(すなわち、固定ディフィー・へルマンパラメーターを含むものを除くすべての証明書)を有する。例えば、暗号スイート ECDH_ECDSAとECDH_RSA(RFC4492参照)は、クライアント認証をサポートするが、証明書検証メッセージは利用しない。
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.
図2は、図1に示した例示的なアーキテクチャにおいて、クライアント/ユーザーが、ウェブサーバーへアクセスしようとするときに実行される認証プロセスの説明的なフロー図である。このプロセスは、クライアント/ユーザーが、ウェブサーバーリソースを所望し、ゲートウェイ20にアクセスするときに開始する(ステップ200)。クライアント/ユーザーが、ウェブサーバーにログインしていない場合、そのクライアント/ユーザーは、ウェブサーバーがアクセスを許可する前に、認証されなければならない。   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.
クライアント/ユーザーは次に、所望のウェブサーバーリソースを要求する(ステップ210)。クライアント/ユーザーを認証するために、ゲートウェイ20とクライアント/ユーザー10は次に、上記に詳しく説明した方法によってクライアント認証を有するTLSハンドシェイクを実行する(ステップ220)(当業者は当然、ゲートウェイ20は、クライアント/ユーザーが所望のリソースを要求する前か、またはクライアント/ユーザーがリソースを要求した後に、即座にクライアント/ユーザー10を認証できることを理解するだろう)。TLSハンドシェイクの少なくとも一部の記録が作成されて、要求されたウェブサーバーに提供される(ステップ230)。   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).
THRの受信後、ウェブサーバー30は、クライアント/ユーザーが、ゲートウェイに認証されたことを検証する(証明書のクライアント/ユーザーの署名を有効にすることによって、THRのメッセージおよびある実施形態におけるTHRのタイムスタンプ(以下に論ずる)も検証する)(ステップ240)。クライアント/ユーザーがウェブサーバーにアクセスする権限を与えられたと仮定して、THRが検証された場合、要求されたウェブサーバーへのアクセスが許可され(ステップ250)、THRが検証されない場合、そのアクセスは拒否される(ステップ260)。   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).
攻撃者がTHRを取得できて、THRを再使用してクライアント/ユーザーに成り済まそうとする場合に、このような「リプレイアタック」を阻止するか、または少なくとも抑制するために想定されるいくつかの技術および機構がある。まず、サーバーおよび/またはクライアント/ユーザーが、時間に関連するデータ(例えば、タイムスタンプ)をそれらのハンドシェイクメッセージに組み込んだと仮定して、サービスプロバイダー(例えば、内部のウェブサーバー)は、受信したTHRを調べて、それが「フレッシュ」であることを確認することができる。この解決方法は、典型的には、ゲートウェイ20およびウェブサーバー30に(またはユーザー/クライアント10およびウェブサーバー30)、同期化されたクロックを有するよう要求する。とはいえ、当業者は当然、多くの実現可能な次善策があることがわかるだろう。   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.
代替的に、ゲートウェイ20は、サービスプロバイダー(ウェブサーバー30)にノンスを求め、TLSハンドシェイクの一部としてユーザー/クライアント10に送信するメッセージの1つの中にノンスを組み込むことが可能である。サービスプロバイダーは次に、受信したTHRを調べて、それが以前に作成されてゲートウェイ20を通過したノンスを含むことを確認することができる。   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.
このような2つの可能性のいずれにおいても、ゲートウェイ20(またはユーザー/クライアント10)は、あるデータをTLSハンドシェイクメッセージに組み込む(さらに、ハンドシェイクプロトコルは基本的に、データ転送セッションのセキュリティパラメータを交渉する一連の順序付けられたメッセージである)。このようなデータの組み込みは、典型的には、以下の方法の1つによって行われるものとする。すなわち
(1)サーバーは、タイムスタンプまたはノンスをサーバーのハローメッセージ内に、このメッセージのランダムフィールドの一部として、置く(ハンドシェイクプロトコルのこの態様の詳細は、RFC2246の7.4.1.3節に見出すことができる)
(2)サーバーは、タイムスタンプまたはノンスをサーバーのハロー拡張子に置く(詳細は、RFC3546の2.2節に見出すことができる)
(3)クライアント/ユーザーは、タイムスタンプをクライアントのハローメッセージ内に、このメッセージのランダムフィールドの一部として、置く(ハンドシェイクプロトコルのこの態様の詳細は、RFC2246の7.4.1.2節に見出すことができる)
(4)クライアント/ユーザーは、タイムスタンプをクライアントのハロー拡張子内に置く(詳細は、RFC3546の2.1節に見出すことができる)
最後に、上記の代替案の各々に加えて、サービスプロバイダ(ウェブサーバ30)は、同じTHRを2回以上使用しないことを保証するために、受信するすべてのTHRを記憶することが可能である。この記憶は、ある共有された記憶装置または通信機構を経由して、サービスプロバイダー間で共有することも可能である。
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.
別の説明的な実装において、ゲートウェイまたはクライアントとゲートウェイ間の通信チャネルを侵害する攻撃者に対するより一層の防御として、「2重の」TLSハンドシェイクを使用することができる。この場合、クライアント/ユーザー10およびゲートウェイ20は、クライアント認証を有しない第1のTLSハンドシェイクを実行する。第1のTLSハンドシェイクがうまく完了したとき、クライアント/ユーザー10およびゲートウェイ20は、クライアント認証を有する第2のTLSハンドシェイクを実行する。後に証拠(THR)として使用される第2のハンドシェイクは、クライアント/ユーザー10およびゲートウェイ20が第1のハンドシェイクから得たセッション鍵によって送信のために暗号化される。従ってTHRは、暗号化されずに(例えば、暗号化されていない文章で)送信されないように防御されているので、攻撃者がたとえゲートウェイ20を侵害できたとしても、THRを取得するのはより困難になるだろう。   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.
これまで論じられ、図1に示した実施形態は、ユーザー/クライアント10、ゲートウェイ20、およびサービスプロバイダー(ウェブサーバー30)から成る。図3に示す、以下でより詳細に論じられる代替的実施形態では、第三者エンティティ40を利用する。この場合、サービスプロバイダー(ウェブサーバー30)は、第三者エンティティ40を「信頼」して、ユーザーの実アイデンティティを提供する。このような第三者エンティティ40を、KerberosKDC(S4U2Self+S4U2Proxyなど)またはCA(Certificate Authority、認証局)にすることができる。第三者エンティティ40を、個別のエンティティとして図3に示しているが、ある構成においては、第三者エンティティ(KDCまたはCA)は、ゲートウェイ20として同じマシン上に常駐することに留意する。   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.
図3に示した実施形態をさらに具体的に論じる前に、KDCとして知られる信頼された第三者の使用に関与するKerberosプロトコルが、クライアントとサービス間の共有セッション鍵を交渉し、クライアントとサービス間の相互認証を提供することを論ずる。   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.
Kerberosの基礎は、チケットと認証コードである。チケットは、特定のサービスを目的とするエンベロープ(公開メッセージ)の対称鍵(チケットセッション鍵−2つのエンドポイント間で共有されるただ1つの鍵である)をカプセル化する。チケットの内容は、サービスのプリンシパルと発行するKDC間で共用される対称鍵を用いて暗号化される。チケットの暗号化された部分は、他の項目の中で、クライアントのプリンシパル名を含む。認証コードは、関連するチケットのチケットセッション鍵を使用して、直近に作成されたことを示すことができる記録である。チケットセッション鍵は、そのチケットを要求したクライアントにより公知である。認証コードの内容は、関連するチケットセッション鍵を用いて暗号化される。認証コードの暗号化された部分は、他の項目の中で、タイムスタンプとクライアントのプリンシパル名を含む。   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.
図4に示したように、Kerberos(バージョン5)プロトコルは、以下のクライアント405とKDC410間、およびクライアント405とアプリケーションサーバー415間のメッセージ交換から成る。すなわち
AS(Authentication Service、認証サービス)交換
クライアントは、典型的にはTGT(Ticket Granting Ticket、チケット保証チケット)である、KerberosAS(authentication server)から「最初の」チケットを取得する。AS−REQメッセージ420とAS−REP425メッセージはそれぞれ、クライアントとAS間の要求メッセージと応答メッセージである。
TGS(Ticket Granting Service、チケット保証サービス)交換
続いてクライアントは、認証するためにTGTを使用して、KerberosTGS(ticket-granting server)から特定のサービスのサービスチケットを要求する。TGS−REQメッセージ430とTGS−REP435メッセージはそれぞれ、クライアントとTGS間の要求メッセージと応答メッセージである。
クライアント/サーバーAP(Authentication Protocol、認証プロトコル)交換
次にクライアントは、クライアントのチケットセッション鍵の所有を認証するサービスチケットと認証コードから成るAP−REQメッセージ440を用いて要求する。サーバーは、随意的に、AP−REPメッセージ445を用いて応答することができる。AP交換は、典型的には、セッション固有対称鍵を交渉する。
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およびTGSは、典型的には、KCDとしても知られる単一のデバイス内に組み込まれる。   AS and TGS are typically incorporated within a single device, also known as KCD.
AS交換において、KDC応答は、他の項目の中で、チケットセッション鍵を含み、クライアントとKDC間で共有される鍵(AS応答鍵)を使用して暗号化される。AS応答鍵は、典型的には、人間ユーザー用のクライアントのパスワードから得られる。従って、人間ユーザーにとって、攻撃に対するKerberosプロトコルの抵抗力は、人間ユーザーのパスワードの効力ほど強くない。   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.
データ発信元認証および完全秘密を容易にするために、X.509証明書形式での非対称暗号の使用(「ISOC(Internet Society、インターネット協会)」によって管理された文書シリーズ「Request for Comments」の項目でRFC3280を参照)が普及している。確立されたPKI(Public Key Infrastructure、公開鍵基盤)は、認証および安全な通信を確立するために使用することができる鍵管理および鍵分散機構を提供する。公開鍵暗号をKerberosに付加することは、公開鍵プロトコルに上手い合同式を提供し、強力なパスワードを管理する人間ユーザーの負担を取り除き、ケルベライズ(Kerberized)されたアプリケーションが、現存する鍵サービスおよびアイデンティティ管理を利用できるようにする。   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.
KerberosTGTにより与えられる利点は、クライアントが、長期間の秘密を1回しかさらさないことである。TGTおよびそれに関連するセッション鍵は次に、後に続く任意のサービスチケット要求に対して使用することができる。1つの結果では、すべての追加的な認証が、最初の認証が実行された方法から独立している。その結果、最初の認証は、公開鍵暗号をKerberos認証に組み込むのに便利な場所を提供する。加えて、最初の交換の後の対称暗号の使用は、性能考察に適している。   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は、クライアントおよびKDCが、AS交換によって相互に認証する公開鍵と秘密鍵の組を使用して、クライアントとKDCのみにより知られるAS応答鍵を交渉し、KDCによって送信されたAS−REPを暗号化できる方法およびデータ形式について記載する。   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.
図3を参照すると、TLSハンドシェイク(図1への参照とともに論じられたのと同様に、「2重の」ハンドシェイクにすることができる)の完了後、ゲートウェイ20は、THR45を第三者エンティティ40に提供する。図1の場合のように、再度、「信頼するエンティティ」(この場合、第三者エンティティ40)は、クライアント/ユーザー10とゲートウェイ20間の認証に関与せずに判定する。むしろ、信頼するエンティティは、THRに依存して、ユーザー資格をゲートウェイに提供するかどうかを判定する。   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.
さらに具体的には、有効なTLSハンドシェイク(すなわち、THR)の交換において、第三者エンティティ40は、参照番号55に示すように、UC(user credential)の形式をゲートウェイ20に戻す。ゲートウェイ20は、今度は、参照番号65に示すように、USを使用してウェブサーバー30に対して認証する。KDCの場合、ユーザー資格は、ユーザー10の名におけるKerberosのサービスチケットまたはTGTとなる。CAの場合、ユーザー資格は、ユーザーの名における証明書(通常、短い存続期間とともに)となる。   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).
図5は、クライアント/ユーザーが、第三者エンティティを含むシステムのウェブサーバーにアクセスしようとするときに実行される認証プロセスのステップを示す説明的なフロー図である。このシステムにおいて、そのプロセスは、クライアント/ユーザー10がゲートウェイ20にアクセスするときに開始する(ステップ500)。クライアント/ユーザー10は次に、所望のウェブサーバー30のリソースを要求する(ステップ510)。クライアント/ユーザー10がウェブサーバーにログインしていない場合、そのクライアント/ユーザー10は、ウェブサーバー30がアクセスを許可する前に認証されなければならない。   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.
クライアント/ユーザー10およびゲートウェイ20は次に、上記に詳細に示した方法でクライアント認証を有するTLSハンドシェイクを実行する(ステップ520)。TLSハンドシェイクの少なくとも一部の記録(THR)が作成され、第三者エンティティ(「信頼するエンティティ」)40に提供される(ステップ530)。   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).
THRの受信後、第三者エンティティ40は、ユーザーがゲートウェイに認証されたことを検証する(THRの証明書検証メッセージを有効化することによって)(ステップ540)。THRが有効かつフレッシュであると検証された場合(ステップ550)、ユーザー資格(例えば、CAの場合における一時的な証明書、またはKDCの場合におけるKerberosのサービスチケット)は、ゲートウェイ20に提供される(ステップ560)。ゲートウェイ20は次に、ユーザー資格を使用して、実クライアント/ユーザーとしてウェブサーバー30に対して認証する(ステップ570)。しかしながら、THRが有効かつフレッシュと検証できない場合(ステップ550において)、ユーザー資格は、ゲートウェイ20に提供されず、アクセスは拒否される(ステップ555)。   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).
クライアント/ユーザーがウェブサーバーにアクセスする権限を与えられたと仮定して、ユーザー資格(例えば、クライアントの証明書)がウェブサーバー30によって認証された場合、要求されたウェブサーバーへのアクセスは、クライアント/ユーザーに許可され(ステップ580)、クライアント証明を検証できない場合、アクセスは、典型的には、拒否される(ステップ590)。   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).
ユーザー資格は、サービスチケット(KDCベースのデプロイメントにおける)か、一時的な証明書(CAベースのデプロイメントにおける)のいずれかから成るゲートウェイ20に提供される。KDCベースのデプロイメントは、上記で論じたKerberosに制約された委任(S4U2Self+S4U2Proxy)とほぼ同じなので、これ以上論じない。その代わりに、CAベースのデプロイメントについて論じる。   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.
CAベースのデプロイメントにおいて、有効かつ「フレッシュ」なTHRが提供されたとき、1つまたは複数のCAを使用してクライアント証明書を発行する。このシナリオにおいて、サービスプロバイダー(ウェブサーバー30)は、CAを信頼するように組み込まれて(これは典型的には、CA自体の証明書は、サービスプロバイダーのオペレーティングシステム上のある特定の場所にインストールされなければならないことを意味する)、ユーザーの実アイデンティティを提供しなければならない。   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.
いったんユーザー(およびそれに関連する秘密鍵)の名においてクライアント証明書が与えられると、ゲートウェイ20は次に、実際のユーザーとしてサービスプロバイダー30に対して認証するこれらの資格を使用する。証明書および秘密鍵を使用してサービスプロバイダー(例えば、ウェブサーバー30)に対して認証するために、ゲートウェイ20およびサービスプロバイダーは、クライアント証明書をサポートする認証プロトコルを使用しなければならない。クライアント証明書をサポートする2つの公知の認証プロトコルは、TLS(またはSSL)、またはKerberos(w/PKINIT)である。上記により詳細に論じたように、TLS(またはSSL)は、(証明書に基づいた)クライアント認証を含むことができる。「Public Key Cryptography for Initial Authentication in Kerberos」と題したPKINIT機構(RFC4556)は、Kerberosを使用可能のクライアントが、公開鍵暗号を経由して(すなわち、証明書およびそれに関連する秘密鍵を経由して)TGTを取得できるKerberosプロトコルへのプロトコル拡張の機構である。さらに具体的には、このような拡張は、事前認証データフィールドの非対称鍵署名および/または暗号アルゴリズムを使用することによって、公開鍵暗号を最初の認証交換に組み込む方法を提供する。   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.
クライアント/ユーザーがウェブサーバーにアクセスする権限を与えられたと仮定して、いったん資格(クライアント証明書)がウェブサーバー30によって認証されると、要求されたウェブサーバーへのアクセスは、クライアント/ユーザーに許可される。もちろんクライアント証明書が検証できない場合(すなわちウェブサーバーがCAを信頼するように組み込まれてない場合)、ユーザーによるウェブサーバーへのアクセスは拒否される。   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.
図1の実施形態にあるように、「2重の」TLSハンドシェイクを、ゲートウェイ20を侵害する攻撃者に対するさらなる追加的な防御のために、図3の実施形態に実装することができる。   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.
例えば、この文書を通じて我々は、ゲートウェイを介してクライアント/ユーザーがアクセスするサービスプロバイダーから成る一連のエンティティを参照する。しかしながら、これは、実現可能なシナリオの1つにすぎず、便宜上この文書を通じて使用されているにすぎない。他の実現可能なシナリオは、バックエンドアプリケーションまたはデータベースに対するユーザーとして認証する必要があるウェブサーバーを含む。本開示の新規の態様は、連鎖の中のエンティティ間の認証を要求する一連のエンティティに適用できる。各エンティティが元のクライアントとして連鎖中の次のエンティティに対して認証しなければならない、連鎖中の任意の数のエンティティにすることができる。   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.
1つの要素が別の要素に反応するものとして表示される場合、それらの要素を、直接的または間接的につなげられることがさらに理解される。本明細書に図示した接続を、要素間の結合または通信インタフェースを実現するために、実際には論理的または物理的にすることができる。接続は、とりわけ、ソフトウェアプロセス間のプロセス間通信、またはネットワークコンピューター間のマシン間通信として実装することができる。   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)

  1. ゲートウェイを介してサービスプロバイダーにアクセスするクライアント/ユーザー間の認証委任の方法であって、
    前記クライアント/ユーザーと前記ゲートウェイ間のクライアント認証を有するTLSハンドシェイクを実行するステップであって、前記TLSハンドシェイクは、複数のメッセージ交換を特定するプロトコルによって定義される、ステップと、
    前記クライアント/ユーザーが前記ゲートウェイに認証されたことを証明する認証証拠として、前記TLSハンドシェイクにおいて交換されたメッセージを記録するステップであって、前記TLSハンドシェイクにおいて交換されたメッセージは、証明書検証メッセージまでの、前記プロトコルにおいて特定されたすべてのメッセージを含み、前記証明書検証メッセージは、前記TLSハンドシェイクの以前のすべてのメッセージに対する署名から成る、ステップと、
    前記記録を前記ゲートウェイから前記サービスプロバイダーに提供するステップと、
    前記サービスプロバイダーが、前記クライアント/ユーザーからのアクセスの可否を、前記記録に基づき判定するステップと
    を備えたことを特徴とする方法。
    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 .
  2. 前記サービスプロバイダーは、前記クライアント/ユーザーと前記ゲートウェイ間の認証に関与しないことを特徴とする請求項1に記載の方法。   The method of claim 1, wherein the service provider is not involved in authentication between the client / user and the gateway.
  3. 前記提供するステップは、前記ゲートウェイから前記サービスプロバイダーに記録を直接提供することを特徴とする請求項1に記載の方法。   The method of claim 1, wherein the providing step provides a record directly from the gateway to the service provider.
  4. 時間に関連するデータを前記TLSハンドシェイクのメッセージに組み込むステップをさらに備えることを特徴とする請求項1に記載の方法。   The method of claim 1, further comprising incorporating time-related data into the TLS handshake message.
  5. 前記クライアント/ユーザーは、前記時間に関連するデータを組み込むことを特徴とする請求項4に記載の方法。   The method of claim 4, wherein the client / user incorporates data related to the time.
  6. 前記ゲートウェイは、前記時間に関連するデータを組み込むことを特徴とする請求項4に記載の方法。   The method of claim 4, wherein the gateway incorporates data related to the time.
  7. 前記サービスプロバイダーによって提供されたノンスを、前記TLSハンドシェイクの一部として、前記ゲートウェイから前記クライアント/ユーザーまでのメッセージに組み込むステップをさらに備えることを特徴とする請求項1に記載の方法。   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.
  8. 前記サービスプロバイダーは、受信したすべての記録のメモリを保持する、および同じ記録が2回以上使用されていないことを確認することを特徴とする請求項1に記載の方法。   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.
  9. TLSハンドシェイクを実行する前記ステップは、
    クライアント認証を有しない第1のハンドシェイクを実行するステップと、
    前記第1のハンドシェイクの実行の成功した完了後、クライアント認証を有する第2のハンドシェイクを実行するステップと
    をさらに備えることを特徴とする請求項1に記載の方法。
    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.
  10. 前記クライアント/ユーザーとゲートウェイ間の前記第2のハンドシェイクは、前記第1のハンドシェイクから得たセッション鍵によって暗号化されることを特徴とする請求項9に記載の方法。   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.
  11. 前記サービスプロバイダーに提供された前記記録は、暗号化されないことを特徴とする請求項10に記載の方法。   The method of claim 10, wherein the record provided to the service provider is not encrypted.
  12. 認証委任を使用して、エンドサーバー上のサービスへのアクセスを許可する方法であって、
    前記エンドサーバーが、ユーザーによって要求されたサービスにアクセスするために、要求を受信するステップと、
    前記エンドサーバーが、前記ユーザーとゲートウェイ/中間サーバー間で実行されるクライアント認証を有するTLSハンドシェイクにおいて交換されたメッセージの記録を、前記ユーザーが前記ゲートウェイ/中間サーバーに認証されたことを証明する認証証拠として、前記ゲートウェイ/中間サーバーから受信するステップであって、前記TLSハンドシェイクは、複数のメッセージ交換を特定するプロトコルによって定義され、前記TLSハンドシェイクにおいて交換されたメッセージは、証明書検証メッセージまでの、前記プロトコルにおいて特定されたすべてのメッセージを含み、前記証明書検証メッセージは、前記TLSハンドシェイクの以前のすべてのメッセージに対する署名から成る、ステップと、
    前記エンドサーバーが、前記記録を利用して、前記TLSハンドシェイクを再検証し、前記ユーザーのアイデンティティを確認するステップであって、該ステップは、同じ記録が2回以上使用されていないことを確認するステップを含む、ステップ
    を備えたことを特徴とする方法。
    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 :
  13. ゲートウェイを介してサービスプロバイダーにアクセスするクライアント/ユーザー間の認証委任の方法であって、
    前記クライアント/ユーザーと前記ゲートウェイ間のクライアント認証を有するTLSハンドシェイクを実行するステップであって、前記TLSハンドシェイクは、複数のメッセージ交換を特定するプロトコルによって定義され、該ステップは、クライアント認証を有しない第1のハンドシェイクを実行するステップと、前記第1のハンドシェイクを実行するステップの成功した完了後、クライアント認証を有する第2のハンドシェイクを実行するステップとを含む、ステップと、
    前記クライアント/ユーザーが前記ゲートウェイに認証されたことを証明する認証証拠として、前記第2のハンドシェイクにおいて交換されたメッセージを記録するステップであって、前記第2のハンドシェイクにおいて交換されたメッセージは、証明書検証メッセージまでの、前記プロトコルにおいて特定されたすべてのメッセージを含み、前記証明書検証メッセージは、前記第2のハンドシェイクの以前のすべてのメッセージに対する署名から成る、ステップと、
    前記記録を前記ゲートウェイから第三者エンティティに提供するステップと、
    前記第三者エンティティによる前記記録の有効性の確認後、ユーザー資格を前記第三者エンティティから受信するステップと、
    前記ユーザー資格を用いて、前記ユーザーを前記サービスプロバイダーに対して認証するステップと
    を前記ゲートウェイが実行することを特徴とする方法。
    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.
  14. 前記第三者エンティティは、認証局(Certificate Authority)であることを特徴とする請求項13に記載の方法。   The method of claim 13, wherein the third party entity is a Certificate Authority.
  15. ユーザー資格を受信する前記ステップは、一時的な証明書およびそれに関連する秘密鍵を受信することを備えることを特徴とする請求項14に記載の方法。   The method of claim 14, wherein the step of receiving user credentials comprises receiving a temporary certificate and associated private key.
  16. 前記ユーザーを前記サービスプロバイダーに対して認証する前記ステップは、PKINITを用いたKerberosを使用して実行されることを特徴とする請求項14に記載の方法。   The method of claim 14, wherein the step of authenticating the user to the service provider is performed using Kerberos using PKINIT.
  17. 前記第三者エンティティはKDCであり、ユーザー資格を受信する前記ステップは前記KDCからKerberosのサービスチケットを受信することを備えることを特徴とする請求項13に記載の方法。   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.
  18. 前記第三者エンティティは、単一デバイスのゲートウェイと一緒に常駐することを特徴とする請求項13に記載の方法。   The method of claim 13, wherein the third party entity resides with a single device gateway.
JP2013024845A 2006-12-01 2013-02-12 Authentication delegation based on re-verification of cryptographic evidence Active JP5599910B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/607,720 2006-12-01
US11/607,720 US9055107B2 (en) 2006-12-01 2006-12-01 Authentication delegation based on re-verification of cryptographic evidence

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2009539518 Division 2007-11-30

Publications (2)

Publication Number Publication Date
JP2013138474A JP2013138474A (en) 2013-07-11
JP5599910B2 true JP5599910B2 (en) 2014-10-01

Family

ID=39477460

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2009539518A Active JP5334320B2 (en) 2006-12-01 2007-11-30 Authentication delegation based on re-verification of cryptographic evidence
JP2013024845A Active JP5599910B2 (en) 2006-12-01 2013-02-12 Authentication delegation based on re-verification of cryptographic evidence

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2009539518A Active JP5334320B2 (en) 2006-12-01 2007-11-30 Authentication delegation based on re-verification of cryptographic evidence

Country Status (7)

Country Link
US (1) US9055107B2 (en)
EP (1) EP2098006B1 (en)
JP (2) JP5334320B2 (en)
KR (1) KR101459802B1 (en)
CN (1) CN101542965A (en)
TW (1) TWI429256B (en)
WO (1) WO2008127447A2 (en)

Families Citing this family (123)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343413B2 (en) 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US9055107B2 (en) * 2006-12-01 2015-06-09 Microsoft Technology Licensing, Llc Authentication delegation based on re-verification of cryptographic evidence
US8332923B2 (en) * 2007-01-19 2012-12-11 Toshiba America Research, Inc. Kerberized handover keying
JP2009086802A (en) * 2007-09-28 2009-04-23 Hitachi Ltd Mediation method and system for authentication
US8516566B2 (en) * 2007-10-25 2013-08-20 Apple Inc. Systems and methods for using external authentication service for Kerberos pre-authentication
US8387130B2 (en) * 2007-12-10 2013-02-26 Emc Corporation Authenticated service virtualization
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
US8566444B1 (en) 2008-10-30 2013-10-22 F5 Networks, Inc. Methods and system for simultaneous multiple rules checking
US8555069B2 (en) * 2009-03-06 2013-10-08 Microsoft Corporation Fast-reconnection of negotiable authentication network clients
US8064896B2 (en) * 2009-03-09 2011-11-22 Apple Inc. Push notification service
US10157280B2 (en) 2009-09-23 2018-12-18 F5 Networks, Inc. System and method for identifying security breach attempts of a website
JP5325061B2 (en) * 2009-09-25 2013-10-23 株式会社日立製作所 Key management apparatus and key management method
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US8301895B2 (en) * 2009-12-02 2012-10-30 Microsoft Corporation Identity based network policy enablement
KR101712158B1 (en) * 2009-12-28 2017-03-06 인터디지탈 패튼 홀딩스, 인크 Machine-to-machine gateway architecture
US9544143B2 (en) 2010-03-03 2017-01-10 Duo Security, Inc. System and method of notifying mobile devices to complete transactions
US9532222B2 (en) 2010-03-03 2016-12-27 Duo Security, Inc. System and method of notifying mobile devices to complete transactions after additional agent verification
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) * 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
US8908545B1 (en) 2010-07-08 2014-12-09 F5 Networks, Inc. System and method for handling TCP performance in network access with driver initiated application tunnel
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
US9645992B2 (en) 2010-08-21 2017-05-09 Oracle International Corporation Methods and apparatuses for interaction with web applications and web application data
US8630174B1 (en) 2010-09-14 2014-01-14 F5 Networks, Inc. System and method for post shaping TCP packetization
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US8804504B1 (en) 2010-09-16 2014-08-12 F5 Networks, Inc. System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device
AU2010224455B8 (en) * 2010-09-28 2011-05-26 Mu Hua Investments Limited Biometric key
EP2633667B1 (en) 2010-10-29 2017-09-06 F5 Networks, Inc System and method for on the fly protocol conversion in obtaining policy enforcement information
US8959571B2 (en) 2010-10-29 2015-02-17 F5 Networks, Inc. Automated policy builder
US8627467B2 (en) 2011-01-14 2014-01-07 F5 Networks, Inc. System and method for selectively storing web objects in a cache memory based on policy decisions
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US9021552B2 (en) * 2011-04-05 2015-04-28 Sap Se User authentication for intermediate representational state transfer (REST) client via certificate authority
CN102833067B (en) * 2011-06-15 2017-05-17 中兴通讯股份有限公司 Trilateral authentication method and system and authentication state management method of terminal equipment
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
US9015469B2 (en) 2011-07-28 2015-04-21 Cloudflare, Inc. Supporting secure sessions in a cloud-based proxy service
US9467463B2 (en) 2011-09-02 2016-10-11 Duo Security, Inc. System and method for assessing vulnerability of a mobile device
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9722972B2 (en) * 2012-02-26 2017-08-01 Oracle International Corporation Methods and apparatuses for secure communication
CN104160653B (en) * 2012-03-08 2018-02-23 英特尔公司 For providing method, apparatus, medium and the equipment of multifactor digital security certificate
US9450758B1 (en) * 2012-03-12 2016-09-20 Amazon Technologies, Inc. Virtual requests
US8656471B1 (en) 2012-03-12 2014-02-18 Amazon Technologies, Inc. Virtual requests
US8966570B1 (en) * 2012-03-22 2015-02-24 Amazon Technologies, Inc. Entity to authorize delegation of permissions
WO2013163648A2 (en) 2012-04-27 2013-10-31 F5 Networks, Inc. Methods for optimizing service of content requests and devices thereof
CN103581873A (en) * 2012-07-25 2014-02-12 中国电信股份有限公司 Intelligent card and user identification module safe binding method, system and management platform
US9054863B2 (en) 2012-09-04 2015-06-09 Rockwell Automation Asia Pacific Business Center Pte. Ltd. Industrial protocol system authentication and firewall
KR20140052703A (en) * 2012-10-25 2014-05-07 삼성전자주식회사 Method and apparatus for accelerating web service using a proxy server
US9853964B2 (en) 2012-11-27 2017-12-26 Robojar Pty Ltd System and method for authenticating the legitimacy of a request for a resource by a user
JP5614465B2 (en) * 2013-01-30 2014-10-29 沖電気工業株式会社 Encryption communication device, proxy server, encryption communication device program, and proxy server program
US9418213B1 (en) * 2013-02-06 2016-08-16 Amazon Technologies, Inc. Delegated permissions in a distributed electronic environment
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US8782774B1 (en) 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US10909518B2 (en) * 2013-03-07 2021-02-02 Paypal, Inc. Delegation payment with picture
WO2014145039A1 (en) 2013-03-15 2014-09-18 Oracle International Corporation Intra-computer protected communications between applications
US9344422B2 (en) 2013-03-15 2016-05-17 Oracle International Corporation Method to modify android application life cycle to control its execution in a containerized workspace environment
US9129112B2 (en) 2013-03-15 2015-09-08 Oracle International Corporation Methods, systems and machine-readable media for providing security services
KR20170061664A (en) 2014-09-24 2017-06-05 오라클 인터내셔날 코포레이션 Method to modify android application life cycle to control its execution in a containerized workspace environment
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9367676B2 (en) 2013-03-22 2016-06-14 Nok Nok Labs, Inc. System and method for confirming location using supplemental sensor and/or location data
US9154488B2 (en) * 2013-05-03 2015-10-06 Citrix Systems, Inc. Secured access to resources using a proxy
CN104158791A (en) * 2013-05-14 2014-11-19 北大方正集团有限公司 Safe communication authentication method and system in distributed environment
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
US9049169B1 (en) * 2013-05-30 2015-06-02 Trend Micro Incorporated Mobile email protection for private computer networks
US9305161B1 (en) * 2013-06-24 2016-04-05 Emc Corporation Password hardening system using password shares distributed across multiple servers
US9515996B1 (en) * 2013-06-28 2016-12-06 EMC IP Holding Company LLC Distributed password-based authentication in a public key cryptography authentication system
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US8966267B1 (en) 2014-04-08 2015-02-24 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US9184911B2 (en) * 2014-04-08 2015-11-10 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US8996873B1 (en) 2014-04-08 2015-03-31 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US9762590B2 (en) * 2014-04-17 2017-09-12 Duo Security, Inc. System and method for an integrity focused authentication service
US9413533B1 (en) 2014-05-02 2016-08-09 Nok Nok Labs, Inc. System and method for authorizing a new authenticator
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US9531714B2 (en) * 2014-06-27 2016-12-27 Citrix Systems, Inc. Enterprise authentication via third party authentication support
CN105262605B (en) * 2014-07-17 2018-09-25 阿里巴巴集团控股有限公司 A kind of method, apparatus and system obtaining local information
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US9736154B2 (en) * 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
EP3213488A1 (en) 2014-10-31 2017-09-06 Convida Wireless, LLC End-to-end service layer authentication
CN105577738B (en) * 2014-11-10 2019-08-02 中国移动通信集团公司 A kind of method, apparatus and system of processing terminal information
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
CN104660583B (en) * 2014-12-29 2018-05-29 国家电网公司 A kind of cryptographic services method based on Web cryptographic services
JP2018518854A (en) 2015-03-16 2018-07-12 コンヴィーダ ワイヤレス, エルエルシー End-to-end authentication at the service layer using a public key mechanism
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
EP3304336B1 (en) 2015-06-01 2019-10-09 Duo Security, Inc. Method for enforcing endpoint health standards
US9509684B1 (en) * 2015-10-14 2016-11-29 FullArmor Corporation System and method for resource access with identity impersonation
US9450944B1 (en) 2015-10-14 2016-09-20 FullArmor Corporation System and method for pass-through authentication
US9762563B2 (en) 2015-10-14 2017-09-12 FullArmor Corporation Resource access system and method
CN106656928A (en) * 2015-10-30 2017-05-10 西门子公司 Authentication method between client side and server under cloud environment and authentication device thereof
US9900160B1 (en) 2015-12-03 2018-02-20 Amazon Technologies, Inc. Asymmetric session credentials
US10182044B1 (en) 2015-12-03 2019-01-15 Amazon Technologies, Inc. Personalizing global session identifiers
US10277569B1 (en) * 2015-12-03 2019-04-30 Amazon Technologies, Inc. Cross-region cache of regional sessions
US9894067B1 (en) 2015-12-03 2018-02-13 Amazon Technologies, Inc. Cross-region roles
CN105471896B (en) * 2015-12-28 2019-01-15 深信服科技股份有限公司 Proxy Method, apparatus and system based on SSL
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US9888290B1 (en) * 2016-03-24 2018-02-06 Sprint Communications Company L.P. Service denial notification in secure socket layer (SSL) processing
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10791119B1 (en) 2017-03-14 2020-09-29 F5 Networks, Inc. Methods for temporal password injection and devices thereof
US10356075B2 (en) 2017-03-15 2019-07-16 International Business Machines Corporation Automated verification of chains of credentials
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10931662B1 (en) 2017-04-10 2021-02-23 F5 Networks, Inc. Methods for ephemeral authentication screening and devices thereof
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US10412113B2 (en) 2017-12-08 2019-09-10 Duo Security, Inc. Systems and methods for intelligently configuring computer security
CN109102437A (en) * 2018-08-10 2018-12-28 山东省计算中心(国家超级计算济南中心) A kind of webpage automatic evidence-collecting method and system based on block chain
WO2020176945A1 (en) * 2019-03-05 2020-09-10 Red Piranha Limited Network data traffic identification
CN110708170B (en) * 2019-12-13 2020-03-27 腾讯科技(深圳)有限公司 Data processing method and device and computer readable storage medium
US10903990B1 (en) 2020-03-11 2021-01-26 Cloudflare, Inc. Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
JP3595109B2 (en) 1997-05-28 2004-12-02 日本ユニシス株式会社 Authentication device, terminal device, authentication method in those devices, and storage medium
FI104666B (en) * 1997-11-10 2000-04-14 Nokia Networks Oy Safe handshake protocol
US6128738A (en) 1998-04-22 2000-10-03 International Business Machines Corporation Certificate based security in SNA data flows
US6438550B1 (en) 1998-12-10 2002-08-20 International Business Machines Corporation Method and apparatus for client authentication and application configuration via smart cards
US6367009B1 (en) 1998-12-17 2002-04-02 International Business Machines Corporation Extending SSL to a multi-tier environment using delegation of authentication and authority
US6601171B1 (en) 1999-02-18 2003-07-29 Novell, Inc. Deputization in a distributed computing system
GB9905056D0 (en) 1999-03-05 1999-04-28 Hewlett Packard Co Computing apparatus & methods of operating computer apparatus
US6643774B1 (en) 1999-04-08 2003-11-04 International Business Machines Corporation Authentication method to enable servers using public key authentication to obtain user-delegated tickets
US6584567B1 (en) 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
US6934848B1 (en) 2000-07-19 2005-08-23 International Business Machines Corporation Technique for handling subsequent user identification and password requests within a certificate-based host session
US20030014624A1 (en) * 2000-07-31 2003-01-16 Andes Networks, Inc. Non-proxy internet communication
FI20001837A (en) 2000-08-18 2002-02-19 Nokia Corp authentication.pm:
US7395549B1 (en) 2000-10-17 2008-07-01 Sun Microsystems, Inc. Method and apparatus for providing a key distribution center without storing long-term server secrets
SE0004338L (en) * 2000-11-24 2002-05-25 Columbitech Ab Data network based system
JP2002244557A (en) 2001-02-16 2002-08-30 Atr Adaptive Communications Res Lab Cryptographic communication system and authentication method used therefor
US7698381B2 (en) 2001-06-20 2010-04-13 Microsoft Corporation Methods and systems for controlling the scope of delegation of authentication credentials
JP3842100B2 (en) 2001-10-15 2006-11-08 株式会社日立製作所 Authentication processing method and system in encrypted communication system
JP2003229849A (en) 2002-02-05 2003-08-15 Ntt Docomo Inc Relaying method, repeater, program, and recording medium
US6874089B2 (en) * 2002-02-25 2005-03-29 Network Resonance, Inc. System, method and computer program product for guaranteeing electronic transactions
US7529933B2 (en) * 2002-05-30 2009-05-05 Microsoft Corporation TLS tunneling
GB2405566B (en) 2002-10-14 2005-05-18 Toshiba Res Europ Ltd Methods and systems for flexible delegation
US7644275B2 (en) 2003-04-15 2010-01-05 Microsoft Corporation Pass-thru for client authentication
EP1654852B1 (en) 2003-07-11 2008-04-02 International Business Machines Corporation System and method for authenticating clients in a client-server environment
FI20031258A0 (en) 2003-09-04 2003-09-04 Nokia Corp Location privacy in the communication system
US20050138426A1 (en) * 2003-11-07 2005-06-23 Brian Styslinger Method, system, and apparatus for managing, monitoring, auditing, cataloging, scoring, and improving vulnerability assessment tests, as well as automating retesting efforts and elements of tests
JP4520840B2 (en) 2004-12-02 2010-08-11 株式会社日立製作所 Encrypted communication relay method, gateway server device, encrypted communication program, and encrypted communication program storage medium
KR100687722B1 (en) 2004-12-16 2007-02-27 한국전자통신연구원 Authenticating server and method for user authentication using the same
US8365293B2 (en) 2005-01-25 2013-01-29 Redphone Security, Inc. Securing computer network interactions between entities with authorization assurances
US8959596B2 (en) 2006-06-15 2015-02-17 Microsoft Technology Licensing, Llc One-time password validation in a multi-entity environment
US20080022374A1 (en) * 2006-06-29 2008-01-24 Research In Motion Limited System and method for securely communicating with a server
US8095787B2 (en) * 2006-08-21 2012-01-10 Citrix Systems, Inc. Systems and methods for optimizing SSL handshake processing
US9055107B2 (en) 2006-12-01 2015-06-09 Microsoft Technology Licensing, Llc Authentication delegation based on re-verification of cryptographic evidence

Also Published As

Publication number Publication date
CN101542965A (en) 2009-09-23
KR20090095630A (en) 2009-09-09
TW200833060A (en) 2008-08-01
US9055107B2 (en) 2015-06-09
TWI429256B (en) 2014-03-01
JP2013138474A (en) 2013-07-11
JP5334320B2 (en) 2013-11-06
WO2008127447A3 (en) 2009-03-26
EP2098006B1 (en) 2018-08-01
WO2008127447A2 (en) 2008-10-23
JP2010512069A (en) 2010-04-15
EP2098006A2 (en) 2009-09-09
US20080134311A1 (en) 2008-06-05
EP2098006A4 (en) 2012-07-04
KR101459802B1 (en) 2014-11-07

Similar Documents

Publication Publication Date Title
Niruntasukrat et al. Authorization mechanism for MQTT-based Internet of Things
US9900163B2 (en) Facilitating secure online transactions
US9819666B2 (en) Pass-thru for client authentication
US9148420B2 (en) Single sign-on process
DK2608486T3 (en) Computer-implemented system and method for providing users with secure access to application servers
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
JP5744915B2 (en) Trusted federated identity management and data access authorization method and apparatus
TWI543574B (en) Method for authenticatiing online transactions using a browser
EP2369811B1 (en) System and methods for online authentication
US8214884B2 (en) Computer-based dynamic secure non-cached delivery of security credentials such as digitally signed certificates or keys
Kaeo Designing network security
CN1701295B (en) Method and system for a single-sign-on access to a computer grid
KR100992356B1 (en) Establishing a secure context for communicating messages between computer systems
US7689828B2 (en) System and method for implementing digital signature using one time private keys
EP1763947B1 (en) Authenticating users
US5923756A (en) Method for providing secure remote command execution over an insecure computer network
AU739898B2 (en) Method of and apparatus for providing secure distributed directory services and public key infrastructure
EP1255392B1 (en) Computer network security system employing portable storage device
US8856891B2 (en) Proxy authentication network
US7240362B2 (en) Providing identity-related information and preventing man-in-the-middle attacks
CA2531533C (en) Session-based public key infrastructure
EP1251670B1 (en) Negotiating secure connections through a proxy server
US6985953B1 (en) System and apparatus for storage and transfer of secure data on web
US7032110B1 (en) PKI-based client/server authentication
US8434137B2 (en) Method of securely logging into remote servers

Legal Events

Date Code Title Description
RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20130722

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20130723

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A132

Effective date: 20140120

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140421

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140715

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140813

R150 Certificate of patent or registration of utility model

Ref document number: 5599910

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250