RFC 8129 - Authentication Indicator in Kerberos Tickets 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8129
タイトル : RFC 8129 - Kerberosチケットの認証インジケーター
翻訳編集 : 自動生成

[要約] RFC 8129は、Kerberosチケットにおける認証指示子の使用方法を定義しています。目的は、チケットの受信者に対して、チケットがどのように認証されたかを示すことです。

Internet Engineering Task Force (IETF)                           A. Jain
Request for Comments: 8129                                  Georgia Tech
Updates: 4120                                                  N. Kinder
Category: Standards Track                                    N. McCallum
ISSN: 2070-1721                                            Red Hat, Inc.
                                                              March 2017

Authentication Indicator in Kerberos Tickets

Kerberosチケットの認証インジケーター

Abstract

概要

This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

このドキュメントは、Kerberosプロトコルの拡張を指定しているため、RFC 4120を更新しています。新しい認証データタイプAD-AUTHENTICATION-INDICATORを定義します。このデータ型を導入する目的は、クライアントの認証の強さのインジケータをサービスチケットに含め、アプリケーションサービスがそれをポリシー決定への入力として使用できるようにすることです。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8129.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8129で入手できます。

著作権表示

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   2
   3.  AD Type Specification . . . . . . . . . . . . . . . . . . . .   2
   4.  Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

Kerberos [RFC4120] allows secure interaction among users and services over a network. It supports a variety of authentication mechanisms using its pre-authentication framework [RFC6113]. The Kerberos authentication service has been architected to support password-based authentication as well as multi-factor authentication using one-time password devices, public-key cryptography, and other pre-authentication schemes. Implementations that offer pre-authentication mechanisms supporting significantly different strengths of client authentication may choose to keep track of the strength of the authentication that was used, for use as an input into policy decisions.

Kerberos [RFC4120]は、ネットワーク上のユーザーとサービス間の安全な対話を可能にします。事前認証フレームワーク[RFC6113]を使用して、さまざまな認証メカニズムをサポートします。 Kerberos認証サービスは、パスワードベースの認証だけでなく、ワンタイムパスワードデバイス、公開鍵暗号、およびその他の事前認証スキームを使用した多要素認証をサポートするように設計されています。大幅に異なるクライアント認証の強度をサポートする事前認証メカニズムを提供する実装は、ポリシー決定への入力として使用するために、使用された認証の強度を追跡することを選択できます。

This document specifies a new authorization data type to convey authentication strength information to application services. Elements of this type appear within an AD-CAMMAC (Authorization Data type Container Authenticated by Multiple Message Authentication Codes) [RFC7751] container.

このドキュメントでは、認証強度情報をアプリケーションサービスに伝達するための新しい承認データタイプを指定します。このタイプの要素は、AD-CAMMAC（複数のメッセージ認証コードによって認証される承認データタイプコンテナー）[RFC7751]コンテナー内に表示されます。

2. Document Conventions

2. 文書規約

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. AD Type Specification

3. ADタイプの仕様

The Key Distribution Center (KDC) MAY include authorization data of ad-type 97, wrapped in AD-CAMMAC, in initial credentials. The KDC MAY copy it from a ticket-granting ticket into service tickets.

キー配布センター（KDC）は、AD-CAMMACでラップされた広告タイプ97の認証データを初期認証情報に含めることができます。 KDCは、チケット認可チケットからサービスチケットにそれをコピーできます（MAY）。

The corresponding ad-data field contains the DER encoding [X.690] of the following ASN.1 [X.680] type:

対応するad-dataフィールドには、次のASN.1 [X.680]タイプのDERエンコード[X.690]が含まれています。

   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String

Each UTF8String value is a short string that indicates that a particular set of requirements was met during the initial authentication. These strings are intended to be compared against known values. They are not intended to store structured data. Each string MUST be either:

各UTF8String値は、初期認証中に特定の要件のセットが満たされたことを示す短い文字列です。これらの文字列は、既知の値と比較するためのものです。構造化されたデータを格納するためのものではありません。各文字列は次のいずれかである必要があります。

o A URI that references a Level of Assurance Profile [RFC6711], or

o 保証レベルプロファイル[RFC6711]を参照するURI、または

o A site-defined string, which MUST NOT contain a colon, whose meaning is determined by the realm administrator.

o コロンを含めてはならないサイト定義の文字列。その意味はレルム管理者によって決定されます。

Authorization data elements of type AD-AUTHENTICATION-INDICATOR MUST be included in an AD-CAMMAC container so that their contents can be verified as originating from the KDC. Elements of type AD-AUTHENTICATION-INDICATOR MAY safely be ignored by applications and KDCs that do not implement this element.

タイプがAD-AUTHENTICATION-INDICATORの許可データ要素は、その内容がKDCから発信されたものとして検証できるように、AD-CAMMACコンテナに含める必要があります。タイプAD-AUTHENTICATION-INDICATORの要素は、この要素を実装しないアプリケーションおよびKDCによって安全に無視される場合があります。

4. Assigned Numbers

4. 割り当てられた番号

RFC 4120 [RFC4120] is updated in the following way:

RFC 4120 [RFC4120]は次のように更新されています。

o The ad-type number 97 is assigned for AD-AUTHENTICATION-INDICATOR, updating the table in Section 7.5.4 of RFC 4120 [RFC4120].

o 広告タイプ番号97はAD-AUTHENTICATION-INDICATORに割り当てられ、RFC 4120 [RFC4120]のセクション7.5.4の表を更新します。

o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR".

o RFC 4120 [RFC4120]のセクション5.2.6の表が更新され、ad-type 97を「AD-AUTHENTICATION-INDICATORのDERエンコーディング」にマッピングするようになりました。

5. Security Considerations

5. セキュリティに関する考慮事項

Elements of type AD-AUTHENTICATION-INDICATOR are wrapped in AD-CAMMAC containers. AD-CAMMAC supersedes AD-KDC-ISSUED and allows both application services and the KDC to verify the authenticity of the contained authorization data.

タイプAD-AUTHENTICATION-INDICATORの要素は、AD-CAMMACコンテナーにラップされます。 AD-CAMMACはAD-KDC-ISSUEDに取って代わり、アプリケーションサービスとKDCの両方が、含まれている承認データの信頼性を検証できるようにします。

KDC implementations MUST use AD-CAMMAC verifiers as described in the security considerations of RFC 7751 [RFC7751] to ensure that AD-AUTHENTICATION-INDICATOR elements are not modified by an attacker. Application servers MUST validate the AD-CAMMAC container before making authorization decisions based on AD-AUTHENTICATION-INDICATOR elements. Application servers MUST NOT make authorization decisions based on AD-AUTHENTICATION-INDICATOR elements that appear outside of AD-CAMMAC containers.

KDCの実装では、RFC 7751 [RFC7751]のセキュリティに関する考慮事項に記載されているとおりにAD-CAMMAC検証を使用して、攻撃者がAD-AUTHENTICATION-INDICATOR要素を変更しないようにする必要があります。アプリケーションサーバーは、AD-AUTHENTICATION-INDICATOR要素に基づいて承認を決定する前に、AD-CAMMACコンテナーを検証する必要があります。アプリケーションサーバーは、AD-CAMMACコンテナの外部に表示されるAD-AUTHENTICATION-INDICATOR要素に基づいて承認を決定してはなりません（MUST NOT）。

Using multiple strings in AD-AUTHENTICATION-INDICATOR may lead to ambiguity when a service tries to make a decision based on the AD-AUTHENTICATION-INDICATOR values. This ambiguity can be avoided if indicator values are always used as a positive indication of certain requirements being met during the initial authentication. For example, if a "without-password" indicator is inserted whenever authentication occurs without a password, a service might assume this is an indication that a higher-strength client authentication occurred. However, this indicator might also be inserted when no authentication occurred at all (such as anonymous PKINIT).

AD-AUTHENTICATION-INDICATORで複数の文字列を使用すると、サービスがAD-AUTHENTICATION-INDICATORの値に基づいて決定を行おうとしたときに、あいまいになる可能性があります。最初の認証中に特定の要件が満たされていることを示す明確な指標として常にインジケーター値が使用されている場合は、このあいまいさを回避できます。たとえば、パスワードなしで認証が行われるたびに「パスワードなし」インジケータが挿入された場合、サービスはこれがより強力なクライアント認証が行われたことを示していると想定する場合があります。ただし、認証がまったく行われなかった場合（匿名PKINITなど）にも、この標識が挿入されることがあります。

Application service evaluation of site-defined indicators MUST consider the realm of original authentication in order to avoid cross-realm indicator collisions. Failure to enforce this property can result in invalid authorization decisions.

サイト定義のインジケーターのアプリケーションサービス評価では、レルム間のインジケーターの競合を回避するために、元の認証のレルムを考慮する必要があります。このプロパティを適用しないと、承認の決定が無効になる可能性があります。

6. IANA Considerations

6. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.

[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、DOI 10.17487 / RFC4120、2005年7月、<http：// www.rfc-editor.org/info/rfc4120>。

[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/RFC6113, April 2011, <http://www.rfc-editor.org/info/rfc6113>.

[RFC6113] Hartman、S。およびL. Zhu、「A Kerberos Pre-Authenticationの一般化されたフレームワーク」、RFC 6113、DOI 10.17487 / RFC6113、2011年4月、<http://www.rfc-editor.org/info/rfc6113 >。

[RFC7751] Sorce, S. and T. Yu, "Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)", RFC 7751, DOI 10.17487/RFC7751, March 2016, <http://www.rfc-editor.org/info/rfc7751>.

[RFC7751] Sorce、S。およびT. Yu、「複数のメッセージ認証コード（MAC）によって認証されるKerberos認証データコンテナ」、RFC 7751、DOI 10.17487 / RFC7751、2016年3月、<http：//www.rfc-editor。 org / info / rfc7751>。

[X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC International Standard 8824-1:2008, November 2008.

[X.680] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、ISO / IEC国際規格8824-1：2008、11月2008。

[X.690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC International Standard 8825-1:2008, November 2008.

[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X。 690、ISO / IEC国際規格8825-1：2008、2008年11月。

7.2. Informative References

7.2. 参考引用

[RFC6711] Johansson, L., "An IANA Registry for Level of Assurance (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August 2012, <http://www.rfc-editor.org/info/rfc6711>.

[RFC6711]ヨハンソン、L。、「保証レベル（LoA）プロファイルのIANAレジストリ」、RFC 6711、DOI 10.17487 / RFC6711、2012年8月、<http://www.rfc-editor.org/info/rfc6711> 。

Appendix A. ASN.1 Module

付録A. ASN.1モジュール

   KerberosV5AuthenticationIndicators {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4)
           authentication-indicators(9)
   } DEFINITIONS EXPLICIT TAGS ::= BEGIN

   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String

END

終わり

Acknowledgements

謝辞

Dmitri Pal (Red Hat) Simo Sorce (Red Hat) Greg Hudson (MIT)

Dmitri Pal（Redhat）Simo Sorce（Redhat）Greg Hudson（MIT）

Authors' Addresses

著者のアドレス

Anupam Jain Georgia Tech 225 North Ave NW Atlanta, GA 30332 United States of America

Anupam Jain Georgia Tech 225 North Ave NW Atlanta、GA 30332アメリカ合衆国

   Email: ajain323@gatech.edu

Nathan Kinder Red Hat, Inc. 444 Castro St. Suite 500 Mountain View, CA 94041 United States of America

Nathan Kinder Red Hat、Inc. 444 Castro St. Suite 500 Mountain View、CA 94041アメリカ合衆国

   Email: nkinder@redhat.com

Nathaniel McCallum Red Hat, Inc. 100 East Davie Street Raleigh, NC 27601 United States of America

Nathaniel McCallum Red Hat、Inc. 100 East Davie Street Raleigh、NC 27601アメリカ合衆国

   Email: npmccallum@redhat.com