Independent Submission A. Keromytis
Request for Comments: 6042 Columbia University
Category: Informational October 2010
ISSN: 2070-1721
Transport Layer Security (TLS) Authorization Using KeyNote
Abstract
抽象
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message.
この文書では、メッセージは、両方の当事者が希望をサポートしていることを確認ハローRFC 5878.クライアントに運ば拡張し、サーバのガイドラインに従って、トランスポート層セキュリティ（TLS）ハンドシェイクプロトコルでの認証の拡張機能として、基調信託管理システムの使用を指定します認証データの種類。クライアントとサーバーの両方でサポートされている場合その後、基調資格情報は、補足データのハンドシェイクメッセージで交換されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6042.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6042で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document describes the identifiers necessary to exchange KeyNote [KEYNOTE] credential assertions inside a TLS [TLS1.0] [TLS1.1] [TLS1.2] exchange. Such credential assertions can authorize the client and/or the server to perform certain actions. In most usage scenarios, the KeyNote credential assertions will be signed by a cryptographic public key [RFC2792]. By using the X.509 key and signature encoding [X509KEY], it is possible to add KeyNote-based authorization and policy compliance support to the existing, unmodified X.509 authentication exchange in TLS.
この文書では、TLS [TLS1.0] [TLS1.1] [TLS1.2]交換内部基調[KEYNOTE]資格アサーションを交換するために必要な識別子を記述する。このような資格アサーションは特定のアクションを実行するには、クライアントおよび/またはサーバーを承認することができます。ほとんどの使用シナリオでは、基調資格アサーションは、暗号公開鍵[RFC2792]によって署名されます。 X.509鍵と署名エンコーディング[X509KEY]を用いることにより、TLSの既存の、修飾されていないX.509認証交換を基調ベースの認証およびポリシーコンプライアンスサポートを追加することが可能です。
A list of KeyNote credentials (e.g., forming a delegation chain) may be sent as part of the same payload. Alternatively, a URL [RFC3986] pointing to the location of such a list of KeyNote credentials may be provided.
基調クレデンシャル（例えば、委任チェーンを形成する）のリストは、同じペイロードの一部として送信されてもよいです。あるいは基調資格情報のそのようなリストの場所を指し示すURL [RFC3986]は設けられていてもよいです。
In most scenarios, at least one of these credentials will be issued to the public key of the transmitter of the credentials, i.e., said public key will appear in the "Licensees" field of at least one KeyNote credential assertion. The same public key will generally be used by the transmitter of the same credentials to authenticate as part of the TLS exchange. The authentication material (e.g., cryptographic public key) that was used by the transmitter to authenticate in the TLS exchange will be provided to the KeyNote evaluation engine as an "Action Authorizer".
ほとんどのシナリオでは、これらの資格情報のうち少なくとも一つは、資格情報の送信者の公開鍵に発行される、すなわち、公開鍵は、少なくとも一つの基調資格表明の「ライセンシー」フィールドに表示されますと述べました。同じ公開鍵は、一般的にTLS交換の一環として認証するために同じ資格情報の送信機によって使用されます。 TLS交換で認証するために送信機によって使用された認証用材料（例えば、暗号公開鍵）は、「アクション・オーソライザ」として基調評価エンジンに提供されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The KeyNote Assertion List type definition in the TLS Authorization Data Formats registry is:
TLS認証データ形式レジストリの基調アサーション一覧タイプ定義は次のとおりです。
keynote_assertion_list(64)
keynote_assertion_list（64）
When the keynote_assertion_list value is present, the authorization data is a list of KeyNote credential assertions that conforms to the profile in RFC 2704 [KEYNOTE].
keynote_assertion_list値が存在する場合、許可データは、RFC 2704で、プロファイルに準拠基調資格アサーション[KEYNOTE]のリストです。
A KeyNote assertion list is transmitted inside an AuthorizationDataEntry structure as an opaque sequence of 1 - 2^16-1 bytes:
基調アサーションリストが1つの不透明なシーケンスとしてAuthorizationDataEntry構造の内部に伝達され、 - 2 ^ 16-1バイト。
opaque KeyNoteAssertionList<1..2^16-1>;
不透明KeyNoteAssertionList <1..2 ^ 16-1>;
When KeyNoteAssertionList is used, the field contains an ASCII-encoded list of signed KeyNote assertions, as described in RFC 2704 [KEYNOTE]. The assertions are separated by two "\n" (newline) characters. A KeyNote assertion is a structure similar to a public key certificate; the main difference is that instead of a binding between a name and a public key, KeyNote assertions bind public keys to authorization rules that are evaluated by the peer when the sender later issues specific requests.
KeyNoteAssertionListを使用した場合、フィールドは、RFC 2704に記載されるように署名された基調アサーション、[KEYNOTE]のASCII符号化されたリストを含みます。アサーションは、二つの「\ n」は（改行）文字で区切られます。基調アサーションは、公開鍵証明書と同様の構造です。主な違いは、代わりに、名前と公開鍵の間の結合の、基調アサーションは、ピア送信者、後で問題の特定の要求によって評価されている承認規則に公開鍵を結合することです。
When making an authorization decision based on a list of KeyNote assertions, proper linkage between the KeyNote assertions and the public key certificate that is transferred in the TLS Certificate message is needed. Receivers of a KeyNote assertion list should initialize the ACTION_AUTHORIZER variable to be the sender's public key, which was used to authenticate the TLS exchange. If a different authentication mechanism is used, it is the responsibility of the credential issuer to issue the appropriate credentials.
基調表明のリストに基づいて承認決定をするときは、TLS証明書メッセージに転送され、基調表明し、公開鍵証明書の間の適切な連携が必要とされています。基調アサーションリストのレシーバは、TLS交換を認証するために使用された送信者の公開鍵であるとACTION_AUTHORIZER変数を初期化する必要があります。異なる認証メカニズムを使用する場合、それは適切な資格を発行する資格発行者の責任です。
The KeyNote Assertion List URL type definition in the TLS Authorization Data Formats registry is:
TLS認証データ形式レジストリの基調アサーション一覧URLのタイプ定義は次のとおりです。
keynote_assertion_list_url(65)
keynote_assertion_list_url（65）
A KeyNote Assertion List URL is transmitted inside an AuthorizationDataEntry structure as a URLandHash structure [AUTHZ].
基調アサーションリストURLは、[のauthz] URLandHash構造としてAuthorizationDataEntry構造の内部に伝達されます。
When the keynote_assertion_list_url value is present, the authorization data is a list of KeyNote assertions as described in Section 2; however, the KeyNote assertion list is fetched with the supplied URL. A one-way hash value is provided to ensure that the intended KeyNote credential assertion is obtained.
keynote_assertion_list_url値が存在する場合、セクション2で説明したように、認証データは、基調アサーションのリストです。しかし、基調アサーションリストが提供されたURLで取得されます。一方向ハッシュ値を意図基調資格アサーションが得られることを確実にするために設けられています。
Implementations that support keynote_assertion_list_url MUST support URLs that employ the HTTP scheme [HTTP]. These implementations MUST confirm that the hash value computed on the fetched authorization matches the one received in the handshake. Mismatch of the hash values SHOULD be treated as though the authorization was not provided, which will result in a bad_certificate alert [AUTHZ].
keynote_assertion_list_urlをサポートする実装は、HTTPスキーム[HTTP]を採用したURLをサポートしなければなりません。これらの実装は、フェッチされた許可に計算されたハッシュ値は、ハンドシェークで受信したものと一致することを確認しなければなりません。ハッシュ値の不一致がbad_certificateアラート【のauthz]をもたらすであろう、許可が提供されなかったかのように扱われるべきです。
Other schemes may also be supported. When dereferencing these URLs, circular dependencies MUST be avoided. Avoiding TLS when dereferencing these URLs is one way to avoid circular dependencies. Therefore, clients using the HTTP scheme MUST NOT use these TLS extensions if the Upgrade mechanism in HTTP [UPGRADE] is used. For other schemes, similar care must be taken to avoid using these TLS extensions.
他の方式もサポートすることができます。これらのURLを参照解除すると、循環依存は避けなければなりません。これらのURLを参照解除するときTLSを回避することは、循環依存を回避するための一つの方法です。そのため、HTTP [UPGRADE]でアップグレードメカニズムが使用されている場合は、これらのTLS拡張を使用してはならないHTTPスキームを使用しているクライアント。他の方式の場合は、同様の注意がこれらのTLS拡張を使用しないように注意する必要があります。
With this document, IANA has registered two new entries in the TLS Authorization Data Formats registry: keynote_assertion_list(64) and keynote_assertion_list_url(65). This registry is defined in [AUTHZ].
keynote_assertion_list（64）とkeynote_assertion_list_url（65）：この文書では、IANAは、TLS認証データ形式レジストリ内の2つの新規エントリを登録しています。このレジストリは、[のauthz]で定義されています。
There are no security considerations beyond those discussed in [KEYNOTE], [RFC2792], and [AUTHZ].
そこ[KEYNOTE]で論じたもの、[RFC2792]を超えていないセキュリティ上の考慮事項はありませんし、[のauthz]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS1.0]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS1.1]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS1.2]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[アップグレード] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999.
【KEYNOTE]ブレイズ、M.、ファイゲンバウム、J.、Ioannidis、J.、およびA. Keromytis、 "基調信託管理システムバージョン2"、RFC 2704、1999年9月。
[AUTHZ] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010.
[のauthz]ブラウン、M.とR. Housley氏、 "トランスポート層セキュリティ（TLS）認証の拡張"、RFC 5878、2010年5月。
[RFC2792] Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System", RFC 2792, March 2000.
[RFC2792]ブレイズ、M.、Ioannidis、J.、およびA. Keromytis、 "基調トラスト・マネジメント・システムのためのDSAおよびRSA鍵と署名エンコーディング"、RFC 2792、2000年3月。
[X509KEY] Keromytis, A., "X.509 Key and Signature Encoding for the KeyNote Trust Management System", RFC 5708, January 2010.
[X509KEY] Keromytis、A.、 "基調トラスト・マネジメント・システムのためのX.509の鍵と署名エンコーディング"、RFC 5708、2010年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
Appendix A. Updated TLS Authorization Data Structures
付録A.更新TLS認証データ構造
For clarity, this Appendix shows an updated version of the relevant data structures from Section 3.3 in [AUTHZ] with the new entries described in this document. The added elements are denoted with two asterisks ("**") at the end of the respective lines.
明確にするために、この付録は、この文書で説明する新しいエントリで[のauthz]でセクション3.3から関連するデータ構造の更新バージョンを示しています。添加元素は、各ラインの終わりに2つのアスタリスク（「**」）で示されています。
struct {
AuthorizationDataEntry authz_data_list<1..2^16-1>;
} AuthorizationData;
struct {
AuthzDataFormat authz_format;
select (AuthzDataFormat) {
case x509_attr_cert: X509AttrCert;
case saml_assertion: SAMLAssertion;
case x509_attr_cert_url: URLandHash;
case saml_assertion_url: URLandHash;
case keynote_assertion_list: KeyNoteAssertionList; **
case keynote_assertion_list_url: URLandHash; **
}
} AuthorizationDataEntry;
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3),
keynote_assertion_list(64), keynote_assertion_list_url(65), **
(255)
} AuthzDataFormat;
opaque X509AttrCert<1..2^16-1>;
不透明X509AttrCert <1..2 ^ 16-1>;
opaque SAMLAssertion<1..2^16-1>;
不透明なSAMLAssertion <1..2 ^ 16-1>;
opaque KeyNoteAssertionList<1..2^16-1>; **
不透明KeyNoteAssertionList <1..2 ^ 16-1>; **
struct {
opaque url<1..2^16-1>;
HashAlgorithm hash_alg;
select (hash_alg) {
case md5: MD5Hash;
case sha1: SHA1Hash;
case sha224: SHA224Hash;
case sha256: SHA256Hash;
case sha384: SHA384Hash;
case sha512: SHA512Hash;
} hash;
} URLandHash;
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
opaque MD5Hash[16];
不透明MD5Hash [16]。
opaque SHA1Hash[20];
不透明SHA1Hash [20]。
opaque SHA224Hash[28];
不透明SHA224Hash [28]。
opaque SHA256Hash[32];
不透明SHA256Hash [32]。
opaque SHA384Hash[48];
不透明SHA384ハッシュ[48]。
opaque SHA512Hash[64];
不透明SHA512Hash [64]。
Author's Address
著者のアドレス
Angelos D. Keromytis Department of Computer Science Columbia University Mail Code 0401 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学メールコード0401 1214アムステルダムアベニュー、ニューヨーク、NY 10027 USAのアンゲロス・D. Keromytis部門
EMail: angelos@cs.columbia.edu
メールアドレス：angelos@cs.columbia.edu