idnits 2.17.1 draft-ietf-kitten-cammac-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 : ---------------------------------------------------------------------------- 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 (January 5, 2015) is 3392 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 185 -- Looks like a reference, but probably isn't: '1' on line 186 -- Looks like a reference, but probably isn't: '2' on line 187 -- Looks like a reference, but probably isn't: '3' on line 188 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: July 9, 2015 MIT Kerberos Consortium 7 January 5, 2015 9 Kerberos Authorization Data Container Authenticated by Multiple MACs 10 draft-ietf-kitten-cammac-01 12 Abstract 14 This document specifies a Kerberos Authorization Data container that 15 supersedes AD-KDC-ISSUED. It allows for multiple Message 16 Authentication Codes (MACs) or signatures to authenticate the 17 contained Authorization Data elements. The multiple MACs are needed 18 to mitigate shortcomings in the existing AD-KDC-ISSUED container. 19 This document updates RFC 4120. 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 July 9, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 10.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 This document specifies a new Authorization Data container for 72 Kerberos, called the CAMMAC (Container Authenticated by Multiple 73 MACs). The ASN.1 type implementing the CAMMAC concept is the AD- 74 CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type 75 specified in [RFC4120]. This new container allows both the receiving 76 application service and the Key Distribution Center (KDC) itself to 77 verify the authenticity of the contained authorization data. The AD- 78 CAMMAC container can also include additional verifiers that "trusted 79 services" can use to verify the contained authorization data. 81 2. Requirements Language 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. Motivations 89 The Kerberos protocol allows clients to submit arbitrary 90 authorization data for a KDC to insert into a Kerberos ticket. These 91 client-requested authorization data allow the client to express 92 authorization restrictions that the application service will 93 interpret. With few exceptions, the KDC can safely copy these 94 client-requested authorization data to the issued ticket without 95 necessarily inspecting, interpreting, or filtering their contents. 97 The AD-KDC-ISSUED authorization data container specified in RFC 4120 98 [RFC4120] is a means for KDCs to include positive or permissive 99 (rather than restrictive) authorization data in service tickets in a 100 way that the service named in a ticket can verify that the KDC has 101 issued the contained authorization data. This capability takes 102 advantage of a shared symmetric key between the KDC and the service 103 to assure the service that the KDC did not merely copy client- 104 requested authorization data to the ticket without inspecting them. 106 The AD-KDC-ISSUED container works well for situations where the flow 107 of authorization data is from the KDC to the service. However, 108 protocol extensions such as Constrained Delegation (S4U2Proxy 109 [MS-SFU]) require that a service present to the KDC a service ticket 110 that the KDC previously issued, as evidence that the service is 111 authorized to impersonate the client principal named in that ticket. 112 In the S4U2Proxy extension, the KDC uses the evidence ticket as the 113 basis for issuing a derivative ticket that the service can then use 114 to impersonate the client. The authorization data contained within 115 the evidence ticket constitute a flow of authorization data from the 116 application service to the KDC. The properties of the AD-KDC-ISSUED 117 container are insufficient for this use case because the service 118 knows the symmetric key for the checksum in the AD-KDC-ISSUED 119 container. Therefore, the KDC has no way to detect whether the 120 service has tampered with the contents of the AD-KDC-ISSUED container 121 within the evidence ticket. 123 The new AD-CAMMAC authorization data container specified in this 124 document improves upon AD-KDC-ISSUED by including additional verifier 125 elements. The svc-verifier (service verifier) element of the AD- 126 CAMMAC has the same functional and security properties as the ad- 127 checksum element of AD-KDC-ISSUED; the svc-verifier allows the 128 service to verify the integrity of the AD-CAMMAC contents as it 129 already could with the AD-KDC-ISSUED container. The kdc-verifier and 130 other-verifiers elements are new to AD-CAMMAC and provide its 131 enhanced capabilities. 133 The kdc-verifier element of the AD-CAMMAC container allows a KDC to 134 verify the integrity of authorization data that it previously 135 inserted into a ticket, by using a key that only the KDC knows. The 136 KDC thus avoids recomputing all of the authorization data for the 137 issued ticket; this recomputation might not always be possible when 138 that data includes ephemeral information such as the strength or type 139 of authentication method used to obtain the original ticket. 141 The verifiers in the other-verifiers element of the AD-CAMMAC 142 container are not required, but can be useful when a lesser- 143 privileged service receives a ticket from a client and needs to 144 extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted 145 service" on the same host that it is legitimately acting on behalf of 146 that client. The trusted service can use a verifier in the other- 147 verifiers element to validate the contents of the AD-CAMMAC without 148 further communication with the KDC. 150 4. Encoding 152 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 153 Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished 154 Encoding Rules (DER) [X.690]. For consistency, this specification 155 also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data 156 of the AD-CAMMAC authorization data element is the ASN.1 DER encoding 157 of the AD-CAMMAC ASN.1 type specified below. 159 KerberosV5CAMMAC { 160 iso(1) identified-organization(3) dod(6) internet(1) 161 security(5) kerberosV5(2) modules(4) cammac(7) 162 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 164 IMPORTS 165 AuthorizationData, PrincipalName, Checksum, UInt32, Int32 166 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 167 dod(6) internet(1) security(5) kerberosV5(2) 168 modules(4) krb5spec2(2) }; 169 -- as defined in RFC 4120. 171 AD-CAMMAC ::= SEQUENCE { 172 elements [0] AuthorizationData, 173 kdc-verifier [1] Verifier-MAC OPTIONAL, 174 svc-verifier [2] Verifier-MAC OPTIONAL, 175 other-verifiers [3] SEQUENCE (SIZE (1..MAX)) 176 OF Verifier OPTIONAL 177 } 179 Verifier ::= CHOICE { 180 mac Verifier-MAC, 181 ... 182 } 184 Verifier-MAC ::= SEQUENCE { 185 identifier [0] PrincipalName OPTIONAL, 186 kvno [1] UInt32 OPTIONAL, 187 enctype [2] Int32 OPTIONAL, 188 mac [3] Checksum 189 } 191 END 193 elements: 194 A sequence of authorization data elements issued by the KDC. 195 These elements are the authorization data that the verifier fields 196 authenticate. 198 Verifier: 199 A CHOICE type that currently contains only one alternative: 200 Verifier-MAC. Future extensions might add support for public-key 201 signatures. 203 Verifier-MAC: 204 Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the 205 ASN.1 DER encoding of the AuthorizationData value in the elements 206 field of the AD-CAMMAC. The identifier, kvno, and enctype fields 207 help the recipient locate the key required for verifying the MAC. 208 For the kdc-verifier and the svc-verifier, the identifier, kvno 209 and enctype fields are often obvious from context and MAY be 210 omitted. For the kdc-verifier, the MAC is computed differently 211 than for the svc-verifier and the other-verifiers, as described 212 later. The key usage number for computing the MAC (Checksum) is 213 64. 215 kdc-verifier: 216 A Verifier-MAC where the key is a long-term key of the local 217 Ticket-Granting Service (TGS). The checksum type is the required 218 checksum type for the enctype of the TGS key. In contrast to the 219 other Verifier-MAC elements, the KDC computes the MAC in the kdc- 220 verifier over the ASN.1 DER encoding of the EncTicketPart of the 221 surrounding ticket, but where the AuthorizationData value in the 222 EncTicketPart contains the AuthorizationData value contained in 223 the AD-CAMMAC instead of the AuthorizationData value that would 224 otherwise be present in the ticket. This altered Verifier-MAC 225 computation binds the kdc-verifier to the other contents of the 226 ticket, assuring the KDC that a malicious service has not 227 substituted a mismatched AD-CAMMAC received from another ticket. 229 svc-verifier: 230 A Verifier-MAC where the key is the same long-term service key 231 that the KDC uses to encrypt the surrounding ticket. The checksum 232 type is the required checksum type for the enctype of the service 233 key used to encrypt the ticket. This field MUST be present if the 234 service principal of the ticket is not the local TGS, including 235 when the ticket is a cross-realm Ticket-Granting Ticket (TGT). 237 other-verifiers: 238 A sequence of additional verifiers. In each additional Verifier- 239 MAC, the key is a long-term key of the principal name specified in 240 the identifier field. The PrincipalName MUST be present and be a 241 valid principal in the realm. KDCs MAY add one or more "trusted 242 service" verifiers. Unless otherwise administratively configured, 243 the KDC SHOULD determine the "trusted service" principal name by 244 replacing the service identifier component of the sname of the 245 surrounding ticket with "host". The checksum is computed using a 246 long-term key of the identified principal, and the checksum type 247 is the required checksum type for the enctype of that long-term 248 key. The kvno and enctype SHOULD be specified to disambiguate 249 which of the long-term keys of the trusted service is used. 251 5. Usage 253 Application servers and KDCs MAY ignore the AD-CAMMAC container and 254 the authorization data elements it contains. For compatibility with 255 older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD 256 enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC 257 knows that the application server is likely to recognize it. 259 6. Assigned numbers 261 RFC 4120 is updated in the following ways: 263 o The ad-type number 96 is assigned for AD-CAMMAC, updating the 264 table in Section 7.5.4 of [RFC4120]. 266 o The table in Section 5.2.6 of [RFC4120] is updated to map the ad- 267 type 96 to "DER encoding of AD-CAMMAC". 269 o The key usage number 64 is assigned for the Verifier-MAC checksum, 270 updating the table in Section 7.5.1 of [RFC4120]. 272 7. IANA Considerations 274 [ RFC Editor: please remove this section prior to publication. ] 276 There are no IANA considerations in this document. Any numbers 277 assigned in this document are not in IANA-controlled number spaces. 279 8. Security Considerations 281 The CAMMAC provides data origin authentication for authorization data 282 contained in it, attesting that it originated from the KDC. This 283 section describes the precautions required to maintain the integrity 284 of that data origin authentication through various information flows 285 involving a Kerberos ticket containing a CAMMAC. 287 Although authorization data are generally conveyed within the 288 encrypted part of a ticket and are thereby protected by the existing 289 encryption scheme used for the surrounding ticket, some authorization 290 data requires the additional protection provided by the CAMMAC. 292 Some protocol extensions such as S4U2Proxy allow the KDC to issue a 293 new ticket based on an evidence ticket provided by the service. If 294 the evidence ticket contains authorization data that needs to be 295 preserved in the new ticket, then the KDC MUST verify the kdc- 296 verifier prior to copying the contained authorization data to a new 297 CAMMAC, except in the two situations enumerated below. 299 Extracting a CAMMAC from a ticket for use as a credential removes it 300 from the context of the ticket. In the general case, this could turn 301 it into a bearer token, with all of the associated security 302 implications. Also, the CAMMAC does not itself necessarily contain 303 sufficient information to identify the client principal. Therefore, 304 application protocols that rely on extracted CAMMACs might need to 305 duplicate a substantial portion of the ticket contents and include 306 that duplicated information in the authorization data contained 307 within the CAMMAC. The extent of this duplication would depend on 308 the security properties required by the application protocol. 310 The method for computing the kdc-verifier binds it only to the 311 authorization data contained within the CAMMAC; it does not bind the 312 CAMMAC to any authorization data within the containing ticket but 313 outside the CAMMAC. At least one (non-standard) authorization data 314 type, AD-SIGNEDPATH, attempts to bind to other authorization data in 315 a ticket, and it is very difficult for two such authorization data 316 types to coexist. 318 To minimize ticket size when embedding CAMMACs in Kerberos tickets, a 319 KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed. 320 In this situation, the KDC cannot always determine whether the CAMMAC 321 contents are intact. The KDC MUST NOT create a new CAMMAC from an 322 existing one unless the existing CAMMAC has a valid kdc-verifier, 323 with two exceptions: 325 1. Only KDCs for the local realm have knowledge of the local TGS 326 key, so the outer encryption of a local TGT is sufficient to 327 protect the CAMMAC of a local TGT from tampering, assuming that 328 all of the KDCs in the local realm consistently filter out CAMMAC 329 authorization data submitted by clients. The KDC MAY create a 330 new CAMMAC from an existing CAMMAC lacking a kdc-verifier if that 331 CAMMAC is contained within a local TGT and all of the local realm 332 KDCs are configured to filter out CAMMAC authorization data 333 submitted by clients. 335 2. An application service might not use the S4U2Proxy extension, or 336 the realm policy might disallow the use of S4U2Proxy by that 337 service. In such situations where there is no flow of 338 authorization data from the service to the KDC, the application 339 service could modify the CAMMAC contents, but such modifications 340 would have no effect on other services. Because of the lack of 341 security impact, the KDC MAY create a new CAMMAC from an existing 342 CAMMAC lacking a kdc-verifier if it is inserting the new CAMMAC 343 into a service ticket for the same service principal as the 344 ticket that contained the existing CAMMAC, but MUST NOT place a 345 kdc-verifier in the new CAMMAC. 347 The kdc-verifier in CAMMAC does not bind the service principal name 348 to the CAMMAC contents, because the service principal name is not 349 part of the EncTicketPart. An entity that has access to the keys of 350 two different service principals can decrypt a ticket for one service 351 and encrypt it in the key of the other service, altering the svc- 352 verifier to match. Both the kdc-verifier and the svc-verifier would 353 still validate, but the KDC never issued this fabricated ticket. The 354 impact of this manipulation is minor if the CAMMAC contents only 355 communicate attributes related to the client. If an application 356 requires an authenticated binding between the service principal name 357 and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC 358 some authorization data element that names the service principal. 360 9. Acknowledgements 362 Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral 363 Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful 364 technical and editorial feedback on earlier versions of this 365 document. 367 10. References 369 10.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 375 Kerberos 5", RFC 3961, February 2005. 377 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 378 Kerberos Network Authentication Service (V5)", RFC 4120, 379 July 2005. 381 [X.680] ISO, , "Information technology -- Abstract Syntax Notation 382 One (ASN.1): Specification of basic notation -- ITU-T 383 Recommendation X.680 (ISO/IEC International Standard 384 8824-1:2008)", 2008. 386 [X.690] ISO, , "Information technology -- ASN.1 encoding rules: 387 Specification of Basic Encoding Rules (BER), Canonical 388 Encoding Rules (CER) and Distinguished Encoding Rules 389 (DER) -- ITU-T Recommendation X.690 (ISO/IEC International 390 Standard 8825-1:2008)", 1997. 392 10.2. Informative References 394 [MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: 395 Service for User and Constrained Delegation Protocol", 396 January 2013, 397 . 399 Authors' Addresses 401 Simo Sorce (editor) 402 Red Hat 404 Email: ssorce@redhat.com 406 Tom Yu (editor) 407 MIT Kerberos Consortium 409 Email: tlyu@mit.edu 411 Thomas Hardjono (editor) 412 MIT Kerberos Consortium 414 Email: hardjono@mit.edu