draft-ietf-krb-wg-cammac-09.txt   draft-ietf-krb-wg-cammac-10.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: March 9, 2015 MIT Kerberos Consortium Expires: March 14, 2015 MIT Kerberos Consortium
September 5, 2014 September 10, 2014
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-krb-wg-cammac-09 draft-ietf-krb-wg-cammac-10
Abstract Abstract
Abstract: This document specifies a Kerberos Authorization Data Abstract: This document specifies a Kerberos Authorization Data
container that supersedes AD-KDC-ISSUED. It allows for multiple container that supersedes AD-KDC-ISSUED. It allows for multiple
Message Authentication Codes (MACs) or signatures to authenticate the Message Authentication Codes (MACs) or signatures to authenticate the
contained Authorization Data elements. contained Authorization Data elements.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 9, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
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 . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This document specifies a new Authorization Data container for This document specifies a new Authorization Data container for
Kerberos, called AD-CAMMAC (Container Authenticated by Multiple Kerberos, called AD-CAMMAC (Container Authenticated by Multiple
MACs), that supersedes AD-KDC-ISSUED. This new container allows both MACs), that supersedes AD-KDC-ISSUED. This new container allows both
the receiving application service and the Key Distribution Center the receiving application service and the Key Distribution Center
(KDC) itself to verify the authenticity of the contained (KDC) itself to verify the authenticity of the contained
skipping to change at page 7, line 9 skipping to change at page 7, line 9
the security properties required by the application protocol. the security properties required by the application protocol.
The method for computing the kdc-verifier does not bind it to any The method for computing the kdc-verifier does not bind it to any
authorization data within the ticket but outside of the CAMMAC. At authorization data within the ticket but outside of the CAMMAC. At
least one (non-standard) authorization data type, AD-SIGNEDPATH, least one (non-standard) authorization data type, AD-SIGNEDPATH,
attempts to bind to other authorization data in a ticket, and it is attempts to bind to other authorization data in a ticket, and it is
very difficult for two such authorization data types to coexist. very difficult for two such authorization data types to coexist.
To minimize ticket size when embedding CAMMACs in Kerberos tickets, a 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. KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed.
In this situation, the KDC cannot always determine whether the CAMAMC In this situation, the KDC cannot always determine whether the CAMMAC
contents are intact. The KDC MUST NOT create a new CAMMAC from an contents are intact. The KDC MUST NOT create a new CAMMAC from an
existing one unless the existing CAMMAC has a valid kdc-verifier, existing one unless the existing CAMMAC has a valid kdc-verifier,
with two exceptions. with two exceptions.
Only KDCs for the local realm have knowledge of the local TGS key, so 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 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 CAMMAC of a local TGT from tampering, assuming that all of the KDCs
in the local realm consistently filter out CAMMAC authorization data in the local realm consistently filter out CAMMAC authorization data
submitted by clients. The KDC MAY create a new CAMMAC from an submitted by clients. The KDC MAY create a new CAMMAC from an
existing CAMMAC lacking a kdc-verifier if that CAMMAC is contained 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 within a local TGT and all of the local realm KDCs are configured to
filter out CAMMAC authorization data submitted by clients. filter out CAMMAC authorization data submitted by clients.
An application service might be use the S4U2Proxy extension, or the An application service might not use the S4U2Proxy extension, or the
realm policy might disallow the use of S4U2Proxy by that service. In realm policy might disallow the use of S4U2Proxy by that service. In
this situation, the application service could modify the CAMMAC this situation, the application service could modify the CAMMAC
contents, but such modifications would have no effect on other contents, but such modifications would have no effect on other
services. The KDC MAY create a new CAMMAC from an existing CAMMAC services. The KDC MAY create a new CAMMAC from an existing CAMMAC
lacking a kdc-verifier if it is inserting the new CAMMAC into a lacking a kdc-verifier if it is inserting the new CAMMAC into a
service ticket for the same service principal as the ticket that service ticket for the same service principal as the ticket that
contained the existing CAMMAC, and if all of the realm's KDCs are contained the existing CAMMAC, but MUST NOT place a kdc-verifier in
configured to reject S4U2Proxy requests made by that service the new CAMMAC.
principal.
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 9. Acknowledgements
Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Zhanna Tsitkov, and Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Zhanna Tsitkov, and
Kai Zheng provided helpful technical and editorial feedback on Kai Zheng provided helpful technical and editorial feedback on
earlier versions of this document. earlier versions of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
 End of changes. 7 change blocks. 
11 lines changed or deleted 23 lines changed or added

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