draft-ietf-krb-wg-cammac-07.txt   draft-ietf-krb-wg-cammac-08.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: November 8, 2014 MIT Kerberos Consortium Expires: January 1, 2015 MIT Kerberos Consortium
May 7, 2014 June 30, 2014
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-krb-wg-cammac-07 draft-ietf-krb-wg-cammac-08
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 November 8, 2014. This Internet-Draft will expire on January 1, 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. AD-CAMMAC . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. AD-CAMMAC . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 6 5. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 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 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
authorization data. The AD-CAMMAC container can also include authorization data. The AD-CAMMAC container can also include
additional verifiers that "trusted services" can use to verify the additional verifiers that "trusted services" can use to verify the
skipping to change at page 3, line 44 skipping to change at page 3, line 44
(rather than restrictive) authorization data in service tickets in a (rather than restrictive) authorization data in service tickets in a
way that the service named in a ticket can verify that the KDC has way that the service named in a ticket can verify that the KDC has
issued the contained authorization data. This capability takes issued the contained authorization data. This capability takes
advantage of a shared symmetric key between the KDC and the service advantage of a shared symmetric key between the KDC and the service
to assure the service that the KDC did not merely copy client- to assure the service that the KDC did not merely copy client-
requested authorization data to the ticket without inspecting them. requested authorization data to the ticket without inspecting them.
The AD-KDC-ISSUED container works well for situations where the flow The AD-KDC-ISSUED container works well for situations where the flow
of authorization data is from the KDC to the service. However, of authorization data is from the KDC to the service. However,
protocol extensions such as Constrained Delegation (S4U2Proxy protocol extensions such as Constrained Delegation (S4U2Proxy
[MS-SFU]) require that a service present to the KDC an "evidence" [MS-SFU]) require that a service present to the KDC a service ticket
service ticket that the service received from a client. In the that the service received from a client, as evidence that the client
S4U2Proxy extension, the KDC uses the evidence ticket as the basis authenticated to the service. In the S4U2Proxy extension, the KDC
for issuing a derivative ticket that the service can then use to uses the evidence ticket as the basis for issuing a derivative ticket
impersonate the client. The authorization data contained within the that the service can then use to impersonate the client. The
evidence ticket constitute a flow of authorization data from the authorization data contained within the evidence ticket constitute a
application service to the KDC. The properties of the AD-KDC-ISSUED flow of authorization data from the application service to the KDC.
container are insufficient for this use case because the service
knows the symmetric key for the checksum in the AD-KDC-ISSUED The properties of the AD-KDC-ISSUED container are insufficient for
container. Therefore, the KDC has no way to detect whether the this use case because the service knows the symmetric key for the
service has tampered with the contents of the AD-KDC-ISSUED container checksum in the AD-KDC-ISSUED container. Therefore, the KDC has no
within the evidence ticket. 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 The new AD-CAMMAC authorization data container specified in this
document improves upon AD-KDC-ISSUED by including additional verifier document improves upon AD-KDC-ISSUED by including additional verifier
elements. The svc-verifier element of the CAMMAC is equivalent to elements. The svc-verifier element of the CAMMAC is equivalent to
the ad-checksum element of AD-KDC-ISSUED and allows the service to the ad-checksum element of AD-KDC-ISSUED and allows the service to
verify the integrity of the contents as it already could with the AD- verify the integrity of the contents as it already could with the AD-
KDC-ISSUED container. The kdc-verifier and other-verifiers elements KDC-ISSUED container. The kdc-verifier and other-verifiers elements
are new to AD-CAMMAC and provide its enhanced capabilities. are new to AD-CAMMAC and provide its enhanced capabilities.
The kdc-verifier element of the AD-CAMMAC container allows a KDC to The kdc-verifier element of the AD-CAMMAC container allows a KDC to
skipping to change at page 5, line 49 skipping to change at page 5, line 49
signatures. signatures.
Verifier-MAC: Verifier-MAC:
Contains a MAC computed over the ASN.1 DER encoding of the Contains a MAC computed over the ASN.1 DER encoding of the
AuthorizationData value in the elements field of the AD-CAMMAC. AuthorizationData value in the elements field of the AD-CAMMAC.
The identifier, kvno, and enctype fields help the recipient locate The identifier, kvno, and enctype fields help the recipient locate
the key required for verifying the MAC. For the kdc-verifier and the key required for verifying the MAC. For the kdc-verifier and
the svc-verifier, the identifier, kvno and enctype fields are the svc-verifier, the identifier, kvno and enctype fields are
often obvious from context and MAY be omitted. For the kdc- often obvious from context and MAY be omitted. For the kdc-
verifier, the MAC is computed differently than for the svc- verifier, the MAC is computed differently than for the svc-
verifier and the other-verifiers, as described later. verifier and the other-verifiers, as described later. The key
usage for computing the MAC (Checksum) is 64.
kdc-verifier: kdc-verifier:
A Verifier-MAC where the key is that of the local Ticket-Granting A Verifier-MAC where the key is that of the local Ticket-Granting
Service (TGS). The checksum type is the required checksum type Service (TGS). The checksum type is the required checksum type
for the enctype of the TGS key. In contrast to the other for the enctype of the TGS key. In contrast to the other
Verifier-MAC elements, the KDC computes the MAC in the kdc- 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 6, line 38 skipping to change at page 6, line 38
A sequence of additional verifiers. In each additional Verifier- A sequence of additional verifiers. In each additional Verifier-
MAC, the key is a long-term key of the principal name specified in 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 the identifier field. The PrincipalName MUST be present and be a
valid principal in the realm. KDCs MAY add one or more "trusted valid principal in the realm. KDCs MAY add one or more "trusted
service" verifiers. Unless otherwise administratively configured, service" verifiers. Unless otherwise administratively configured,
the KDC SHOULD determine the "trusted service" principal name by the KDC SHOULD determine the "trusted service" principal name by
replacing the service identifier component of the sname of the replacing the service identifier component of the sname of the
surrounding ticket with "host". The checksum is computed using a surrounding ticket with "host". The checksum is computed using a
long-term key of the identified principal, and the checksum type long-term key of the identified principal, and the checksum type
is the required checksum type for the enctype of that long-term is the required checksum type for the enctype of that long-term
the key. The kvno and enctype SHOULD be specified to disambiguate key. The kvno and enctype SHOULD be specified to disambiguate
which of the long-term keys of the trusted service is used. The which of the long-term keys of the trusted service is used.
key usage is TBD.
5. Assigned numbers 5. Assigned numbers
TBD The ad-type number for AD-CAMMAC is 96.
The key usage number for the Verifier-MAC checksum is 64.
6. IANA Considerations 6. IANA Considerations
TBD. [ 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.
7. Security Considerations 7. Security Considerations
Although authorization data are generally conveyed within the Although authorization data are generally conveyed within the
encrypted part of a ticket and are thereby protected by the existing encrypted part of a ticket and are thereby protected by the existing
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
skipping to change at page 7, line 34 skipping to change at page 7, line 36
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 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 attempts to bind to least one (non-standard) authorization data type attempts to bind to
other authorization data in a ticket, and it is very difficult to other authorization data in a ticket, and it is very difficult to
have two such authorization data types coexist. have two such authorization data types coexist.
8. Open Issues 8. Acknowledgements
Allow an optional KDC-verified element, kdc-verifier-unbound, that is
not bound to the ticket contents? This would allow a KDC to provide
the service of verifying an extracted CAMMAC without needing a copy
of the ticket ciphertext.
9. Acknowledgements Shawn Emery, Ben Kaduk, and Zhanna Tsitkov provided helpful technical
and editorial feedback on earlier versions of this document.
Ben Kaduk and Zhanna Tsitkov provided helpful technical and editorial 9. References
feedback on earlier versions of this document.
10. References 9.1. Normative References
10.1. Normative References
[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.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005. Encryption for Kerberos 5", RFC 3962, 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.
skipping to change at page 8, line 27 skipping to change at page 8, line 21
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 8824- Recommendation X.680 (ISO/IEC International Standard 8824-
1:2008)", 2008. 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 9.2. Informative References
[MIT-Athena] [MIT-Athena]
Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An
Authentication Service for Open Network Systems. In Authentication Service for Open Network Systems. In
Proceedings of the Winter 1988 Usenix Conference. Proceedings of the Winter 1988 Usenix Conference.
February.", 1988. 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,
skipping to change at page 9, line 5 skipping to change at page 8, line 44
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication Service (V5)", RFC 1510, September 1993.
[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.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
Appendix A. Additional Stuff
This becomes an Appendix.
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. 16 change blocks. 
46 lines changed or deleted 38 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/