summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8129.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8129.txt')
-rw-r--r--doc/rfc/rfc8129.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc8129.txt b/doc/rfc/rfc8129.txt
new file mode 100644
index 0000000..83faf89
--- /dev/null
+++ b/doc/rfc/rfc8129.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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
+
+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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ 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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+Jain, et al. Standards Track [Page 1]
+
+RFC 8129 Authentication Indicator March 2017
+
+
+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
+
+ 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.
+
+ 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.
+
+2. Document Conventions
+
+ 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].
+
+3. AD Type Specification
+
+ 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.
+
+
+
+
+
+Jain, et al. Standards Track [Page 2]
+
+RFC 8129 Authentication Indicator March 2017
+
+
+ The corresponding ad-data field contains the DER encoding [X.690] of
+ the following ASN.1 [X.680] type:
+
+ 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:
+
+ o A URI that references a Level of Assurance Profile [RFC6711], or
+
+ o A site-defined string, which MUST NOT contain a colon, whose
+ meaning is determined by the realm administrator.
+
+ 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.
+
+4. Assigned Numbers
+
+ RFC 4120 [RFC4120] is updated in the following way:
+
+ 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 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".
+
+5. Security Considerations
+
+ 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.
+
+ 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.
+
+
+
+
+Jain, et al. Standards Track [Page 3]
+
+RFC 8129 Authentication Indicator March 2017
+
+
+ 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).
+
+ 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
+
+ This document does not require any IANA actions.
+
+7. References
+
+7.1. Normative References
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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.
+
+
+
+Jain, et al. Standards Track [Page 4]
+
+RFC 8129 Authentication Indicator March 2017
+
+
+ [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.
+
+7.2. Informative References
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jain, et al. Standards Track [Page 5]
+
+RFC 8129 Authentication Indicator March 2017
+
+
+Appendix A. ASN.1 Module
+
+ 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)
+
+Authors' Addresses
+
+ Anupam Jain
+ Georgia Tech
+ 225 North Ave NW
+ Atlanta, GA 30332
+ United States of America
+
+ Email: ajain323@gatech.edu
+
+
+ Nathan Kinder
+ Red Hat, Inc.
+ 444 Castro St.
+ Suite 500
+ Mountain View, CA 94041
+ United States of America
+
+ Email: nkinder@redhat.com
+
+
+ Nathaniel McCallum
+ Red Hat, Inc.
+ 100 East Davie Street
+ Raleigh, NC 27601
+ United States of America
+
+ Email: npmccallum@redhat.com
+
+
+
+
+
+Jain, et al. Standards Track [Page 6]
+