draft-ietf-krb-wg-cammac-10.txt   draft-ietf-krb-wg-cammac-11.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 14, 2015 MIT Kerberos Consortium Expires: April 6, 2015 MIT Kerberos Consortium
September 10, 2014 October 3, 2014
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-krb-wg-cammac-10 draft-ietf-krb-wg-cammac-11
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. This document updates RFC
4120.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 14, 2015. This Internet-Draft will expire on April 6, 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 5, line 5 skipping to change at page 5, line 5
These elements are the authorization data that the verifier fields These elements are the authorization data that the verifier fields
authenticate. authenticate.
Verifier: Verifier:
A CHOICE type that currently contains only one alternative: A CHOICE type that currently contains only one alternative:
Verifier-MAC. Future extensions might add support for public-key Verifier-MAC. Future extensions might add support for public-key
signatures. signatures.
Verifier-MAC: Verifier-MAC:
Contains a MAC computed over the ASN.1 DER encoding of the Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the
AuthorizationData value in the elements field of the AD-CAMMAC. ASN.1 DER encoding of the AuthorizationData value in the elements
The identifier, kvno, and enctype fields help the recipient locate field of the AD-CAMMAC. The identifier, kvno, and enctype fields
the key required for verifying the MAC. For the kdc-verifier and help the recipient locate the key required for verifying the MAC.
the svc-verifier, the identifier, kvno and enctype fields are For the kdc-verifier and the svc-verifier, the identifier, kvno
often obvious from context and MAY be omitted. For the kdc- and enctype fields are often obvious from context and MAY be
verifier, the MAC is computed differently than for the svc- omitted. For the kdc-verifier, the MAC is computed differently
verifier and the other-verifiers, as described later. The key than for the svc-verifier and the other-verifiers, as described
usage for computing the MAC (Checksum) is 64. later. The key usage for computing the MAC (Checksum) is 64.
kdc-verifier: kdc-verifier:
A Verifier-MAC where the key is a long-term key of the local A Verifier-MAC where the key is a long-term key of the local
Ticket-Granting Service (TGS). The checksum type is the required Ticket-Granting Service (TGS). The checksum type is the required
checksum type for the enctype of the TGS key. In contrast to the 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- other Verifier-MAC elements, the KDC computes the MAC in the kdc-
verifier over the ASN.1 DER encoding of the EncTicketPart of the verifier over the ASN.1 DER encoding of the EncTicketPart of the
surrounding ticket, but where the AuthorizationData value in the surrounding ticket, but where the AuthorizationData value in the
EncTicketPart contains the AuthorizationData value contained in EncTicketPart contains the AuthorizationData value contained in
the CAMMAC instead of the AuthorizationData value that would the CAMMAC instead of the AuthorizationData value that would
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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 not 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 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 contents, but such modifications would have no effect on other
services. The KDC MAY create a new CAMMAC from an existing CAMMAC services. Because of the lack of security impact, the KDC MAY create
lacking a kdc-verifier if it is inserting the new CAMMAC into a a new CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is
service ticket for the same service principal as the ticket that inserting the new CAMMAC into a service ticket for the same service
contained the existing CAMMAC, but MUST NOT place a kdc-verifier in principal as the ticket that contained the existing CAMMAC, but MUST
the new CAMMAC. 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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
8824-1:2008)", 2008. 8824-1:2008)", 2008.
[X.690] ISO, , "Information technology -- ASN.1 encoding rules: [X.690] ISO, , "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)", 1997.
10.2. Informative References 10.2. Informative References
[MIT-Athena]
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: [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>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Authors' Addresses Authors' Addresses
Simo Sorce (editor) Simo Sorce (editor)
Red Hat Red Hat
Email: ssorce@redhat.com Email: ssorce@redhat.com
Tom Yu (editor) Tom Yu (editor)
MIT Kerberos Consortium MIT Kerberos Consortium
Email: tlyu@mit.edu Email: tlyu@mit.edu
Thomas Hardjono (editor) Thomas Hardjono (editor)
MIT Kerberos Consortium MIT Kerberos Consortium
Email: hardjono@mit.edu Email: hardjono@mit.edu
 End of changes. 11 change blocks. 
30 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/