One document matched: draft-ietf-krb-wg-cammac-06.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 RFC2307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2307.xml">
<!ENTITY RFC3961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC3962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3962.xml">
<!ENTITY RFC3713 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3713.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC1510 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1510.xml">
<!ENTITY RFC4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2898 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml">
<!ENTITY RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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-06"
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="2013" />
<!-- 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.
</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 new AD-CAMMAC authorization data container specified in
this document is an improvement upon AD-KDC-ISSUED because it
provides assurance to the KDC that the service named in the
ticket did not tamper with the contained authorization data.
By adding MACs verifiable by the KDC and trusted services,
AD-CAMMAC enables several new use cases for the Kerberos
protocol that AD-KDC-ISSUED does not accommodate.
</t>
<t>
The existing AD-KDC-ISSUED authorization data container allows
a service to verify that the KDC has issued the contained
authorization data. However, because the symmetric key for
the MAC is known to both the KDC and the service, the KDC
cannot generally detect whether the service has forged the
contents of an AD-KDC-ISSUED container in an existing ticket.
The new kdc-verifier MAC in the AD-CAMMAC container, because
it uses a key known only to the KDC, allows the KDC to verify
the integrity of the contents of that container.
</t>
<t>
For example, the new AD-CAMMAC container can protect
authorization data when using the Constrained Delegation
(<xref target="MS-SFU">S4U2Proxy</xref>) protocol extension.
This extension allows a service to use a ticket to itself as
evidence that it received a user request and consequently ask
the KDC to issue a new ticket on behalf of the user to perform
operations against another service.
</t>
<t>
If the KDC had issued a AD-KDC-ISSUED container in the
S4U2Proxy evidence ticket instead of AD-CAMMAC, it would have
no way to subsequently verify whether the service had tampered
with the contents of that container. The service would know
the key for the MAC for the AD-KDC-ISSUED container in the
evidence ticket, and could therefore forge its contents.
</t>
<t>
The kdc-verifier MAC in the AD-CAMMAC container allows a KDC
to verify the integrity of the contained authorization data
without having to compute all of the authorization data, an
operation that might not always be possible when the data
contains ephemeral information such as the strength or type of
authentication method used to obtain the original ticket.
</t>
<t>
A lesser-privileged service on a host may receive an
authentication from a client, and might then ask a
higher-privileged service ("trusted service") on the same host
to act on behalf of the client. To demonstrate that the
client has authenticated to it, the lesser-privileged service
can extract the AD-CAMMAC container from the ticket and submit
it to the trusted service. The trusted service can either ask
a specialized service (not yet specified) on the KDC to
validate the AD-CAMMAC container, or use verify the optional
additional verifiers (the other-verifiers field) that are part
of the AD-CAMMAC.
</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"/><xref target="X.690"/>. For consistency, this
specification also uses the ASN.1 syntax 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>
<section title="AD-CAMMAC">
<figure>
<preamble></preamble>
<artwork><![CDATA[
KerberosV5CAMMAC DEFINITIONS EXPLICIT TAGS ::= BEGIN
AD-CAMMAC ::= SEQUENCE {
elements [0] AuthorizationData,
kdc-verifier [1] Verifier-MAC,
svc-verifier [2] Verifier-MAC OPTIONAL,
other-verifiers [3] SEQUENCE OF Verifier
}
Verifier ::= CHOICE {
mac Verifier-MAC,
...
}
Verifier-MAC ::= SEQUENCE {
identifier [0] PrincipalName OPTIONAL,
kvno [1] UInt32,
enctype [2] Int32,
mac [3] Checksum
}
AD-CAMMAC-BINDING ::= OCTET STRING
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 a MAC computed over the 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.
</t>
<t hangText="AD-CAMMAC-BINDING:">
<vspace/>
An optional AuthorizationData element that binds the
CAMMAC contents to the enclosing ticket. This
AuthorizationData element has ad-type number TBD, and if
it appears in the AD-CAMMAC, it MUST be the first member
of the elements field of the AD-CAMMAC.
<vspace/>
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 <xref
target="MS-SFU">Constrained Delegation
(S4U2Proxy)</xref> extension.
</t>
<t hangText="kdc-verifier:">
<vspace/>
A Verifier-MAC where the key is the TGS key. The
checksum type is the mandatory checksum type for the TGS
key.
</t>
<t hangText="svc-verifier:">
<vspace/>
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 mandatory checksum type for the long-term
key of the service. 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 the 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 'trusted service' SHOULD be found by
replacing the service identifier component of the
principal name of the svc-verifier with 'host'. The
checksum type is the mandatory checksum type for the
long-term key (which one?) of the principal. The key
usage is TBD.
</t>
</list>
</t>
</section>
</section>
<section title="Assigned numbers">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>TBD.</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 methods on the 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.
</t>
<t>
A KDC that needs to verify the contents of a CAMMAC in a
non-TGS ticket MUST ensure that the CAMMAC in the ticket is
the same one that it inserted into the ticket. A malicious
service could substitute legitimate CAMMACs from other tickets
that it has received (but not fabricate completely new
CAMMACs) into a service ticket. A CAMMAC by itself does not
contain sufficient information to accomplish this, but
including an AD-CAMMAC-BINDING element could be sufficient.
</t>
</section>
<section title="Open Issues">
<t>
Consider making other-verifiers "[3] SEQUENCE (SIZE (1..MAX))
OF VERIFIER OPTIONAL" to make the common case encoding
smaller.
</t>
<t>
Enclose in AD-IF-RELEVANT?
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD.</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"?-->
&RFC4120;
&RFC3961;
&RFC3962;
<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. -->
&RFC2119;
&RFC3552;
&RFC1510;
<reference anchor="MIT-Athena">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Kerberos: An Authentication Service for Open Network Systems.
In Proceedings of the Winter 1988 Usenix Conference.
February.</title>
<author initials="J." surname="Steiner">
<organization></organization>
</author>
<author initials="B." surname="Neuman">
<organization></organization>
</author>
<author initials="J." surname="Schiller">
<organization></organization>
</author>
<date year="1988" />
</front>
</reference>
<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>
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
<!-- 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:51:10 |