One document matched: draft-ietf-krb-wg-cammac-08.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://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2307.xml">
<!ENTITY RFC3961 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC3962 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3962.xml">
<!ENTITY RFC3713 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3713.xml">
<!ENTITY RFC4120 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC1510 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1510.xml">
<!ENTITY RFC4559 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4559.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2898 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2898.xml">
<!ENTITY RFC4493 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.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-08"
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="June" 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.
</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 service
received from a client, as evidence that the client
authenticated to the service. 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 is equivalent 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-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, an operation that 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>
<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 (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 a 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 that 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>
<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
attempts to bind to other authorization data in a ticket, and
it is very difficult to have two such authorization data types
coexist.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Shawn Emery, Ben Kaduk, and Zhanna Tsitkov 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"?-->
&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>
<!-- 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:50:58 |