draft-ietf-kitten-cammac-01.txt   draft-ietf-kitten-cammac-02.txt 
Internet Engineering Task Force S. Sorce, Ed. Internet Engineering Task Force S. Sorce, Ed.
Internet-Draft Red Hat Internet-Draft Red Hat
Updates: 4120 (if approved) T. Yu, Ed. Updates: 4120 (if approved) T. Yu, Ed.
Intended status: Standards Track T. Hardjono, Ed. Intended status: Standards Track T. Hardjono, Ed.
Expires: July 9, 2015 MIT Kerberos Consortium Expires: September 10, 2015 MIT Kerberos Consortium
January 5, 2015 March 9, 2015
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-kitten-cammac-01 draft-ietf-kitten-cammac-02
Abstract Abstract
This document specifies a Kerberos Authorization Data container that This document specifies a Kerberos Authorization Data container that
supersedes AD-KDC-ISSUED. It allows for multiple Message supersedes AD-KDC-ISSUED. It allows for multiple Message
Authentication Codes (MACs) or signatures to authenticate the Authentication Codes (MACs) or signatures to authenticate the
contained Authorization Data elements. The multiple MACs are needed contained Authorization Data elements. The multiple MACs are needed
to mitigate shortcomings in the existing AD-KDC-ISSUED container. to mitigate shortcomings in the existing AD-KDC-ISSUED container.
This document updates RFC 4120. This document updates RFC 4120.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document specifies a new Authorization Data container for This document specifies a new Authorization Data container for
Kerberos, called the CAMMAC (Container Authenticated by Multiple Kerberos, called the CAMMAC (Container Authenticated by Multiple
MACs). The ASN.1 type implementing the CAMMAC concept is the AD- MACs). The ASN.1 type implementing the CAMMAC concept is the AD-
CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type
specified in [RFC4120]. This new container allows both the receiving specified in [RFC4120]. This new container allows both the receiving
skipping to change at page 7, line 14 skipping to change at page 7, line 14
encryption scheme used for the surrounding ticket, some authorization encryption scheme used for the surrounding ticket, some authorization
data requires the additional protection provided by the CAMMAC. data requires the additional protection provided by the CAMMAC.
Some protocol extensions such as S4U2Proxy allow the KDC to issue a Some protocol extensions such as S4U2Proxy allow the KDC to issue a
new ticket based on an evidence ticket provided by the service. If new ticket based on an evidence ticket provided by the service. If
the evidence ticket contains authorization data that needs to be the evidence ticket contains authorization data that needs to be
preserved in the new ticket, then the KDC MUST verify the kdc- preserved in the new ticket, then the KDC MUST verify the kdc-
verifier prior to copying the contained authorization data to a new verifier prior to copying the contained authorization data to a new
CAMMAC, except in the two situations enumerated below. 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 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 from the context of the ticket. In the general case, this could turn
it into a bearer token, with all of the associated security it into a bearer token, with all of the associated security
implications. Also, the CAMMAC does not itself necessarily contain implications. Also, the CAMMAC does not itself necessarily contain
sufficient information to identify the client principal. Therefore, sufficient information to identify the client principal. Therefore,
application protocols that rely on extracted CAMMACs might need to application protocols that rely on extracted CAMMACs might need to
duplicate a substantial portion of the ticket contents and include duplicate a substantial portion of the ticket contents and include
that duplicated information in the authorization data contained that duplicated information in the authorization data contained
within the CAMMAC. The extent of this duplication would depend on within the CAMMAC. The extent of this duplication would depend on
the security properties required by the application protocol. the security properties required by the application protocol.
The method for computing the kdc-verifier binds it only to the The method for computing the kdc-verifier binds it only to the
authorization data contained within the CAMMAC; it does not bind the authorization data contained within the CAMMAC; it does not bind the
CAMMAC to any authorization data within the containing ticket but CAMMAC to any authorization data within the containing ticket but
outside the CAMMAC. At least one (non-standard) authorization data outside the CAMMAC. At least one (non-standard) authorization data
type, AD-SIGNEDPATH, attempts to bind to other authorization data in type, AD-SIGNEDPATH, attempts to bind to other authorization data in
a ticket, and it is very difficult for two such authorization data a ticket, and it is very difficult for two such authorization data
types to coexist. 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 The kdc-verifier in CAMMAC does not bind the service principal name
to the CAMMAC contents, because the service principal name is not to the CAMMAC contents, because the service principal name is not
part of the EncTicketPart. An entity that has access to the keys of part of the EncTicketPart. An entity that has access to the keys of
two different service principals can decrypt a ticket for one service two different service principals can decrypt a ticket for one service
and encrypt it in the key of the other service, altering the svc- 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 verifier to match. Both the kdc-verifier and the svc-verifier would
still validate, but the KDC never issued this fabricated ticket. The still validate, but the KDC never issued this fabricated ticket. The
impact of this manipulation is minor if the CAMMAC contents only impact of this manipulation is minor if the CAMMAC contents only
communicate attributes related to the client. If an application communicate attributes related to the client. If an application
requires an authenticated binding between the service principal name requires an authenticated binding between the service principal name
 End of changes. 6 change blocks. 
36 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/