draft-ietf-kitten-cammac-02.txt   draft-ietf-kitten-cammac-03.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: September 10, 2015 MIT Kerberos Consortium Expires: December 27, 2015 MIT Kerberos Consortium
March 9, 2015 June 25, 2015
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-kitten-cammac-02 draft-ietf-kitten-cammac-03
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 September 10, 2015. This Internet-Draft will expire on December 27, 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 6, line 50 skipping to change at page 6, line 50
assigned in this document are not in IANA-controlled number spaces. assigned in this document are not in IANA-controlled number spaces.
8. Security Considerations 8. Security Considerations
The CAMMAC provides data origin authentication for authorization data The CAMMAC provides data origin authentication for authorization data
contained in it, attesting that it originated from the KDC. This contained in it, attesting that it originated from the KDC. This
section describes the precautions required to maintain the integrity section describes the precautions required to maintain the integrity
of that data origin authentication through various information flows of that data origin authentication through various information flows
involving a Kerberos ticket containing a CAMMAC. involving a Kerberos ticket containing a CAMMAC.
Although authorization data are generally conveyed within the When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy
encrypted part of a ticket and are thereby protected by the existing decision on how to produce the CAMMAC contents of the newly issued
encryption scheme used for the surrounding ticket, some authorization ticket based on properties of the ticket(s) accompanying the TGS-REQ.
data requires the additional protection provided by the CAMMAC. This policy decision can involve filtering, transforming, or verbatim
copying of the original CAMMAC contents. The following paragraphs
Some protocol extensions such as S4U2Proxy allow the KDC to issue a provide some guidance on formulating such policies.
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.
A KDC SHOULD only make verbatim copies of CAMMAC contents to a new A KDC verifies a CAMMAC as originating from a local realm KDC when at
CAMMAC when it has authenticated the CAMMAC as originating from a least one of following the criteria is true:
local realm KDC according to one of the criteria below:
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 2. The KDC successfully verifies the svc-verifier, and the svc-
known only to the local realm KDCs; or verifier uses a key known only to the local realm KDCs; or
3. No verifiers are present, the ticket-encrypting key is known only 3. No verifiers are present, the ticket-encrypting key is known only
to local realm KDCs, and all local realm KDCs properly filter out 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 A CAMMAC that originates from a local realm KDC might contain
without having authenticated the first CAMMAC as originating from a information that originates from elsewhere. Originating from a local
local realm KDC, it SHOULD NOT apply a kdc-verifier to the new realm KDC means that a local realm KDC attests that the CAMMAC
CAMMAC. One possible exception is when a realm's policy allows a KDC contents conform to the local realm's policy, regardless of the
to make a verbatim copy of CAMMAC contents from a cross-realm TGT ultimate origin of the information in the CAMMAC (which could be a
from designated "fully-trusted" remote realms. The local realm KDC remote realm in the case of a CAMMAC contained in a cross-realm TGT).
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 Local policy determines when a KDC can apply a kdc-verifier to a
will be that of the remote realm. The presence of a remote client CAMMAC (or otherwise creates a CAMMAC that satisfies the local origin
realm name allows the local realm KDC to identify the originator of criteria listed above). Semantically, a CAMMAC that a KDC verifies
the CAMMAC contents as being a remote realm. 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 A KDC MAY omit the kdc-verifier from the CAMMAC when it is not
needed, according to how realm policies will subsequently treat the needed, according to how realm policies will subsequently treat the
containing ticket. An implementation might choose to do this containing ticket. An implementation might choose to do this
omission to reduce the size of tickets it issues. Some examples of omission to reduce the size of tickets it issues. Some examples of
when such an omission is safe are: when such an omission is safe are:
1. For a local realm TGT, if all local realm KDCs correctly filter 1. For a local realm TGT, if all local realm KDCs correctly filter
out client-submitted CAMMACs, the local realm origin criteria out client-submitted CAMMACs, the local realm origin criteria
listed above allow omission of the kdc-verifier. listed above allow omission of the kdc-verifier.
2. An application service might not use the S4U2Proxy extension, or 2. An application service might not use the S4U2Proxy extension, or
the realm policy might disallow the use of S4U2Proxy by that the realm policy might disallow the use of S4U2Proxy by that
service. In such situations where there is no flow of service. In such situations where there is no flow of
authorization data from the service to the KDC, the application authorization data from the service to the KDC, the application
service could modify the CAMMAC contents, but such modifications service could modify the CAMMAC contents, but such modifications
would have no effect on other services. Because of the lack of would have no effect on other services. Because of the lack of
security impact, the KDCM AY omit the kdc-verifier from a CAMMAC security impact to other application services, the KDC MAY omit
contained in a ticket for that service. 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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. 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 One (ASN.1): Specification of basic notation -- ITU-T
Recommendation X.680 (ISO/IEC International Standard Recommendation X.680 (ISO/IEC International Standard
8824-1:2008)", 2008. 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 Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER) -- ITU-T Recommendation X.690 (ISO/IEC International (DER) -- ITU-T Recommendation X.690 (ISO/IEC International
Standard 8825-1:2008)", 1997. Standard 8825-1:2008)", 2008.
10.2. Informative References 10.2. Informative References
[MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: [MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions:
Service for User and Constrained Delegation Protocol", Service for User and Constrained Delegation Protocol",
January 2013, January 2013,
<http://msdn.microsoft.com/en-us/library/cc246071.aspx>. <http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
Authors' Addresses Authors' Addresses
 End of changes. 13 change blocks. 
45 lines changed or deleted 49 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/