--- 1/draft-ietf-kitten-cammac-02.txt 2015-06-25 12:14:54.189498522 -0700 +++ 2/draft-ietf-kitten-cammac-03.txt 2015-06-25 12:14:54.213499092 -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: September 10, 2015 MIT Kerberos Consortium - March 9, 2015 +Expires: December 27, 2015 MIT Kerberos Consortium + June 25, 2015 Kerberos Authorization Data Container Authenticated by Multiple MACs - draft-ietf-kitten-cammac-02 + draft-ietf-kitten-cammac-03 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 September 10, 2015. + This Internet-Draft will expire on December 27, 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 @@ -277,82 +277,86 @@ assigned in this document are not in IANA-controlled number spaces. 8. Security Considerations The CAMMAC provides data origin authentication for authorization data contained in it, attesting that it originated from the KDC. This section describes the precautions required to maintain the integrity of that data origin authentication through various information flows involving a Kerberos ticket containing a CAMMAC. - Although authorization data are generally conveyed within the - encrypted part of a ticket and are thereby protected by the existing - 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. + When handling a TGS-REQ containing a CAMMAC, 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 original 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: + A KDC verifies a CAMMAC as originating from a local realm KDC when at + least one of following the criteria is true: - 1. The kdc-verifier is present and validates properly; + 1. The KDC successfully verifies the kdc-verifier; or - 2. The svc-verifier is present, validates properly, and uses a key - known only to the local realm KDCs; or + 2. The KDC successfully verifies the svc-verifier, and the svc- + verifier 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. + client-submitted CAMMACs. (This can require particular caution + in a realm that has KDCs with mixed CAMMAC support, as might + happen when incrementally upgrading KDCs in a realm to support + CAMMAC.) - 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 CAMMAC that originates from a local realm KDC might contain + information that originates from elsewhere. Originating from a local + realm KDC means that a local realm KDC attests that the CAMMAC + contents conform to the local realm's policy, regardless of the + ultimate origin of the information in the CAMMAC (which could be a + remote realm in the case of a CAMMAC contained in a cross-realm TGT). + + Local policy determines when a KDC can apply a kdc-verifier to a + CAMMAC (or otherwise creates a CAMMAC that satisfies the local origin + criteria listed above). Semantically, a CAMMAC that a KDC verifies + as originating from a local realm KDC attests that the CAMMAC + contents conformed to local policy at the time of creation of the + CAMMAC. Such a local policy can include allowing verbatim copying of + CAMMAC contents from cross-realm TGTs from designated remote realms + and applying a kdc-verifier to the new CAMMAC. + + Usually, when a KDC verifies a CAMMAC as originating from a local + realm KDC, the KDC can assume that the CAMMAC contents continue to + conform to the local realm's policies. It is generally safe for a + KDC to make verbatim copies of the contents of such a CAMMAC into a + new CAMMAC when handling a TGS-REQ. Particularly strict + implementations might conduct additional policy checks on the + contents of a CAMMAC originating from a local realm KDC if the local + realm's policy materially changes during the life of the CAMMAC. 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. + security impact to other application services, the KDC MAY 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 @@ -393,30 +397,30 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. - [X.680] ISO, , "Information technology -- Abstract Syntax Notation + [X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation -- ITU-T Recommendation X.680 (ISO/IEC International Standard 8824-1:2008)", 2008. - [X.690] ISO, , "Information technology -- ASN.1 encoding rules: + [X.690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) -- ITU-T Recommendation X.690 (ISO/IEC International - Standard 8825-1:2008)", 1997. + Standard 8825-1:2008)", 2008. 10.2. Informative References [MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol", January 2013, . Authors' Addresses