Internet DRAFT - draft-ietf-kitten-cammac
draft-ietf-kitten-cammac
Internet Engineering Task Force S. Sorce
Internet-Draft Red Hat
Updates: 4120 (if approved) T. Yu
Intended status: Standards Track MIT
Expires: May 4, 2016 November 1, 2015
Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-kitten-cammac-04
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 May 4, 2016.
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
Sorce & Yu Expires May 4, 2016 [Page 1]
Internet-Draft Container Authenticated by Multiple MACs November 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . 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
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.
Sorce & Yu Expires May 4, 2016 [Page 2]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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
Sorce & Yu Expires May 4, 2016 [Page 3]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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
Sorce & Yu Expires May 4, 2016 [Page 4]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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
Sorce & Yu Expires May 4, 2016 [Page 5]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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:
o The ad-type number 96 is assigned for AD-CAMMAC, updating the
table in Section 7.5.4 of [RFC4120].
o The table in Section 5.2.6 of [RFC4120] is updated to map the ad-
type 96 to "DER encoding of AD-CAMMAC".
o 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.
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
Sorce & Yu Expires May 4, 2016 [Page 6]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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 verifies a CAMMAC as originating from a local realm KDC when at
least one of following the criteria is true:
1. The KDC successfully verifies the kdc-verifier; 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. (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.)
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
Sorce & Yu Expires May 4, 2016 [Page 7]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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 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
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.
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.
Sorce & Yu Expires May 4, 2016 [Page 8]
Internet-Draft Container Authenticated by Multiple MACs November 2015
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. Thomas Hardjono helped with the initial editing to split
this document from a predecessor document that had a wider scope.
10. References
10.1. Normative References
[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] 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] 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)", 2008.
10.2. Informative References
[MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions:
Service for User and Constrained Delegation Protocol",
January 2013,
<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
Authors' Addresses
Simo Sorce
Red Hat
Email: ssorce@redhat.com
Sorce & Yu Expires May 4, 2016 [Page 9]
Internet-Draft Container Authenticated by Multiple MACs November 2015
Tom Yu
MIT
Email: tlyu@mit.edu
Sorce & Yu Expires May 4, 2016 [Page 10]
