idnits 2.17.1 draft-ietf-kitten-cammac-03.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 (June 25, 2015) is 3199 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: December 27, 2015 MIT Kerberos Consortium 7 June 25, 2015 9 Kerberos Authorization Data Container Authenticated by Multiple MACs 10 draft-ietf-kitten-cammac-03 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 December 27, 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 . . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 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 When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy 288 decision on how to produce the CAMMAC contents of the newly issued 289 ticket based on properties of the ticket(s) accompanying the TGS-REQ. 290 This policy decision can involve filtering, transforming, or verbatim 291 copying of the original CAMMAC contents. The following paragraphs 292 provide some guidance on formulating such policies. 294 A KDC verifies a CAMMAC as originating from a local realm KDC when at 295 least one of following the criteria is true: 297 1. The KDC successfully verifies the kdc-verifier; or 299 2. The KDC successfully verifies the svc-verifier, and the svc- 300 verifier uses a key known only to the local realm KDCs; or 302 3. No verifiers are present, the ticket-encrypting key is known only 303 to local realm KDCs, and all local realm KDCs properly filter out 304 client-submitted CAMMACs. (This can require particular caution 305 in a realm that has KDCs with mixed CAMMAC support, as might 306 happen when incrementally upgrading KDCs in a realm to support 307 CAMMAC.) 309 A CAMMAC that originates from a local realm KDC might contain 310 information that originates from elsewhere. Originating from a local 311 realm KDC means that a local realm KDC attests that the CAMMAC 312 contents conform to the local realm's policy, regardless of the 313 ultimate origin of the information in the CAMMAC (which could be a 314 remote realm in the case of a CAMMAC contained in a cross-realm TGT). 316 Local policy determines when a KDC can apply a kdc-verifier to a 317 CAMMAC (or otherwise creates a CAMMAC that satisfies the local origin 318 criteria listed above). Semantically, a CAMMAC that a KDC verifies 319 as originating from a local realm KDC attests that the CAMMAC 320 contents conformed to local policy at the time of creation of the 321 CAMMAC. Such a local policy can include allowing verbatim copying of 322 CAMMAC contents from cross-realm TGTs from designated remote realms 323 and applying a kdc-verifier to the new CAMMAC. 325 Usually, when a KDC verifies a CAMMAC as originating from a local 326 realm KDC, the KDC can assume that the CAMMAC contents continue to 327 conform to the local realm's policies. It is generally safe for a 328 KDC to make verbatim copies of the contents of such a CAMMAC into a 329 new CAMMAC when handling a TGS-REQ. Particularly strict 330 implementations might conduct additional policy checks on the 331 contents of a CAMMAC originating from a local realm KDC if the local 332 realm's policy materially changes during the life of the CAMMAC. 334 A KDC MAY omit the kdc-verifier from the CAMMAC when it is not 335 needed, according to how realm policies will subsequently treat the 336 containing ticket. An implementation might choose to do this 337 omission to reduce the size of tickets it issues. Some examples of 338 when such an omission is safe are: 340 1. For a local realm TGT, if all local realm KDCs correctly filter 341 out client-submitted CAMMACs, the local realm origin criteria 342 listed above allow omission of the kdc-verifier. 344 2. An application service might not use the S4U2Proxy extension, or 345 the realm policy might disallow the use of S4U2Proxy by that 346 service. In such situations where there is no flow of 347 authorization data from the service to the KDC, the application 348 service could modify the CAMMAC contents, but such modifications 349 would have no effect on other services. Because of the lack of 350 security impact to other application services, the KDC MAY omit 351 the kdc-verifier from a CAMMAC contained in a ticket for that 352 service. 354 Extracting a CAMMAC from a ticket for use as a credential removes it 355 from the context of the ticket. In the general case, this could turn 356 it into a bearer token, with all of the associated security 357 implications. Also, the CAMMAC does not itself necessarily contain 358 sufficient information to identify the client principal. Therefore, 359 application protocols that rely on extracted CAMMACs might need to 360 duplicate a substantial portion of the ticket contents and include 361 that duplicated information in the authorization data contained 362 within the CAMMAC. The extent of this duplication would depend on 363 the security properties required by the application protocol. 365 The method for computing the kdc-verifier binds it only to the 366 authorization data contained within the CAMMAC; it does not bind the 367 CAMMAC to any authorization data within the containing ticket but 368 outside the CAMMAC. At least one (non-standard) authorization data 369 type, AD-SIGNEDPATH, attempts to bind to other authorization data in 370 a ticket, and it is very difficult for two such authorization data 371 types to coexist. 373 The kdc-verifier in CAMMAC does not bind the service principal name 374 to the CAMMAC contents, because the service principal name is not 375 part of the EncTicketPart. An entity that has access to the keys of 376 two different service principals can decrypt a ticket for one service 377 and encrypt it in the key of the other service, altering the svc- 378 verifier to match. Both the kdc-verifier and the svc-verifier would 379 still validate, but the KDC never issued this fabricated ticket. The 380 impact of this manipulation is minor if the CAMMAC contents only 381 communicate attributes related to the client. If an application 382 requires an authenticated binding between the service principal name 383 and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC 384 some authorization data element that names the service principal. 386 9. Acknowledgements 388 Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral 389 Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful 390 technical and editorial feedback on earlier versions of this 391 document. 393 10. References 395 10.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 401 Kerberos 5", RFC 3961, February 2005. 403 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 404 Kerberos Network Authentication Service (V5)", RFC 4120, 405 July 2005. 407 [X.680] ITU-T, "Information technology -- Abstract Syntax Notation 408 One (ASN.1): Specification of basic notation -- ITU-T 409 Recommendation X.680 (ISO/IEC International Standard 410 8824-1:2008)", 2008. 412 [X.690] ITU-T, "Information technology -- ASN.1 encoding rules: 413 Specification of Basic Encoding Rules (BER), Canonical 414 Encoding Rules (CER) and Distinguished Encoding Rules 415 (DER) -- ITU-T Recommendation X.690 (ISO/IEC International 416 Standard 8825-1:2008)", 2008. 418 10.2. Informative References 420 [MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: 421 Service for User and Constrained Delegation Protocol", 422 January 2013, 423 . 425 Authors' Addresses 427 Simo Sorce (editor) 428 Red Hat 430 Email: ssorce@redhat.com 431 Tom Yu (editor) 432 MIT Kerberos Consortium 434 Email: tlyu@mit.edu 436 Thomas Hardjono (editor) 437 MIT Kerberos Consortium 439 Email: hardjono@mit.edu