[要約] RFC 6042は、KeyNoteを使用したTransport Layer Security（TLS）の認証に関する規格です。このRFCの目的は、TLSセッションの認証を強化し、セキュリティを向上させることです。
Independent Submission A. Keromytis
Request for Comments: 6042 Columbia University
Category: Informational October 2010
ISSN: 2070-1721
Transport Layer Security (TLS) Authorization Using KeyNote
基調講演を使用した輸送層のセキュリティ（TLS）承認
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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]交換内の基調講演[基調講演]資格的アサーションを交換するために必要な識別子について説明します。このような資格的アサーションは、クライアントおよび/またはサーバーに特定のアクションを実行することを許可できます。ほとんどの使用シナリオでは、基調講演の資格的アサーションは暗号化の公開鍵[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".
ほとんどのシナリオでは、これらの資格情報の少なくとも1つが資格情報の送信機の公開鍵に発行されます。つまり、少なくとも1つの基調講演の認定アサーションの「ライセンシー」フィールドに公開鍵が表示されると述べています。同じ公開キーは、通常、同じ資格情報の送信機によって使用され、TLS Exchangeの一部として認証されます。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 [基調講演]のプロファイルに準拠する基調講演の認定アサーションのリストです。
A KeyNote assertion list is transmitted inside an AuthorizationDataEntry structure as an opaque sequence of 1 - 2^16-1 bytes:
基調講演リストは、1-2^16-1バイトの不透明なシーケンスとして、AuthorizationDataEntry構造内で送信されます。
opaque 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 [基調講演]に記載されているように、フィールドには署名された基調講演のAscii-Encodedリストが含まれています。アサーションは、2つの「\ n」（newline）文字によって区切られています。基調講演は、公開鍵証明書に似た構造です。主な違いは、名前と公開鍵の間の拘束力の代わりに、基調講演のアサーションは、送信者が後で特定の要求を発行したときにピアによって評価される許可ルールにパブリックキーを拘束することです。
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は、urlandhash構造[authz]として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を避けることは、円形の依存関係を回避する1つの方法です。したがって、HTTP [アップグレード]のアップグレードメカニズムが使用されている場合、HTTPスキームを使用するクライアントはこれらのTLS拡張機能を使用してはなりません。他のスキームについては、これらの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].
このドキュメントを使用して、IANAはTLS認証データフォーマットレジストリ（keynote_assertion_list（64）とkeynote_assertion_list_url（65）に2つの新しいエントリを登録しました。このレジストリは[authz]で定義されています。
There are no security considerations beyond those discussed in [KEYNOTE], [RFC2792], and [AUTHZ].
[基調講演]、[RFC2792]、および[authz]で議論されているものを超えて、セキュリティ上の考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Dierks、T。およびC. Allen、「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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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. Lawrence、「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.
[基調講演] Blaze、M.、Feigenbaum、J.、Ioannidis、J。、およびA. Keromytis、「The Keynote Trust-Management Systemバージョン2」、RFC 2704、1999年9月。
[AUTHZ] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010.
[Authz] Brown、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] Blaze、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 KeyNote Trust Management Systemのキーおよび署名エンコード」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
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>;
opaque SAMLAssertion<1..2^16-1>;
opaque 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];
不透明なsha384hash [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
アンジェロスD.ケロミティコンピュータサイエンス科学部コロンビア大学メールコード0401 1214アムステルダムアベニューニューヨーク、ニューヨーク10027 USA
EMail: angelos@cs.columbia.edu