Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-kitten-cammac-01

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 12, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Motivations
• 4. Encoding
• 5. Usage
• 6. Assigned numbers
• 7. IANA Considerations
• 8. Security Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

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 application service and the Key Distribution Center (KDC) itself to verify the authenticity of the contained authorization data. The AD-CAMMAC container can also include additional verifiers that "trusted services" can use to verify the contained authorization data.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Motivations

The Kerberos protocol allows clients to submit arbitrary authorization data for a KDC to insert into a Kerberos ticket. These client-requested authorization data allow the client to express authorization restrictions that the application service will interpret. With few exceptions, the KDC can safely copy these client-requested authorization data to the issued ticket without necessarily inspecting, interpreting, or filtering their contents.

The AD-KDC-ISSUED authorization data container specified in RFC 4120 [RFC4120] is a means for KDCs to include positive or permissive (rather than restrictive) authorization data in service tickets in a way that the service named in a ticket can verify that the KDC has issued the contained authorization data. This capability takes advantage of a shared symmetric key between the KDC and the service to assure the service that the KDC did not merely copy client-requested authorization data to the ticket without inspecting them.

The AD-KDC-ISSUED container works well for situations where the flow of authorization data is from the KDC to the service. However, protocol extensions such as Constrained Delegation (S4U2Proxy [MS-SFU]) require that a service present to the KDC a service ticket that the KDC previously issued, as evidence that the service is authorized to impersonate the client principal named in that ticket. In the S4U2Proxy extension, the KDC uses the evidence ticket as the basis for issuing a derivative ticket that the service can then use to impersonate the client. The authorization data contained within the evidence ticket constitute a flow of authorization data from the application service to the KDC. The properties of the AD-KDC-ISSUED container are insufficient for this use case because the service knows the symmetric key for the checksum in the AD-KDC-ISSUED container. Therefore, the KDC has no way to detect whether the service has tampered with the contents of the AD-KDC-ISSUED container within the evidence ticket.

The new AD-CAMMAC authorization data container specified in this document improves upon AD-KDC-ISSUED by including additional verifier elements. The svc-verifier (service verifier) element of the AD-CAMMAC has the same functional and security properties as the ad-checksum element of AD-KDC-ISSUED; the svc-verifier allows the service to verify the integrity of the AD-CAMMAC contents as it already could with the AD-KDC-ISSUED container. The kdc-verifier and other-verifiers elements are new to AD-CAMMAC and provide its enhanced capabilities.

The kdc-verifier element of the AD-CAMMAC container allows a KDC to verify the integrity of authorization data that it previously inserted into a ticket, by using a key that only the KDC knows. The KDC thus avoids recomputing all of the authorization data for the issued ticket; this recomputation might not always be possible when that data includes ephemeral information such as the strength or type of authentication method used to obtain the original ticket.

The verifiers in the other-verifiers element of the AD-CAMMAC container are not required, but can be useful when a lesser-privileged service receives a ticket from a client and needs to extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted service" on the same host that it is legitimately acting on behalf of that client. The trusted service can use a verifier in the other-verifiers element to validate the contents of the AD-CAMMAC without further communication with the KDC.

4. Encoding

The Kerberos protocol is defined in [RFC4120] using Abstract Syntax Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished Encoding Rules (DER) [X.690]. For consistency, this specification also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data of the AD-CAMMAC authorization data element is the ASN.1 DER encoding of the AD-CAMMAC ASN.1 type specified below.

   KerberosV5CAMMAC {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4) cammac(7)
   } DEFINITIONS EXPLICIT TAGS ::= BEGIN

   IMPORTS
         AuthorizationData, PrincipalName, Checksum, UInt32, Int32
           FROM KerberosV5Spec2 { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) kerberosV5(2)
             modules(4) krb5spec2(2) };
             -- as defined in RFC 4120.

   AD-CAMMAC                   ::= SEQUENCE {
         elements              [0] AuthorizationData,
         kdc-verifier          [1] Verifier-MAC OPTIONAL,
         svc-verifier          [2] Verifier-MAC OPTIONAL,
         other-verifiers       [3] SEQUENCE (SIZE (1..MAX))
                                   OF Verifier OPTIONAL
   }

   Verifier             ::= CHOICE {
         mac            Verifier-MAC,
         ...
   }

   Verifier-MAC         ::= SEQUENCE {
         identifier     [0] PrincipalName OPTIONAL,
         kvno           [1] UInt32 OPTIONAL,
         enctype        [2] Int32 OPTIONAL,
         mac            [3] Checksum
   }

   END

elements:

A sequence of authorization data elements issued by the KDC. These elements are the authorization data that the verifier fields authenticate.

Verifier:

A CHOICE type that currently contains only one alternative: Verifier-MAC. Future extensions might add support for public-key signatures.

Verifier-MAC:

Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the ASN.1 DER encoding of the AuthorizationData value in the elements field of the AD-CAMMAC. The identifier, kvno, and enctype fields help the recipient locate the key required for verifying the MAC. For the kdc-verifier and the svc-verifier, the identifier, kvno and enctype fields are often obvious from context and MAY be omitted. For the kdc-verifier, the MAC is computed differently than for the svc-verifier and the other-verifiers, as described later. The key usage number for computing the MAC (Checksum) is 64.

kdc-verifier:

A Verifier-MAC where the key is a long-term key of the local Ticket-Granting Service (TGS). The checksum type is the required checksum type for the enctype of the TGS key. In contrast to the other Verifier-MAC elements, the KDC computes the MAC in the kdc-verifier over the ASN.1 DER encoding of the EncTicketPart of the surrounding ticket, but where the AuthorizationData value in the EncTicketPart contains the AuthorizationData value contained in the AD-CAMMAC instead of the AuthorizationData value that would otherwise be present in the ticket. This altered Verifier-MAC computation binds the kdc-verifier to the other contents of the ticket, assuring the KDC that a malicious service has not substituted a mismatched AD-CAMMAC received from another ticket.

svc-verifier:

A Verifier-MAC where the key is the same long-term service key that the KDC uses to encrypt the surrounding ticket. The checksum type is the required checksum type for the enctype of the service key used to encrypt the ticket. This field MUST be present if the service principal of the ticket is not the local TGS, including when the ticket is a cross-realm Ticket-Granting Ticket (TGT).

other-verifiers:

A sequence of additional verifiers. In each additional Verifier-MAC, the key is a long-term key of the principal name specified in the identifier field. The PrincipalName MUST be present and be a valid principal in the realm. KDCs MAY add one or more "trusted service" verifiers. Unless otherwise administratively configured, the KDC SHOULD determine the "trusted service" principal name by replacing the service identifier component of the sname of the surrounding ticket with "host". The checksum is computed using a long-term key of the identified principal, and the checksum type is the required checksum type for the enctype of that long-term key. The kvno and enctype SHOULD be specified to disambiguate which of the long-term keys of the trusted service is used.

5. Usage

Application servers and KDCs MAY ignore the AD-CAMMAC container and the authorization data elements it contains. For compatibility with older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC knows that the application server is likely to recognize it.

6. Assigned numbers

RFC 4120 is updated in the following ways:

• The ad-type number 96 is assigned for AD-CAMMAC, updating the table in Section 7.5.4 of [RFC4120].
• The table in Section 5.2.6 of [RFC4120] is updated to map the ad-type 96 to "DER encoding of AD-CAMMAC".
• The key usage number 64 is assigned for the Verifier-MAC checksum, updating the table in Section 7.5.1 of [RFC4120].

7. IANA Considerations

[ RFC Editor: please remove this section prior to publication. ]

There are no IANA considerations in this document. Any numbers 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.

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 and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC some authorization data element that names the service principal.

9. Acknowledgements

Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful technical and editorial feedback on earlier versions of this document.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses