draft-ietf-krb-wg-cammac-04.txt   draft-ietf-krb-wg-cammac-05.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: August 5, 2013 MIT Kerberos Consortium Expires: January 15, 2014 MIT Kerberos Consortium
Feb 2013 July 14, 2013
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-krb-wg-cammac-04 draft-ietf-krb-wg-cammac-05
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 August 5, 2013. This Internet-Draft will expire on January 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 8 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
... ...
} }
Verifier-MAC ::= SEQUENCE { Verifier-MAC ::= SEQUENCE {
identifier [0] PrincipalName OPTIONAL, identifier [0] PrincipalName OPTIONAL,
kvno [1] UInt32, kvno [1] UInt32,
enctype [2] Int32, enctype [2] Int32,
mac [3] Checksum mac [3] Checksum
} }
AD-CAMMAC-BINDING ::= SEQUENCE { AD-CAMMAC-BINDING ::= OCTET STRING
cname [0] PrincipalName,
authtime [1] KerberosTime,
endtime [2] KerberosTime
}
END END
elements: elements:
A sequence of authorization data elements issued by the KDC. A sequence of authorization data elements issued by the KDC.
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 encoding of the AuthorizationData Contains a MAC computed over the encoding of the AuthorizationData
value in the elements field of the AD-CAMMAC. The identifier, value in the elements field of the AD-CAMMAC. The identifier,
kvno, and enctype fields help the recipient locate the key kvno, and enctype fields help the recipient locate the key
required for verifying the MAC. required for verifying the MAC.
AD-CAMMAC-BINDING: AD-CAMMAC-BINDING:
An AuthorizationData element that binds the CAMMAC contents to the An optional AuthorizationData element that binds the CAMMAC
enclosing ticket. This AuthorizationData element has ad-type contents to the enclosing ticket. This AuthorizationData element
number TBD, and MUST be absent from the transmitted elements field has ad-type number TBD, and if it appears in the AD-CAMMAC, it
of the AD-CAMMAC. It MUST be included in the computation of the MUST be the first member of the elements field of the AD-CAMMAC.
Verifiers as if it were the first element. The contents of the AD-CAMMAC-BINDING element are a local matter
for the KDC implementation. A KDC can use this element to
checksum portions of the ticket outside of the CAMMAC, to ensure
that a service has not tampered with them. This can be useful if
the KDC implements a capability resembling the Windows Constrained
Delegation (S4U2Proxy) [MS-SFU] extension.
kdc-verifier: kdc-verifier:
A Verifier-MAC where the key is the TGS key. The checksum type is A Verifier-MAC where the key is the TGS key. The checksum type is
the mandatory checksum type for the TGS key. the mandatory checksum type for the TGS key.
svc-verifier: svc-verifier:
A Verifier-MAC where the key is the long-term key of the service A Verifier-MAC where the key is the long-term key of the service
for which the ticket is issued. The checksum type is the for which the ticket is issued. The checksum type is the
mandatory checksum type for the long-term key of the service. mandatory checksum type for the long-term key of the service.
This field MUST be present if the service principal of the ticket This field MUST be present if the service principal of the ticket
skipping to change at page 7, line 11 skipping to change at page 7, line 16
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 methods on the ticket, some authorization data requires encryption methods on the ticket, some authorization data requires
the additional protection provided by the CAMMAC. the additional protection provided by the CAMMAC.
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 (if the sufficient information to identify the client principal. Therefore,
encoding of AD-CAMMAC-BINDING is omitted from the transmitted application protocols that rely on extracted CAMMACs might need to
CAMMAC). Therefore, application protocols that rely on extracted duplicate a substantial portion of the ticket contents and include
CAMMACs might need to duplicate a substantial portion of the ticket that duplicated information in the authorization data contained
contents and include that duplicated information in the authorization within the CAMMAC.
data contained within the CAMMAC.
A KDC that needs to verify the contents of a CAMMAC in a non-TGS A KDC that needs to verify the contents of a CAMMAC in a non-TGS
service ticket MUST ensure that the CAMMAC in the ticket is the same service ticket MUST ensure that the CAMMAC in the ticket is the same
one that it inserted into the ticket. A malicious service could one that it inserted into the ticket. A malicious service could
substitute legitimate CAMMACs from other tickets that it has received substitute legitimate CAMMACs from other tickets that it has received
(but not fabricate completely new CAMMACs) into a service ticket. A (but not fabricate completely new CAMMACs) into a service ticket. A
CAMMAC by itself does not contain sufficient information to CAMMAC by itself does not contain sufficient information to
accomplish this. accomplish this.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 8, line 18 skipping to change at page 8, line 20
Standard 8825-1:2008)", 1997. Standard 8825-1:2008)", 1997.
9.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:
Service for User and Constrained Delegation Protocol",
January 2013,
<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
[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.
 End of changes. 8 change blocks. 
21 lines changed or deleted 26 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/