idnits 2.17.1 draft-jain-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2014) is 3522 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) == Unused Reference: 'RFC4120' is defined on line 148, but no explicit reference was found in the text == Unused Reference: 'RFC4121' is defined on line 161, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-krb-wg-cammac-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 Intended status: Standards Track N. Kinder 5 Expires: March 1, 2015 N. McCallum 6 Red Hat, Inc. 7 August 28, 2014 9 Authentication Indicator in Kerberos tickets 10 draft-jain-kitten-krb-auth-indicator-01 12 Abstract 14 This document proposes an extension in the Kerberos protocol. It 15 defines a new Authorization Data Type AUTHENTICATION-INDICATOR. The 16 purpose of introducing this data type is to include an indicator of 17 the client's authentication strength in the service tickets so that 18 the application services can use it as an input into policy 19 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 March 1, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . 2 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 3 61 5.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 Kerberos allows secure interaction among users and services over a 67 network. It supports a variety of authentication mechanisms using 68 its Pre-Authentication framework [RFC6113]. Kerberos Authentication 69 Service has been architected to support password based authentication 70 as well as multi-factor authentication using One Time Password 71 devices or Public Key Cryptography. Implementations that have Pre- 72 Authentication mechanisms offering significantly different strengths 73 of client authentication may choose to keep track of the strength of 74 the authentication used as an input into policy decisions. This 75 document proposes a new Authorization Data Type to be used to convey 76 the authentication strength to the application services. The AD type 77 is wrapped in the AD-CAMMAC [I-D.ietf-krb-wg-cammac] container and 78 contains information about the type of authentication mechanism used 79 by the Kerberos client to authenticate itself to the KDC. 81 2. Document Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 3. AD Type Specification 89 The KDC MAY include the following Authorization Data element, wrapped 90 in AD-CAMMAC, in the initial credentials and copy it from a ticket- 91 granting ticket into service tickets: 93 AUTHENTICATION-INDICATOR TBD 95 The corresponding ad-data field contains the DER encoding of this AD 96 type which is defined as 97 AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String 99 These values are short strings that indicate that a particular set of 100 requirements was met during the initial authentication. These 101 strings are intended to be compared against known values. They are 102 not intended to store structured data. These strings MAY be site- 103 defined strings that do not contain a colon such as the name of the 104 Pre-Authentication mechanism used, or alternatively URIs that 105 reference a Level of Assurance Profile [RFC6711]. 107 The AUTHENTICATION-INDICATOR AD type MUST be included in the AD- 108 CAMMAC container so that its contents can be protected. The AD- 109 CAMMAC element and the new AD type it encapsulates MAY safely be 110 ignored by the applications and KDCs that do not implement this 111 element. 113 4. Security Considerations 115 AUTHENTICATION-INDICATOR is wrapped in AD-CAMMAC which supersedes AD- 116 KDC-ISSUED container. AD-CAMMAC allows both the application service 117 and the KDC to verify the authenticity of the contained Authorization 118 Data. 120 A malicious service can replace AD-CAMMAC in a service ticket with a 121 legitimate AD-CAMMAC present in some other ticket that the service 122 has received. KDC MUST ensure that the service does not tamper with 123 the contents of AD-CAMMAC or the ticket. It SHOULD insert an 124 Authorization Data element into the AD-CAMMAC container that binds 125 the contents of the container to the enclosing ticket. This binding 126 protects AUTHENTICATION-INDICATOR in case of constrained delegation 127 such as S4U2Proxy [MS-SFU] extension. 129 Using multiple strings in AUTHENTICATION-INDICATOR MAY lead to 130 ambiguity when a service tries to make a decision based on the 131 AUTHENTICATION-INDICATOR values. This ambiguity can be avoided if 132 indicator values are always used as a positive indication of certain 133 requirements being met during the initial authentication. 135 5. References 137 5.1. Normative References 139 [I-D.ietf-krb-wg-cammac] 140 Sorce, S., Yu, T., and T. Hardjono, "Kerberos 141 Authorization Data Container Authenticated by Multiple 142 MACs", draft-ietf-krb-wg-cammac-08 (work in progress), 143 June 2014. 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 149 Kerberos Network Authentication Service (V5)", RFC 4120, 150 July 2005. 152 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 153 Kerberos Pre-Authentication", RFC 6113, April 2011. 155 5.2. Informative References 157 [MS-SFU] Microsoft, "Kerberos Protocol Extensions: Service for User 158 and Constrained Delegation Protocol", January 2013, 159 . 161 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 162 Version 5 Generic Security Service Application Program 163 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 164 2005. 166 [RFC6711] Johansson, L., "An IANA Registry for Level of Assurance 167 (LoA) Profiles", RFC 6711, August 2012. 169 Appendix A. Acknowledgements 171 Dmitri Pal (Red Hat) 172 Simo Sorce (Red Hat) 174 Authors' Addresses 176 Anupam Jain 177 Georgia Tech 178 225 North Ave NW 179 Atlanta, GA 30332 180 USA 182 EMail: ajain323@gatech.edu 184 Nathan Kinder 185 Red Hat, Inc. 186 444 Castro St. 187 Suite 500 188 Mountain View, CA 94041 189 USA 191 EMail: nkinder@redhat.com 193 Nathaniel McCallum 194 Red Hat, Inc. 195 100 East Davie Street 196 Raleigh, NC 27601 197 USA 199 EMail: npmccallum@redhat.com