idnits 2.17.1 draft-ietf-kitten-cammac-04.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 (November 1, 2015) is 3099 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 184 -- Looks like a reference, but probably isn't: '1' on line 185 -- Looks like a reference, but probably isn't: '2' on line 186 -- Looks like a reference, but probably isn't: '3' on line 187 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 3 Internet-Draft Red Hat 4 Updates: 4120 (if approved) T. Yu 5 Intended status: Standards Track MIT 6 Expires: May 4, 2016 November 1, 2015 8 Kerberos Authorization Data Container Authenticated by Multiple MACs 9 draft-ietf-kitten-cammac-04 11 Abstract 13 This document specifies a Kerberos Authorization Data container that 14 supersedes AD-KDC-ISSUED. It allows for multiple Message 15 Authentication Codes (MACs) or signatures to authenticate the 16 contained Authorization Data elements. The multiple MACs are needed 17 to mitigate shortcomings in the existing AD-KDC-ISSUED container. 18 This document updates RFC 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 May 4, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 9 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 10.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This document specifies a new Authorization Data container for 71 Kerberos, called the CAMMAC (Container Authenticated by Multiple 72 MACs). The ASN.1 type implementing the CAMMAC concept is the AD- 73 CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type 74 specified in [RFC4120]. This new container allows both the receiving 75 application service and the Key Distribution Center (KDC) itself to 76 verify the authenticity of the contained authorization data. The AD- 77 CAMMAC container can also include additional verifiers that "trusted 78 services" can use to verify the contained authorization data. 80 2. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 3. Motivations 88 The Kerberos protocol allows clients to submit arbitrary 89 authorization data for a KDC to insert into a Kerberos ticket. These 90 client-requested authorization data allow the client to express 91 authorization restrictions that the application service will 92 interpret. With few exceptions, the KDC can safely copy these 93 client-requested authorization data to the issued ticket without 94 necessarily inspecting, interpreting, or filtering their contents. 96 The AD-KDC-ISSUED authorization data container specified in RFC 4120 97 [RFC4120] is a means for KDCs to include positive or permissive 98 (rather than restrictive) authorization data in service tickets in a 99 way that the service named in a ticket can verify that the KDC has 100 issued the contained authorization data. This capability takes 101 advantage of a shared symmetric key between the KDC and the service 102 to assure the service that the KDC did not merely copy client- 103 requested authorization data to the ticket without inspecting them. 105 The AD-KDC-ISSUED container works well for situations where the flow 106 of authorization data is from the KDC to the service. However, 107 protocol extensions such as Constrained Delegation (S4U2Proxy 108 [MS-SFU]) require that a service present to the KDC a service ticket 109 that the KDC previously issued, as evidence that the service is 110 authorized to impersonate the client principal named in that ticket. 111 In the S4U2Proxy extension, the KDC uses the evidence ticket as the 112 basis for issuing a derivative ticket that the service can then use 113 to impersonate the client. The authorization data contained within 114 the evidence ticket constitute a flow of authorization data from the 115 application service to the KDC. The properties of the AD-KDC-ISSUED 116 container are insufficient for this use case because the service 117 knows the symmetric key for the checksum in the AD-KDC-ISSUED 118 container. Therefore, the KDC has no way to detect whether the 119 service has tampered with the contents of the AD-KDC-ISSUED container 120 within the evidence ticket. 122 The new AD-CAMMAC authorization data container specified in this 123 document improves upon AD-KDC-ISSUED by including additional verifier 124 elements. The svc-verifier (service verifier) element of the AD- 125 CAMMAC has the same functional and security properties as the ad- 126 checksum element of AD-KDC-ISSUED; the svc-verifier allows the 127 service to verify the integrity of the AD-CAMMAC contents as it 128 already could with the AD-KDC-ISSUED container. The kdc-verifier and 129 other-verifiers elements are new to AD-CAMMAC and provide its 130 enhanced capabilities. 132 The kdc-verifier element of the AD-CAMMAC container allows a KDC to 133 verify the integrity of authorization data that it previously 134 inserted into a ticket, by using a key that only the KDC knows. The 135 KDC thus avoids recomputing all of the authorization data for the 136 issued ticket; this recomputation might not always be possible when 137 that data includes ephemeral information such as the strength or type 138 of authentication method used to obtain the original ticket. 140 The verifiers in the other-verifiers element of the AD-CAMMAC 141 container are not required, but can be useful when a lesser- 142 privileged service receives a ticket from a client and needs to 143 extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted 144 service" on the same host that it is legitimately acting on behalf of 145 that client. The trusted service can use a verifier in the other- 146 verifiers element to validate the contents of the AD-CAMMAC without 147 further communication with the KDC. 149 4. Encoding 151 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 152 Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished 153 Encoding Rules (DER) [X.690]. For consistency, this specification 154 also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data 155 of the AD-CAMMAC authorization data element is the ASN.1 DER encoding 156 of the AD-CAMMAC ASN.1 type specified below. 158 KerberosV5CAMMAC { 159 iso(1) identified-organization(3) dod(6) internet(1) 160 security(5) kerberosV5(2) modules(4) cammac(7) 161 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 163 IMPORTS 164 AuthorizationData, PrincipalName, Checksum, UInt32, Int32 165 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 166 dod(6) internet(1) security(5) kerberosV5(2) 167 modules(4) krb5spec2(2) }; 168 -- as defined in RFC 4120. 170 AD-CAMMAC ::= SEQUENCE { 171 elements [0] AuthorizationData, 172 kdc-verifier [1] Verifier-MAC OPTIONAL, 173 svc-verifier [2] Verifier-MAC OPTIONAL, 174 other-verifiers [3] SEQUENCE (SIZE (1..MAX)) 175 OF Verifier OPTIONAL 176 } 178 Verifier ::= CHOICE { 179 mac Verifier-MAC, 180 ... 181 } 183 Verifier-MAC ::= SEQUENCE { 184 identifier [0] PrincipalName OPTIONAL, 185 kvno [1] UInt32 OPTIONAL, 186 enctype [2] Int32 OPTIONAL, 187 mac [3] Checksum 188 } 190 END 192 elements: 193 A sequence of authorization data elements issued by the KDC. 194 These elements are the authorization data that the verifier fields 195 authenticate. 197 Verifier: 198 A CHOICE type that currently contains only one alternative: 199 Verifier-MAC. Future extensions might add support for public-key 200 signatures. 202 Verifier-MAC: 203 Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the 204 ASN.1 DER encoding of the AuthorizationData value in the elements 205 field of the AD-CAMMAC. The identifier, kvno, and enctype fields 206 help the recipient locate the key required for verifying the MAC. 207 For the kdc-verifier and the svc-verifier, the identifier, kvno 208 and enctype fields are often obvious from context and MAY be 209 omitted. For the kdc-verifier, the MAC is computed differently 210 than for the svc-verifier and the other-verifiers, as described 211 later. The key usage number for computing the MAC (Checksum) is 212 64. 214 kdc-verifier: 215 A Verifier-MAC where the key is a long-term key of the local 216 Ticket-Granting Service (TGS). The checksum type is the required 217 checksum type for the enctype of the TGS key. In contrast to the 218 other Verifier-MAC elements, the KDC computes the MAC in the kdc- 219 verifier over the ASN.1 DER encoding of the EncTicketPart of the 220 surrounding ticket, but where the AuthorizationData value in the 221 EncTicketPart contains the AuthorizationData value contained in 222 the AD-CAMMAC instead of the AuthorizationData value that would 223 otherwise be present in the ticket. This altered Verifier-MAC 224 computation binds the kdc-verifier to the other contents of the 225 ticket, assuring the KDC that a malicious service has not 226 substituted a mismatched AD-CAMMAC received from another ticket. 228 svc-verifier: 229 A Verifier-MAC where the key is the same long-term service key 230 that the KDC uses to encrypt the surrounding ticket. The checksum 231 type is the required checksum type for the enctype of the service 232 key used to encrypt the ticket. This field MUST be present if the 233 service principal of the ticket is not the local TGS, including 234 when the ticket is a cross-realm Ticket-Granting Ticket (TGT). 236 other-verifiers: 237 A sequence of additional verifiers. In each additional Verifier- 238 MAC, the key is a long-term key of the principal name specified in 239 the identifier field. The PrincipalName MUST be present and be a 240 valid principal in the realm. KDCs MAY add one or more "trusted 241 service" verifiers. Unless otherwise administratively configured, 242 the KDC SHOULD determine the "trusted service" principal name by 243 replacing the service identifier component of the sname of the 244 surrounding ticket with "host". The checksum is computed using a 245 long-term key of the identified principal, and the checksum type 246 is the required checksum type for the enctype of that long-term 247 key. The kvno and enctype SHOULD be specified to disambiguate 248 which of the long-term keys of the trusted service is used. 250 5. Usage 252 Application servers and KDCs MAY ignore the AD-CAMMAC container and 253 the authorization data elements it contains. For compatibility with 254 older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD 255 enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC 256 knows that the application server is likely to recognize it. 258 6. Assigned numbers 260 RFC 4120 is updated in the following ways: 262 o The ad-type number 96 is assigned for AD-CAMMAC, updating the 263 table in Section 7.5.4 of [RFC4120]. 265 o The table in Section 5.2.6 of [RFC4120] is updated to map the ad- 266 type 96 to "DER encoding of AD-CAMMAC". 268 o The key usage number 64 is assigned for the Verifier-MAC checksum, 269 updating the table in Section 7.5.1 of [RFC4120]. 271 7. IANA Considerations 273 [ RFC Editor: please remove this section prior to publication. ] 275 There are no IANA considerations in this document. Any numbers 276 assigned in this document are not in IANA-controlled number spaces. 278 8. Security Considerations 280 The CAMMAC provides data origin authentication for authorization data 281 contained in it, attesting that it originated from the KDC. This 282 section describes the precautions required to maintain the integrity 283 of that data origin authentication through various information flows 284 involving a Kerberos ticket containing a CAMMAC. 286 When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy 287 decision on how to produce the CAMMAC contents of the newly issued 288 ticket based on properties of the ticket(s) accompanying the TGS-REQ. 289 This policy decision can involve filtering, transforming, or verbatim 290 copying of the original CAMMAC contents. The following paragraphs 291 provide some guidance on formulating such policies. 293 A KDC verifies a CAMMAC as originating from a local realm KDC when at 294 least one of following the criteria is true: 296 1. The KDC successfully verifies the kdc-verifier; or 298 2. The KDC successfully verifies the svc-verifier, and the svc- 299 verifier uses a key known only to the local realm KDCs; or 301 3. No verifiers are present, the ticket-encrypting key is known only 302 to local realm KDCs, and all local realm KDCs properly filter out 303 client-submitted CAMMACs. (This can require particular caution 304 in a realm that has KDCs with mixed CAMMAC support, as might 305 happen when incrementally upgrading KDCs in a realm to support 306 CAMMAC.) 308 A CAMMAC that originates from a local realm KDC might contain 309 information that originates from elsewhere. Originating from a local 310 realm KDC means that a local realm KDC attests that the CAMMAC 311 contents conform to the local realm's policy, regardless of the 312 ultimate origin of the information in the CAMMAC (which could be a 313 remote realm in the case of a CAMMAC contained in a cross-realm TGT). 315 Local policy determines when a KDC can apply a kdc-verifier to a 316 CAMMAC (or otherwise creates a CAMMAC that satisfies the local origin 317 criteria listed above). Semantically, a CAMMAC that a KDC verifies 318 as originating from a local realm KDC attests that the CAMMAC 319 contents conformed to local policy at the time of creation of the 320 CAMMAC. Such a local policy can include allowing verbatim copying of 321 CAMMAC contents from cross-realm TGTs from designated remote realms 322 and applying a kdc-verifier to the new CAMMAC. 324 Usually, when a KDC verifies a CAMMAC as originating from a local 325 realm KDC, the KDC can assume that the CAMMAC contents continue to 326 conform to the local realm's policies. It is generally safe for a 327 KDC to make verbatim copies of the contents of such a CAMMAC into a 328 new CAMMAC when handling a TGS-REQ. Particularly strict 329 implementations might conduct additional policy checks on the 330 contents of a CAMMAC originating from a local realm KDC if the local 331 realm's policy materially changes during the life of the CAMMAC. 333 A KDC MAY omit the kdc-verifier from the CAMMAC when it is not 334 needed, according to how realm policies will subsequently treat the 335 containing ticket. An implementation might choose to do this 336 omission to reduce the size of tickets it issues. Some examples of 337 when such an omission is safe are: 339 1. For a local realm TGT, if all local realm KDCs correctly filter 340 out client-submitted CAMMACs, the local realm origin criteria 341 listed above allow omission of the kdc-verifier. 343 2. An application service might not use the S4U2Proxy extension, or 344 the realm policy might disallow the use of S4U2Proxy by that 345 service. In such situations where there is no flow of 346 authorization data from the service to the KDC, the application 347 service could modify the CAMMAC contents, but such modifications 348 would have no effect on other services. Because of the lack of 349 security impact to other application services, the KDC MAY omit 350 the kdc-verifier from a CAMMAC contained in a ticket for that 351 service. 353 Extracting a CAMMAC from a ticket for use as a credential removes it 354 from the context of the ticket. In the general case, this could turn 355 it into a bearer token, with all of the associated security 356 implications. Also, the CAMMAC does not itself necessarily contain 357 sufficient information to identify the client principal. Therefore, 358 application protocols that rely on extracted CAMMACs might need to 359 duplicate a substantial portion of the ticket contents and include 360 that duplicated information in the authorization data contained 361 within the CAMMAC. The extent of this duplication would depend on 362 the security properties required by the application protocol. 364 The method for computing the kdc-verifier binds it only to the 365 authorization data contained within the CAMMAC; it does not bind the 366 CAMMAC to any authorization data within the containing ticket but 367 outside the CAMMAC. At least one (non-standard) authorization data 368 type, AD-SIGNEDPATH, attempts to bind to other authorization data in 369 a ticket, and it is very difficult for two such authorization data 370 types to coexist. 372 The kdc-verifier in CAMMAC does not bind the service principal name 373 to the CAMMAC contents, because the service principal name is not 374 part of the EncTicketPart. An entity that has access to the keys of 375 two different service principals can decrypt a ticket for one service 376 and encrypt it in the key of the other service, altering the svc- 377 verifier to match. Both the kdc-verifier and the svc-verifier would 378 still validate, but the KDC never issued this fabricated ticket. The 379 impact of this manipulation is minor if the CAMMAC contents only 380 communicate attributes related to the client. If an application 381 requires an authenticated binding between the service principal name 382 and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC 383 some authorization data element that names the service principal. 385 9. Acknowledgements 387 Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral 388 Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful 389 technical and editorial feedback on earlier versions of this 390 document. Thomas Hardjono helped with the initial editing to split 391 this document from a predecessor document that had a wider scope. 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 428 Red Hat 430 Email: ssorce@redhat.com 431 Tom Yu 432 MIT 434 Email: tlyu@mit.edu