idnits 2.17.1 draft-ietf-krb-wg-cammac-11.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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 3, 2014) is 3493 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) -- Looks like a reference, but probably isn't: '0' on line 172 -- Looks like a reference, but probably isn't: '1' on line 173 -- Looks like a reference, but probably isn't: '2' on line 174 -- Looks like a reference, but probably isn't: '3' on line 175 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Sorce, Ed. 3 Internet-Draft Red Hat 4 Updates: 4120 (if approved) T. Yu, Ed. 5 Intended status: Standards Track T. Hardjono, Ed. 6 Expires: April 6, 2015 MIT Kerberos Consortium 7 October 3, 2014 9 Kerberos Authorization Data Container Authenticated by Multiple MACs 10 draft-ietf-krb-wg-cammac-11 12 Abstract 14 Abstract: This document specifies a Kerberos Authorization Data 15 container that supersedes AD-KDC-ISSUED. It allows for multiple 16 Message Authentication Codes (MACs) or signatures to authenticate the 17 contained Authorization Data elements. This document updates RFC 18 4120. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 6, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 10.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This document specifies a new Authorization Data container for 71 Kerberos, called AD-CAMMAC (Container Authenticated by Multiple 72 MACs), that supersedes AD-KDC-ISSUED. This new container allows both 73 the receiving application service and the Key Distribution Center 74 (KDC) itself to verify the authenticity of the contained 75 authorization data. The AD-CAMMAC container can also include 76 additional verifiers that "trusted services" can use to verify the 77 contained authorization data. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 3. Motivations 87 The Kerberos protocol allows clients to submit arbitrary 88 authorization data for a KDC to insert into a Kerberos ticket. These 89 client-requested authorization data allow the client to express 90 authorization restrictions that the application service will 91 interpret. With few exceptions, the KDC can safely copy these 92 client-requested authorization data to the issued ticket without 93 necessarily inspecting, interpreting, or filtering their contents. 95 The AD-KDC-ISSUED authorization data container specified in RFC 4120 96 [RFC4120] is a means for KDCs to include positive or permissive 97 (rather than restrictive) authorization data in service tickets in a 98 way that the service named in a ticket can verify that the KDC has 99 issued the contained authorization data. This capability takes 100 advantage of a shared symmetric key between the KDC and the service 101 to assure the service that the KDC did not merely copy client- 102 requested authorization data to the ticket without inspecting them. 104 The AD-KDC-ISSUED container works well for situations where the flow 105 of authorization data is from the KDC to the service. However, 106 protocol extensions such as Constrained Delegation (S4U2Proxy 107 [MS-SFU]) require that a service present to the KDC a service ticket 108 that the KDC previously issued, as evidence that the service is 109 authorized to impersonate the client principal named in that ticket. 110 In the S4U2Proxy extension, the KDC uses the evidence ticket as the 111 basis for issuing a derivative ticket that the service can then use 112 to impersonate the client. The authorization data contained within 113 the evidence ticket constitute a flow of authorization data from the 114 application service to the KDC. The properties of the AD-KDC-ISSUED 115 container are insufficient for this use case because the service 116 knows the symmetric key for the checksum in the AD-KDC-ISSUED 117 container. Therefore, the KDC has no way to detect whether the 118 service has tampered with the contents of the AD-KDC-ISSUED container 119 within the evidence ticket. 121 The new AD-CAMMAC authorization data container specified in this 122 document improves upon AD-KDC-ISSUED by including additional verifier 123 elements. The svc-verifier element of the CAMMAC has the same 124 functional and security properties as the ad-checksum element of AD- 125 KDC-ISSUED; the svc-verifier allows the service to verify the 126 integrity of the AD-CAMMAC contents as it already could with the AD- 127 KDC-ISSUED container. The kdc-verifier and other-verifiers elements 128 are new to AD-CAMMAC and provide its enhanced capabilities. 130 The kdc-verifier element of the AD-CAMMAC container allows a KDC to 131 verify the integrity of authorization data that it previously 132 inserted into a ticket, by using a key that only the KDC knows. The 133 KDC thus avoids recomputing all of the authorization data for the 134 issued ticket; this operation might not always be possible when that 135 data includes ephemeral information such as the strength or type of 136 authentication method used to obtain the original ticket. 138 The verifiers in the other-verifiers element of the AD-CAMMAC 139 container are not required, but can be useful when a lesser- 140 privileged service receives a ticket from a client and needs to 141 extract the CAMMAC to demonstrate to a higher-privileged "trusted 142 service" on the same host that it is legitimately acting on behalf of 143 that client. The trusted service can use a verifier in the other- 144 verifiers element to validate the contents of the CAMMAC without 145 further communication with the KDC. 147 4. Encoding 149 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 150 Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished 151 Encoding Rules (DER) [X.690]. For consistency, this specification 152 also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data 153 of the AD-CAMMAC authorization data element is the ASN.1 DER encoding 154 of the AD-CAMMAC ASN.1 type specified below. 156 KerberosV5CAMMAC DEFINITIONS EXPLICIT TAGS ::= BEGIN 158 AD-CAMMAC ::= SEQUENCE { 159 elements [0] AuthorizationData, 160 kdc-verifier [1] Verifier-MAC OPTIONAL, 161 svc-verifier [2] Verifier-MAC OPTIONAL, 162 other-verifiers [3] SEQUENCE (SIZE (1..MAX)) 163 OF Verifier OPTIONAL 164 } 166 Verifier ::= CHOICE { 167 mac Verifier-MAC, 168 ... 169 } 171 Verifier-MAC ::= SEQUENCE { 172 identifier [0] PrincipalName OPTIONAL, 173 kvno [1] UInt32 OPTIONAL, 174 enctype [2] Int32 OPTIONAL, 175 mac [3] Checksum 176 } 178 END 180 elements: 181 A sequence of authorization data elements issued by the KDC. 182 These elements are the authorization data that the verifier fields 183 authenticate. 185 Verifier: 186 A CHOICE type that currently contains only one alternative: 187 Verifier-MAC. Future extensions might add support for public-key 188 signatures. 190 Verifier-MAC: 192 Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the 193 ASN.1 DER encoding of the AuthorizationData value in the elements 194 field of the AD-CAMMAC. The identifier, kvno, and enctype fields 195 help the recipient locate the key required for verifying the MAC. 196 For the kdc-verifier and the svc-verifier, the identifier, kvno 197 and enctype fields are often obvious from context and MAY be 198 omitted. For the kdc-verifier, the MAC is computed differently 199 than for the svc-verifier and the other-verifiers, as described 200 later. The key usage for computing the MAC (Checksum) is 64. 202 kdc-verifier: 203 A Verifier-MAC where the key is a long-term key of the local 204 Ticket-Granting Service (TGS). The checksum type is the required 205 checksum type for the enctype of the TGS key. In contrast to the 206 other Verifier-MAC elements, the KDC computes the MAC in the kdc- 207 verifier over the ASN.1 DER encoding of the EncTicketPart of the 208 surrounding ticket, but where the AuthorizationData value in the 209 EncTicketPart contains the AuthorizationData value contained in 210 the CAMMAC instead of the AuthorizationData value that would 211 otherwise be present in the ticket. This altered Verifier-MAC 212 computation binds the kdc-verifier to the other contents of the 213 ticket, assuring the KDC that a malicious service has not 214 substituted a mismatched CAMMAC received from another ticket. 216 svc-verifier: 217 A Verifier-MAC where the key is the same long-term service key 218 that the KDC uses to encrypt the surrounding ticket. The checksum 219 type is the required checksum type for the enctype of the service 220 key used to encrypt the ticket. This field MUST be present if the 221 service principal of the ticket is not the local TGS, including 222 when the ticket is a cross-realm TGT. 224 other-verifiers: 225 A sequence of additional verifiers. In each additional Verifier- 226 MAC, the key is a long-term key of the principal name specified in 227 the identifier field. The PrincipalName MUST be present and be a 228 valid principal in the realm. KDCs MAY add one or more "trusted 229 service" verifiers. Unless otherwise administratively configured, 230 the KDC SHOULD determine the "trusted service" principal name by 231 replacing the service identifier component of the sname of the 232 surrounding ticket with "host". The checksum is computed using a 233 long-term key of the identified principal, and the checksum type 234 is the required checksum type for the enctype of that long-term 235 key. The kvno and enctype SHOULD be specified to disambiguate 236 which of the long-term keys of the trusted service is used. 238 5. Usage 240 Application servers and KDCs MAY ignore the AD-CAMMAC container and 241 the authorization data elements it contains. For compatibility with 242 older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD 243 enclose it in an AD-IF-RELEVANT container unless the KDC knows that 244 the application server is likely to recognize it. 246 6. Assigned numbers 248 The ad-type number for AD-CAMMAC is 96. 250 The key usage number for the Verifier-MAC checksum is 64. 252 7. IANA Considerations 254 [ RFC Editor: please remove this section prior to publication. ] 256 There are no IANA considerations in this document. Any numbers 257 assigned in this document are not in IANA-controlled number spaces. 259 8. Security Considerations 261 Although authorization data are generally conveyed within the 262 encrypted part of a ticket and are thereby protected by the existing 263 encryption scheme used for the surrounding ticket, some authorization 264 data requires the additional protection provided by the CAMMAC. 266 Some protocol extensions such as S4U2Proxy allow the KDC to issue a 267 new ticket based on an evidence ticket provided by the service. If 268 the evidence ticket contains authorization data that needs to be 269 preserved in the new ticket, then the KDC MUST revalidate it. 271 Extracting a CAMMAC from a ticket for use as a credential removes it 272 from the context of the ticket. In the general case, this could turn 273 it into a bearer token, with all of the associated security 274 implications. Also, the CAMMAC does not itself necessarily contain 275 sufficient information to identify the client principal. Therefore, 276 application protocols that rely on extracted CAMMACs might need to 277 duplicate a substantial portion of the ticket contents and include 278 that duplicated information in the authorization data contained 279 within the CAMMAC. The extent of this duplication would depend on 280 the security properties required by the application protocol. 282 The method for computing the kdc-verifier does not bind it to any 283 authorization data within the ticket but outside of the CAMMAC. At 284 least one (non-standard) authorization data type, AD-SIGNEDPATH, 285 attempts to bind to other authorization data in a ticket, and it is 286 very difficult for two such authorization data types to coexist. 288 To minimize ticket size when embedding CAMMACs in Kerberos tickets, a 289 KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed. 290 In this situation, the KDC cannot always determine whether the CAMMAC 291 contents are intact. The KDC MUST NOT create a new CAMMAC from an 292 existing one unless the existing CAMMAC has a valid kdc-verifier, 293 with two exceptions. 295 Only KDCs for the local realm have knowledge of the local TGS key, so 296 the outer encryption of a local TGT is sufficient to protect the 297 CAMMAC of a local TGT from tampering, assuming that all of the KDCs 298 in the local realm consistently filter out CAMMAC authorization data 299 submitted by clients. The KDC MAY create a new CAMMAC from an 300 existing CAMMAC lacking a kdc-verifier if that CAMMAC is contained 301 within a local TGT and all of the local realm KDCs are configured to 302 filter out CAMMAC authorization data submitted by clients. 304 An application service might not use the S4U2Proxy extension, or the 305 realm policy might disallow the use of S4U2Proxy by that service. In 306 such situations where there is no flow of authorization data from the 307 service to the KDC, the application service could modify the CAMMAC 308 contents, but such modifications would have no effect on other 309 services. Because of the lack of security impact, the KDC MAY create 310 a new CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is 311 inserting the new CAMMAC into a service ticket for the same service 312 principal as the ticket that contained the existing CAMMAC, but MUST 313 NOT place a kdc-verifier in the new CAMMAC. 315 The kdc-verifier in CAMMAC does not bind the service principal name 316 to the CAMMAC contents, because the service principal name is not 317 part of the EncTicketPart. An entity that has access to the keys of 318 two different service principals can decrypt a ticket for one service 319 and encrypt it in the key of the other service, altering the svc- 320 verifier to match. Both the kdc-verifier and the svc-verifier would 321 still validate, but the KDC never issued this fabricated ticket. The 322 impact of this manipulation is minor if the CAMMAC contents only 323 communicate attributes related to the client. If an application 324 requires an authenticated binding between the service principal name 325 and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC 326 some authorization data element that names the service principal. 328 9. Acknowledgements 330 Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Zhanna Tsitkov, and 331 Kai Zheng provided helpful technical and editorial feedback on 332 earlier versions of this document. 334 10. References 336 10.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 342 Kerberos 5", RFC 3961, February 2005. 344 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 345 Kerberos Network Authentication Service (V5)", RFC 4120, 346 July 2005. 348 [X.680] ISO, , "Information technology -- Abstract Syntax Notation 349 One (ASN.1): Specification of basic notation -- ITU-T 350 Recommendation X.680 (ISO/IEC International Standard 351 8824-1:2008)", 2008. 353 [X.690] ISO, , "Information technology -- ASN.1 encoding rules: 354 Specification of Basic Encoding Rules (BER), Canonical 355 Encoding Rules (CER) and Distinguished Encoding Rules 356 (DER) -- ITU-T Recommendation X.690 (ISO/IEC International 357 Standard 8825-1:2008)", 1997. 359 10.2. Informative References 361 [MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: 362 Service for User and Constrained Delegation Protocol", 363 January 2013, 364 . 366 Authors' Addresses 368 Simo Sorce (editor) 369 Red Hat 371 Email: ssorce@redhat.com 373 Tom Yu (editor) 374 MIT Kerberos Consortium 376 Email: tlyu@mit.edu 377 Thomas Hardjono (editor) 378 MIT Kerberos Consortium 380 Email: hardjono@mit.edu