One document matched: draft-ietf-krb-wg-cammac-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC3961 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC4120 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-krb-wg-cammac-11"
ipr="trust200902" updates="4120">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Container Authenticated by Multiple MACs">
Kerberos Authorization Data Container Authenticated by Multiple
MACs
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Simo Sorce" initials="S.S." role="editor"
surname="Sorce">
<organization>Red Hat</organization>
<address>
<email>ssorce@redhat.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tom Yu" initials="T.Y." role="editor" surname="Yu">
<organization>MIT Kerberos Consortium</organization>
<address>
<email>tlyu@mit.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Thomas Hardjono" initials="T.H." role="editor"
surname="Hardjono">
<organization>MIT Kerberos Consortium</organization>
<address>
<email>hardjono@mit.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Network Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Kerberos</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
Abstract: This document specifies a Kerberos Authorization
Data container that supersedes AD-KDC-ISSUED. It allows for
multiple Message Authentication Codes (MACs) or signatures to
authenticate the contained Authorization Data elements. This
document updates RFC 4120.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies a new Authorization Data container for
Kerberos, called AD-CAMMAC (Container Authenticated by
Multiple MACs), that supersedes AD-KDC-ISSUED. This new
container allows both the receiving application service and
the Key Distribution Center (KDC) itself to verify the
authenticity of the contained authorization data. The
AD-CAMMAC container can also include additional verifiers that
"trusted services" can use to verify the contained
authorization data.
</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Motivations">
<t>
The Kerberos protocol allows clients to submit arbitrary
authorization data for a KDC to insert into a Kerberos ticket.
These client-requested authorization data allow the client to
express authorization restrictions that the application
service will interpret. With few exceptions, the KDC can
safely copy these client-requested authorization data to the
issued ticket without necessarily inspecting, interpreting, or
filtering their contents.
</t>
<t>
The AD-KDC-ISSUED authorization data container specified in
<xref target="RFC4120">RFC 4120</xref> is a means for KDCs to
include positive or permissive (rather than restrictive)
authorization data in service tickets in a way that the
service named in a ticket can verify that the KDC has issued
the contained authorization data. This capability takes
advantage of a shared symmetric key between the KDC and the
service to assure the service that the KDC did not merely copy
client-requested authorization data to the ticket without
inspecting them.
</t>
<t>
The AD-KDC-ISSUED container works well for situations where
the flow of authorization data is from the KDC to the service.
However, protocol extensions such as Constrained Delegation
(<xref target="MS-SFU">S4U2Proxy</xref>) require that a
service present to the KDC a service ticket that the KDC
previously issued, as evidence that the service is authorized
to impersonate the client principal named in that ticket. In
the S4U2Proxy extension, the KDC uses the evidence ticket as
the basis for issuing a derivative ticket that the service can
then use to impersonate the client. The authorization data
contained within the evidence ticket constitute a flow of
authorization data from the application service to the KDC.
The properties of the AD-KDC-ISSUED container are insufficient
for this use case because the service knows the symmetric key
for the checksum in the AD-KDC-ISSUED container. Therefore,
the KDC has no way to detect whether the service has tampered
with the contents of the AD-KDC-ISSUED container within the
evidence ticket.
</t>
<t>
The new AD-CAMMAC authorization data container specified in
this document improves upon AD-KDC-ISSUED by including
additional verifier elements. The svc-verifier element of the
CAMMAC has the same functional and security properties as the
ad-checksum element of AD-KDC-ISSUED; the svc-verifier allows
the service to verify the integrity of the AD-CAMMAC contents
as it already could with the AD-KDC-ISSUED container. The
kdc-verifier and other-verifiers elements are new to AD-CAMMAC
and provide its enhanced capabilities.
</t>
<t>
The kdc-verifier element of the AD-CAMMAC container allows a
KDC to verify the integrity of authorization data that it
previously inserted into a ticket, by using a key that only
the KDC knows. The KDC thus avoids recomputing all of the
authorization data for the issued ticket; this operation might
not always be possible when that data includes ephemeral
information such as the strength or type of authentication
method used to obtain the original ticket.
</t>
<t>
The verifiers in the other-verifiers element of the AD-CAMMAC
container are not required, but can be useful when a
lesser-privileged service receives a ticket from a client and
needs to extract the CAMMAC to demonstrate to a
higher-privileged "trusted service" on the same host that it
is legitimately acting on behalf of that client. The trusted
service can use a verifier in the other-verifiers element to
validate the contents of the CAMMAC without further
communication with the KDC.
</t>
</section>
<section title="Encoding">
<t>
The Kerberos protocol is defined in <xref target="RFC4120"/>
using Abstract Syntax Notation One (ASN.1) <xref
target="X.680"/> and using the ASN.1 Distinguished Encoding
Rules (DER) <xref target="X.690"/>. For consistency, this
specification also uses ASN.1 for specifying the layout of
AD-CAMMAC. The ad-data of the AD-CAMMAC authorization data
element is the ASN.1 DER encoding of the AD-CAMMAC ASN.1 type
specified below.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
KerberosV5CAMMAC DEFINITIONS EXPLICIT TAGS ::= BEGIN
AD-CAMMAC ::= SEQUENCE {
elements [0] AuthorizationData,
kdc-verifier [1] Verifier-MAC OPTIONAL,
svc-verifier [2] Verifier-MAC OPTIONAL,
other-verifiers [3] SEQUENCE (SIZE (1..MAX))
OF Verifier OPTIONAL
}
Verifier ::= CHOICE {
mac Verifier-MAC,
...
}
Verifier-MAC ::= SEQUENCE {
identifier [0] PrincipalName OPTIONAL,
kvno [1] UInt32 OPTIONAL,
enctype [2] Int32 OPTIONAL,
mac [3] Checksum
}
END
]]></artwork>
<postamble></postamble>
</figure>
<t>
<list style="hanging">
<t hangText="elements:">
<vspace/>
A sequence of authorization data elements issued by the
KDC. These elements are the authorization data that the
verifier fields authenticate.
</t>
<t hangText="Verifier:">
<vspace/>
A CHOICE type that currently contains only one
alternative: Verifier-MAC. Future extensions might add
support for public-key signatures.
</t>
<t hangText="Verifier-MAC:">
<vspace/>
Contains an <xref target="RFC3961">RFC 3961</xref> Checksum
(MAC) computed over the ASN.1 DER encoding of the
AuthorizationData value in the elements field of the
AD-CAMMAC. The identifier, kvno, and enctype fields help
the recipient locate the key required for verifying the
MAC. For the kdc-verifier and the svc-verifier, the
identifier, kvno and enctype fields are often obvious from
context and MAY be omitted. For the kdc-verifier, the MAC
is computed differently than for the svc-verifier and the
other-verifiers, as described later. The key usage for
computing the MAC (Checksum) is 64.
</t>
<t hangText="kdc-verifier:">
<vspace/>
A Verifier-MAC where the key is a long-term key of the
local Ticket-Granting Service (TGS). The checksum type is
the required 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-verifier over the ASN.1 DER
encoding of the EncTicketPart of the surrounding ticket,
but where the AuthorizationData value in the EncTicketPart
contains the AuthorizationData value contained in the
CAMMAC instead of the AuthorizationData value that would
otherwise be present in the ticket. This altered
Verifier-MAC computation binds the kdc-verifier to the
other contents of the ticket, assuring the KDC that a
malicious service has not substituted a mismatched CAMMAC
received from another ticket.
</t>
<t hangText="svc-verifier:">
<vspace/>
A Verifier-MAC where the key is the same long-term service
key that the KDC uses to encrypt the surrounding ticket.
The checksum type is the required checksum type for the
enctype of the service key used to encrypt the ticket.
This field MUST be present if the service principal of the
ticket is not the local TGS, including when the ticket is
a cross-realm TGT.
</t>
<t hangText="other-verifiers:">
<vspace/>
A sequence of additional verifiers. In each additional
Verifier-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 valid principal in the realm.
KDCs MAY add one or more "trusted service" verifiers.
Unless otherwise administratively configured, the KDC
SHOULD determine the "trusted service" principal name by
replacing the service identifier component of the sname of
the surrounding ticket with "host". The checksum is
computed using a long-term key of the identified
principal, and the checksum type is the required checksum
type for the enctype of that long-term key. The kvno and
enctype SHOULD be specified to disambiguate which of the
long-term keys of the trusted service is used.
</t>
</list>
</t>
</section>
<section title="Usage">
<t>
Application servers and KDCs MAY ignore the AD-CAMMAC
container and the authorization data elements it contains.
For compatibility with older Kerberos implementations, a KDC
issuing an AD-CAMMAC SHOULD enclose it in an AD-IF-RELEVANT
container unless the KDC knows that the application server is
likely to recognize it.
</t>
</section>
<section title="Assigned numbers">
<t>The ad-type number for AD-CAMMAC is 96.</t>
<t>
The key usage number for the Verifier-MAC checksum is 64.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
[ RFC Editor: please remove this section prior to
publication. ]
</t>
<t>
There are no IANA considerations in this document. Any
numbers assigned in this document are not in IANA-controlled
number spaces.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Although authorization data are generally conveyed within the
encrypted part of a ticket and are thereby protected by the
existing encryption scheme used for the surrounding ticket,
some authorization data requires the additional protection
provided by the CAMMAC.
</t>
<t>
Some protocol extensions such as S4U2Proxy allow the KDC to
issue a 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 revalidate it.
</t>
<t>
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 it into a bearer token, with all of the
associated security implications. Also, the CAMMAC does not
itself necessarily contain sufficient information to identify
the client principal. Therefore, application protocols that
rely on extracted CAMMACs might need to duplicate a
substantial portion of the ticket contents and include that
duplicated information in the authorization data contained
within the CAMMAC. The extent of this duplication would depend
on the security properties required by the application
protocol.
</t>
<t>
The method for computing the kdc-verifier does not bind it to
any authorization data within the ticket but outside of the
CAMMAC. At least one (non-standard) authorization data type,
AD-SIGNEDPATH, attempts to bind to other authorization data in
a ticket, and it is very difficult for two such authorization
data types to coexist.
</t>
<t>
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. In this situation, the KDC cannot always
determine whether the CAMMAC contents are intact. The KDC
MUST NOT create a new CAMMAC from an existing one unless the
existing CAMMAC has a valid kdc-verifier, with two exceptions.
</t>
<t>
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 CAMMAC of a local TGT from tampering, assuming
that all of the KDCs in the local realm consistently filter
out CAMMAC authorization data submitted by clients. The KDC
MAY create a new CAMMAC from an 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 filter out
CAMMAC authorization data submitted by clients.
</t>
<t>
An application service might not use the S4U2Proxy extension,
or the realm policy might disallow the use of S4U2Proxy by
that service. In 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 services. Because of the lack of
security impact, the KDC MAY create a new
CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is
inserting the new CAMMAC into a service ticket for the same
service principal as the ticket that contained the existing
CAMMAC, but MUST NOT place a kdc-verifier in the new CAMMAC.
</t>
<t>
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.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Zhanna
Tsitkov, and Kai Zheng provided helpful technical and
editorial feedback on earlier versions of this document.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4120;
&RFC3961;
<reference anchor="X.680">
<front>
<title>
Information technology -- Abstract Syntax Notation One
(ASN.1): Specification of basic notation -- ITU-T
Recommendation X.680 (ISO/IEC International Standard
8824-1:2008)
</title>
<author surname="ISO">
<organization>ISO</organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="X.690">
<front>
<title>
Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER) -- ITU-T Recommendation X.690 (ISO/IEC International
Standard 8825-1:2008)
</title>
<author surname="ISO">
<organization>ISO</organization>
</author>
<date year="1997" />
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="MS-SFU"
target="http://msdn.microsoft.com/en-us/library/cc246071.aspx">
<front>
<title>[MS-SFU]: Kerberos Protocol Extensions: Service for
User and Constrained Delegation Protocol</title>
<author>
<organization>Microsoft</organization>
</author>
<date year="2013" month="January"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2012-02-08 EBD Initial version after the split of generalized-pac
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:53:41 |