TLSチャンネルID 翻訳 - 1. introduction

TLSチャンネルIDは、GoogleのWebブラウザ ”Chrome”で実装され、テストされている技術で、Cookie を特定のチャンネル ID と暗号で結び付けることで、セッションが乗っ取られるリスクを低減するものです。 昨年 (2013)、idconというOAuth、OpenIDなどの技術を扱う勉強会で言及されていて、興味を持っていたのですが、今回そのIETFドラフトの翻訳にチャレンジしてみることにしました。

今回は翻訳シリーズの第1回ということで、「1. Introduction」までの翻訳結果を投稿します。

1.イントロダクション

  1. Introduction Many applications on the Internet use bearer tokens to authenticate clients to servers. The most prominent example is the HTTP-based World Wide Web, which overwhelmingly uses HTTP cookies to authenticate client requests. Other examples include OpenID or SAML assertions, and OAuth tokens. All these have in common that the bearer of the HTTP cookie or authentication token is granted access to a protected resource, regardless of the channel over which the token is presented, or who presented it.

インターネット上のたくさんのアプリケーションは、サーバーに対してクライアントを認証するために、[bearer token]を利用している。最もよく知られた例はHTTPベースのWorld Wide Webであり、クライントのリクエストを認証するために、圧倒的な割合でHTTP Cookieが用いられている。他の例としては、OpenIDやSAMLのアサーション、OAuthのトークンがある。これらはすべて共通して、トークンが発行される際のチャンネルやトークンの発行相手に関係なく保護リソースへのアクセスが許可される、HTTP Cookieや認証トークン 〜 bearerである。

As a result, an adversary that manages to steal a bearer token from a client can impersonate that client to services that require the token.

結果として、クライアントからbearer tokenを盗んだ攻撃者は、トークンを要求するサーバーに対して、そのクライアントになりすますことができる。

This document describes a light-weight mechanism for establishing a cryptographic channel between client and server. A server can choose to bind authentication tokens to this channel, thus rendering the theft of authentication tokens fruitless - tokens must be sent over the channel to which they are bound (i.e., by the client to which they were issued) or else they will be ignored.

本ドキュメントは、クライアントとサービス間で暗号化されたチャンネルを確立するための、軽量な方法について述べる。サーバーはこのチャンネルにバインドする認証トークンを選択することができ、従って、盗みとられた認証トークンを無効なものとして扱う事ができる。ー トークンはバインドされたチャンネル上で送付されなければならず（i.e., トークンの発行先のクライアントから）、そうでなければ無視される。

This document does not prescribe how authentication tokens are bound to the underlying channel. Rather, it prescribes how a client can establish a long-lived channel with a server. Such a channel persists across HTTP requests, TLS connections, and even multiple TLS sessions, as long as the same client communicates with the same server.

本ドキュメントは、認証トークンがチャンネルにバインドされる際の手段については規定しない。むしろ、どのようにして、クライアントとサーバーが長期間有効なチャンネルを確立することを可能にするのかを規定する。このチャンネルは、同じクライアントとサーバーが交信している限り、HTTPリクエスト、TLSコネクション、複数のTLSセッションをまたがって持続する。

The basic idea is that the client proves, during the TLS handshake, possession of a private key. The corresponding public key becomes the "Channel ID" that identifies this TLS connection. Clients should re-use the same private/public key pair across subsequent TLS connections to the same server, thus creating TLS connections that share the same Channel ID.

基本的な考え方は、クライアントが、TLSハンドシェイクの間秘密鍵を保持することを保証することである。これに対応する公開鍵が、TLSコネクションを識別する"Channel ID"となる。クライントは、同じ鍵ペアを、同じサーバーに対する後続のTLSコネクションで再利用すべきであり、これによって、同じChannel IDを共有するTLSコネクションを作ることができる。

Using private/public key pairs to define a channel (as opposed to, say, an HTTP session cookie) has several advantages: One, the credential establishing the channel (the private key) is never sent from client to server, thus removing it from the reach of eavesdroppers in the network. Two, clients can choose to implement cryptographic operations in a secure hardware module, which further removes the private key from the reach of eavesdroppers residing on the client itself.

チャンネルを規定するために鍵ペアを用いるのには、（例えはHTTPセッションクッキーを用いるのに対して、）いくつかの利点がある。第一に、チャンネルを確立しているクレデンシャル（秘密鍵）が、決してクライアントからサーバーに送信されないので、ネットワーク上の盗聴者の手の届く範囲から取り除くことができる。第二に、クライアントが、暗号関連の操作の実装方法としてハードウエアセキュリティモジュールを選択することができるので、秘密鍵を、クライアント上の盗聴者の手の届く範囲からさえ取り除くことができる。

「1. Introduction」までの翻訳結果は以上です。