idnits 2.17.1 draft-ietf-kitten-krb-auth-indicator-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC4120]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to directly say this. It does mention RFC4120 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2016) is 2902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Jain 3 Internet-Draft Georgia Tech 4 Updates: 4120 (if approved) N. Kinder 5 Intended status: Standards Track N. McCallum 6 Expires: November 17, 2016 Red Hat, Inc. 7 May 16, 2016 9 Authentication Indicator in Kerberos Tickets 10 draft-ietf-kitten-krb-auth-indicator-01 12 Abstract 14 This document proposes an extension in the Kerberos protocol 15 [RFC4120]. It defines a new Authorization Data Type AD- 16 AUTHENTICATION-INDICATOR. The purpose of introducing this data type 17 is to include an indicator of the strength of a client's 18 authentication in the service tickets so that the application 19 services can use it as an input into policy decisions. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 17, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 2 57 3. AD Type Specification . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 5.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 4 63 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 Kerberos [RFC4120] allows secure interaction among users and services 68 over a network. It supports a variety of authentication mechanisms 69 using its Pre-Authentication framework [RFC6113]. The Kerberos 70 Authentication Service has been architected to support password based 71 authentication as well as multi-factor authentication using One Time 72 Password devices or Public Key Cryptography. Implementations that 73 have Pre-Authentication mechanisms offering significantly different 74 strengths of client authentication may choose to keep track of the 75 strength of the authentication used as an input into policy 76 decisions. 78 This document proposes a new Authorization Data Type to be used to 79 convey the authentication strength to the application services. The 80 KDC can provide the DER encoding of the ASN.1 type defined in this 81 document into the ad-data field of the AD-CAMMAC [RFC7751] container. 82 This ASN.1 type contains information about the type of authentication 83 mechanism used by the Kerberos client to authenticate itself to the 84 KDC. 86 2. Document Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. AD Type Specification 94 The KDC MAY include the following Authorization Data element, wrapped 95 in AD-CAMMAC, in the initial credentials and copy it from a ticket- 96 granting ticket into service tickets: 98 AD-AUTHENTICATION-INDICATOR 97 100 The corresponding ad-data field contains the DER encoding of the 101 ASN.1 type which is defined as 103 AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String 105 Each UTF8String value is a short string that indicates that a 106 particular set of requirements was met during the initial 107 authentication. These strings are intended to be compared against 108 known values. They are not intended to store structured data. These 109 strings MAY be site-defined strings that do not contain a colon such 110 as the name of the Pre-Authentication mechanism used, or 111 alternatively URIs that reference a Level of Assurance Profile 112 [RFC6711]. 114 The AD-AUTHENTICATION-INDICATOR MUST be included in the AD-CAMMAC 115 container so that its contents can be protected. The AD- 116 AUTHENTICATION-INDICATOR MAY safely be ignored by the applications 117 and KDCs that do not implement this element. 119 4. Security Considerations 121 AD-AUTHENTICATION-INDICATOR is wrapped in AD-CAMMAC which supersedes 122 AD-KDC-ISSUED container. AD-CAMMAC allows both the application 123 service and the KDC to verify the authenticity of the contained 124 Authorization Data. 126 A malicious service can replace AD-CAMMAC in a service ticket with a 127 legitimate AD-CAMMAC present in some other ticket that the service 128 has received. The KDC MUST ensure that the service does not tamper 129 with the contents of AD-CAMMAC or the ticket by including a kdc- 130 verifier in the containing CAMMAC. This binding protects AD- 131 AUTHENTICATION-INDICATOR in case of constrained delegation such as 132 S4U2Proxy [MS-SFU] extension. 134 Using multiple strings in AD-AUTHENTICATION-INDICATOR MAY lead to 135 ambiguity when a service tries to make a decision based on the AD- 136 AUTHENTICATION-INDICATOR values. This ambiguity can be avoided if 137 indicator values are always used as a positive indication of certain 138 requirements being met during the initial authentication. 140 5. References 142 5.1. Normative References 144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 145 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 146 RFC2119, March 1997, 147 . 149 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 150 Kerberos Network Authentication Service (V5)", RFC 4120, 151 DOI 10.17487/RFC4120, July 2005, 152 . 154 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 155 Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/ 156 RFC6113, April 2011, 157 . 159 [RFC7751] Sorce, S. and T. Yu, "Kerberos Authorization Data 160 Container Authenticated by Multiple Message Authentication 161 Codes (MACs)", RFC 7751, DOI 10.17487/RFC7751, March 2016, 162 . 164 5.2. Informative References 166 [MS-SFU] Microsoft, "Kerberos Protocol Extensions: Service for User 167 and Constrained Delegation Protocol", January 2013, 168 . 170 [RFC6711] Johansson, L., "An IANA Registry for Level of Assurance 171 (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August 172 2012, . 174 Appendix A. ASN.1 Module 176 KerberosV5AuthenticationIndicators { 177 iso(1) identified-organization(3) dod(6) internet(1) 178 security(5) kerberosV5(2) modules(4) 179 authentication-indicators(9) 180 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 182 AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String 184 END 186 Appendix B. Acknowledgements 188 Dmitri Pal (Red Hat) 189 Simo Sorce (Red Hat) 191 Authors' Addresses 193 Anupam Jain 194 Georgia Tech 195 225 North Ave NW 196 Atlanta, GA 30332 197 USA 199 EMail: ajain323@gatech.edu 201 Nathan Kinder 202 Red Hat, Inc. 203 444 Castro St. 204 Suite 500 205 Mountain View, CA 94041 206 USA 208 EMail: nkinder@redhat.com 210 Nathaniel McCallum 211 Red Hat, Inc. 212 100 East Davie Street 213 Raleigh, NC 27601 214 USA 216 EMail: npmccallum@redhat.com