--- 1/draft-ietf-kitten-cammac-01.txt 2015-03-09 16:15:00.051540385 -0700 +++ 2/draft-ietf-kitten-cammac-02.txt 2015-03-09 16:15:00.075540936 -0700 @@ -1,20 +1,20 @@ Internet Engineering Task Force S. Sorce, Ed. Internet-Draft Red Hat Updates: 4120 (if approved) T. Yu, Ed. Intended status: Standards Track T. Hardjono, Ed. -Expires: July 9, 2015 MIT Kerberos Consortium - January 5, 2015 +Expires: September 10, 2015 MIT Kerberos Consortium + March 9, 2015 Kerberos Authorization Data Container Authenticated by Multiple MACs - draft-ietf-kitten-cammac-01 + draft-ietf-kitten-cammac-02 Abstract This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 9, 2015. + This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,23 +53,23 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document specifies a new Authorization Data container for Kerberos, called the CAMMAC (Container Authenticated by Multiple MACs). The ASN.1 type implementing the CAMMAC concept is the AD- CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type specified in [RFC4120]. This new container allows both the receiving @@ -289,68 +289,90 @@ encryption scheme used for the surrounding ticket, some authorization data requires the additional protection provided by the CAMMAC. Some protocol extensions such as S4U2Proxy allow the KDC to issue a new ticket based on an evidence ticket provided by the service. If the evidence ticket contains authorization data that needs to be preserved in the new ticket, then the KDC MUST verify the kdc- verifier prior to copying the contained authorization data to a new CAMMAC, except in the two situations enumerated below. + In general, when handling TGS-REQs containing CAMMACs, a KDC makes a + policy decision on how to produce the CAMMAC contents of the newly + issued ticket based on properties of the ticket(s) accompanying the + TGS-REQ. This policy decision can involve filtering, transforming, + or verbatim copying of the orginal CAMMAC contents. The following + paragraphs provide some guidance on formulating such policies. + + A KDC SHOULD only make verbatim copies of CAMMAC contents to a new + CAMMAC when it has authenticated the CAMMAC as originating from a + local realm KDC according to one of the criteria below: + + 1. The kdc-verifier is present and validates properly; + + 2. The svc-verifier is present, validates properly, and uses a key + known only to the local realm KDCs; or + + 3. No verifiers are present, the ticket-encrypting key is known only + to local realm KDCs, and all local realm KDCs properly filter out + client-submitted CAMMACs. + + When a KDC makes verbatim copies of CAMMAC contents to a new CAMMAC + without having authenticated the first CAMMAC as originating from a + local realm KDC, it SHOULD NOT apply a kdc-verifier to the new + CAMMAC. One possible exception is when a realm's policy allows a KDC + to make a verbatim copy of CAMMAC contents from a cross-realm TGT + from designated "fully-trusted" remote realms. The local realm KDC + can safely apply a kdc-verifier to a new CAMMAC based on the cross- + realm TGT, because the client realm name in the resulting new ticket + will be that of the remote realm. The presence of a remote client + realm name allows the local realm KDC to identify the originator of + the CAMMAC contents as being a remote realm. + + A KDC MAY omit the kdc-verifier from the CAMMAC when it is not + needed, according to how realm policies will subsequently treat the + containing ticket. An implementation might choose to do this + omission to reduce the size of tickets it issues. Some examples of + when such an omission is safe are: + + 1. For a local realm TGT, if all local realm KDCs correctly filter + out client-submitted CAMMACs, the local realm origin criteria + listed above allow omission of the kdc-verifier. + + 2. An application service might not use the S4U2Proxy extension, or + the realm policy might disallow the use of S4U2Proxy by that + service. In such situations where there is no flow of + authorization data from the service to the KDC, the application + service could modify the CAMMAC contents, but such modifications + would have no effect on other services. Because of the lack of + security impact, the KDCM AY omit the kdc-verifier from a CAMMAC + contained in a ticket for that service. + Extracting a CAMMAC from a ticket for use as a credential removes it from the context of the ticket. In the general case, this could turn it into a bearer token, with all of the associated security implications. Also, the CAMMAC does not itself necessarily contain sufficient information to identify the client principal. Therefore, application protocols that rely on extracted CAMMACs might need to duplicate a substantial portion of the ticket contents and include that duplicated information in the authorization data contained within the CAMMAC. The extent of this duplication would depend on the security properties required by the application protocol. The method for computing the kdc-verifier binds it only to the authorization data contained within the CAMMAC; it does not bind the CAMMAC to any authorization data within the containing ticket but outside the CAMMAC. At least one (non-standard) authorization data type, AD-SIGNEDPATH, attempts to bind to other authorization data in a ticket, and it is very difficult for two such authorization data types to coexist. - To minimize ticket size when embedding CAMMACs in Kerberos tickets, a - KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed. - In this situation, the KDC cannot always determine whether the CAMMAC - contents are intact. The KDC MUST NOT create a new CAMMAC from an - existing one unless the existing CAMMAC has a valid kdc-verifier, - with two exceptions: - - 1. Only KDCs for the local realm have knowledge of the local TGS - key, so the outer encryption of a local TGT is sufficient to - protect the CAMMAC of a local TGT from tampering, assuming that - all of the KDCs in the local realm consistently filter out CAMMAC - authorization data submitted by clients. The KDC MAY create a - new CAMMAC from an existing CAMMAC lacking a kdc-verifier if that - CAMMAC is contained within a local TGT and all of the local realm - KDCs are configured to filter out CAMMAC authorization data - submitted by clients. - - 2. An application service might not use the S4U2Proxy extension, or - the realm policy might disallow the use of S4U2Proxy by that - service. In such situations where there is no flow of - authorization data from the service to the KDC, the application - service could modify the CAMMAC contents, but such modifications - would have no effect on other services. Because of the lack of - security impact, the KDC MAY create a new CAMMAC from an existing - CAMMAC lacking a kdc-verifier if it is inserting the new CAMMAC - into a service ticket for the same service principal as the - ticket that contained the existing CAMMAC, but MUST NOT place a - kdc-verifier in the new CAMMAC. - The kdc-verifier in CAMMAC does not bind the service principal name to the CAMMAC contents, because the service principal name is not part of the EncTicketPart. An entity that has access to the keys of two different service principals can decrypt a ticket for one service and encrypt it in the key of the other service, altering the svc- verifier to match. Both the kdc-verifier and the svc-verifier would still validate, but the KDC never issued this fabricated ticket. The impact of this manipulation is minor if the CAMMAC contents only communicate attributes related to the client. If an application requires an authenticated binding between the service principal name