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: April 24, November 8, 2014                        MIT Kerberos Consortium
                                                        October 21, 2013
                                                             May 7, 2014

  Kerberos Authorization Data Container Authenticated by Multiple MACs


   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.

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

   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 April 24, November 8, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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
   ( 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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   3.  Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  AD-CAMMAC . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Assigned numbers  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

1.  Introduction

   This document specifies a new Authorization Data container for
   Kerberos, called AD-CAMMAC (Container Authenticated by Multiple
   MACs), that supersedes AD-KDC-ISSUED.  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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Motivations

   The new AD-CAMMAC Kerberos protocol allows clients to submit arbitrary
   authorization data container specified in this
   document is an improvement upon AD-KDC-ISSUED because it provides
   assurance for a KDC to insert into a Kerberos ticket.  These
   client-requested authorization data allow the KDC client to express
   authorization restrictions that the application service named in the ticket did not
   tamper with the contained authorization data.  By adding MACs
   verifiable by will
   interpret.  With few exceptions, the KDC and trusted services, AD-CAMMAC enables several
   new use cases for can safely copy these
   client-requested authorization data to the Kerberos protocol that AD-KDC-ISSUED does not
   accommodate. issued ticket without
   necessarily inspecting, interpreting, or filtering their contents.

   The existing AD-KDC-ISSUED authorization data container allows specified in RFC 4120
   [RFC4120] is a
   service 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.  However, because the  This capability takes
   advantage of a shared symmetric key for the MAC is known to
   both between the KDC and the service, the KDC cannot generally detect whether
   the service has forged the contents of an AD-KDC-ISSUED container in
   an existing ticket.  The new kdc-verifier MAC in the AD-CAMMAC
   container, because it uses a key known only
   to assure the KDC, allows service that the KDC did not merely copy client-
   requested authorization data to verify the integrity of ticket without inspecting them.

   The AD-KDC-ISSUED container works well for situations where the contents flow
   of that container.

   For example, the new AD-CAMMAC container can protect authorization data when using is from the KDC to the service.  However,
   protocol extensions such as Constrained Delegation (S4U2Proxy
   protocol extension.  This extension allows require that a service present to use a the KDC an "evidence"
   service ticket
   to itself as evidence that it the service received from a user request and
   consequently ask client.  In the
   S4U2Proxy extension, the KDC to issue uses the evidence ticket as the basis
   for issuing a new derivative ticket on behalf of that the user service can then use to perform operations against another service.

   impersonate the KDC had issued a AD-KDC-ISSUED container in client.  The authorization data contained within the S4U2Proxy
   evidence ticket instead constitute a flow of AD-CAMMAC, it would have no way to
   subsequently verify whether the service had tampered with authorization data from the
   contents of that container.
   application service to the KDC.  The properties of the AD-KDC-ISSUED
   container are insufficient for this use case because the service would know
   knows the symmetric key for the
   MAC for 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 in
   within the evidence ticket, 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 element of the CAMMAC is equivalent to
   the ad-checksum element of AD-KDC-ISSUED and allows the service to
   verify the integrity of the contents as it already could
   therefore forge with the AD-
   KDC-ISSUED container.  The kdc-verifier and other-verifiers elements
   are new to AD-CAMMAC and provide its contents. enhanced capabilities.

   The kdc-verifier MAC in element of the AD-CAMMAC container allows a KDC to
   verify the integrity of the contained authorization data without
   having to compute 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, an
   operation that might not always be possible when the that data contains includes
   ephemeral information such as the strength or type of authentication
   method used to obtain the original ticket.

   A lesser-privileged

   The verifiers in the other-verifiers element of the AD-CAMMAC
   container are not required, but can be useful when a lesser-
   privileged service on receives a host may receive an authentication ticket from a client, client and might then ask needs to
   extract the CAMMAC to demonstrate to a higher-privileged service
   ("trusted service") "trusted
   service" on the same host to act that it is legitimately acting on behalf of the client.
   To demonstrate
   that the client has authenticated to it, the lesser-
   privileged service can extract the AD-CAMMAC container from the
   ticket and submit it to the trusted service. client.  The trusted service can
   either ask use a specialized service (not yet specified) on verifier in the KDC other-
   verifiers element to validate the AD-CAMMAC container, or use verify the optional
   additional verifiers (the other-verifiers field) that are part contents of the
   AD-CAMMAC. 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][X.690]. [X.680] and using the ASN.1 Distinguished
   Encoding Rules (DER) [X.690].  For consistency, this specification
   also uses the ASN.1 syntax 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.



      AD-CAMMAC                   ::= SEQUENCE {
            elements              [0] AuthorizationData,
            kdc-verifier          [1] Verifier-MAC,
            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, UInt32 OPTIONAL,
            enctype        [2] Int32, Int32 OPTIONAL,
            mac            [3] Checksum



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

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

      Contains a 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.

      An optional AuthorizationData element  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.

      A Verifier-MAC where the key is that binds of the CAMMAC
      contents local Ticket-Granting
      Service (TGS).  The checksum type is the required checksum type
      for the enctype of the TGS key.  In contrast to the enclosing ticket.  This AuthorizationData element
      has ad-type number TBD, and if it appears other
      Verifier-MAC elements, the KDC computes the MAC in the AD-CAMMAC, it
      MUST be kdc-
      verifier over the first member ASN.1 DER encoding of the elements field EncTicketPart of the AD-CAMMAC.
      The contents
      surrounding ticket, but where the AuthorizationData value in the
      EncTicketPart contains the AuthorizationData value contained in
      the CAMMAC instead of the AD-CAMMAC-BINDING element are a local matter
      for AuthorizationData value that would
      otherwise be present in the KDC implementation.  A KDC can use this element ticket.  This altered Verifier-MAC
      computation binds the kdc-verifier to
      checksum portions of the ticket outside other contents of the CAMMAC, to ensure
      ticket, assuring the KDC that a malicious service has not tampered with them.  This can be useful if
      the KDC implements
      substituted a capability resembling the Windows Constrained
      Delegation (S4U2Proxy) [MS-SFU] extension.

      A Verifier-MAC where the key is the TGS key.  The checksum type is
      the mandatory checksum type for the TGS key. mismatched CAMMAC received from another ticket.

      A Verifier-MAC where the key is the same long-term service key of
      that the service
      for which KDC uses to encrypt the ticket is issued. surrounding ticket.  The checksum
      type is the
      mandatory required checksum type for the long-term key enctype of the service. 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 TGT.

      A sequence of additional verifiers.  In each additional Verifier-
      MAC, the key is the 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' "trusted
      service" verifiers.  Unless otherwise administratively configured,
      the 'trusted service' KDC SHOULD be found determine the "trusted service" principal name by
      replacing the service identifier component of the principal name sname of the svc-verifier
      surrounding ticket with 'host'. "host".  The checksum is computed using a
      long-term key of the identified principal, and the checksum type
      is the mandatory required checksum type for the enctype of that long-term
      the key.  The kvno and enctype SHOULD be specified to disambiguate
      which of the long-term key (which one?) keys of the principal. trusted service is used.  The
      key usage is TBD.

5.  Assigned numbers


6.  IANA Considerations


7.  Security Considerations

   Although authorization data are generally conveyed within the
   encrypted part of a ticket and are thereby protected by the existing
   encryption methods on 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 revalidate it.

   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.

   A KDC that needs to verify the contents  The extent of a CAMMAC in a non-TGS
   ticket MUST ensure that this duplication would depend on
   the CAMMAC in security properties required by the ticket is application protocol.

   The method for computing the same one that kdc-verifier does not bind it inserted into to any
   authorization data within the ticket.  A malicious service could substitute
   legitimate CAMMACs from ticket but outside of the CAMMAC.  At
   least one (non-standard) authorization data type attempts to bind to
   other tickets that it has received (but not
   fabricate completely new CAMMACs) into authorization data in a service ticket.  A CAMMAC by
   itself does not contain sufficient information ticket, and it is very difficult to accomplish this,
   but including an AD-CAMMAC-BINDING element could be sufficient.
   have two such authorization data types coexist.

8.  Open Issues

   Consider making other-verifiers "[3] SEQUENCE (SIZE (1..MAX)) OF

   Allow an optional KDC-verified element, kdc-verifier-unbound, that is
   not bound to make the common case encoding smaller.

   Enclose in AD-IF-RELEVANT? ticket contents?  This would allow a KDC to provide
   the service of verifying an extracted CAMMAC without needing a copy
   of the ticket ciphertext.

9.  Acknowledgements


   Ben Kaduk and Zhanna Tsitkov provided helpful technical and editorial
   feedback on earlier versions of this document.

10.  References
10.1.  Normative References

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
              Encryption for Kerberos 5", RFC 3962, 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
              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:
              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.

10.2.  Informative References

              Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An
              Authentication Service for Open Network Systems. In
              Proceedings of the Winter 1988 Usenix Conference.
              February.", 1988.

   [MS-SFU]   Microsoft, "[MS-SFU]: Kerberos Protocol Extensions:
              Service for User and Constrained Delegation Protocol",
              January 2013,

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Simo Sorce (editor)
   Red Hat


   Tom Yu (editor)
   MIT Kerberos Consortium


   Thomas Hardjono (editor)
   MIT Kerberos Consortium