One document matched: draft-zhu-pku2u-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC0822 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0822.xml'>
<!ENTITY RFC1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY RFC3490 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml'>
<!ENTITY RFC4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY RFC4121 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml'>
<!ENTITY RFC2743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY RFC3280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml'>
<!ENTITY RFC1964 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
<!ENTITY RFC4556 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml'>
<!ENTITY RFC3961 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
<!ENTITY RFC4514 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4514.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc ipr='full3978' category="std" docName="draft-zhu-pku2u-07">
<front><title abbrev="PKU2U">Public Key Cryptography Based User-to-User Authentication - (PKU2U)</title>
<author initials="L." surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address><postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>lzhu@microsoft.com</email></address>
</author>
<author initials="J." surname="Altman" fullname="Jeffery Altman">
<organization>Secure Endpoints</organization> <address>
<postal>
<street>255 W 94th St</street>
<city>New York</city>
<region>NY</region>
<code>10025</code>
<country>US</country>
</postal>
<email>jaltman@secure-endpoints.com</email></address>
</author>
<author initials='N.' surname="Williams" fullname='Nicolas Williams'>
<organization
abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city>
<region>TX</region>
<code>78727</code>
<country>US</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="July" year="2008"></date>
<area>Security</area><workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines a Generic Security Services
Application Program Interface (GSS-API) mechanism based
on Public Key Infrastructure (PKI) - PKU2U. This
mechanism is based on Kerberos V messages and the
Kerberos V GSS-API mechanism, but without requiring a
Kerberos Key Distribution Center (KDC).</t>
</abstract>
</front><middle>
<section anchor="introduction" title="Introduction">
<t>The Generic Security Services Application Programming
Interface (GSS-API) is a generic protocol and API for
providing authentication and session protection to
applications. It is generic in that it supports
multiple authentication mechanisms. Today there exists
only one workable, widely deployed, standards-track
GSS-API mechanism: the Kerberos V GSS-API mechanism
<xref target="RFC1964"/> <xref target="RFC4121"/>, which
is based on Kerberos V <xref target="RFC4120"/>. There
is a need to provide a GSS-API mechanism which does not
require Kerberos V Key Distribution Center (KDC)
infrastructure, and which supports the use of public key
cryptography, particularly Public Key Infrastructure
(PKI) <xref target="RFC3280"/>, including the use of
public key certificates without a PKI.</t>
<t>This document specifies such a mechanism: the Public Key
User to User mechanism (PKU2U).</t>
<t>PKU2U is based on building blocks taken from Kerberos V
<xref target="RFC4120"/>, PKINIT, <xref
target="RFC4556"/> (which in turn uses PKI <xref
target="RFC3280"/>) building blocks), and the
Kerberos V GSS-API mechanism <xref target="RFC1964"/>
<xref target="RFC4121"/>. In spite of using Kerberos V
building blocks, PKU2U does not require any Kerberos V
KDC infrastructure. And though PKU2U also uses PKI
building blocks, PKU2U can be used without a PKI by
pre-sharing certificates and/or pre-associating
name/certificate bindings.</t>
<t>Therefore PKU2U can be used for true peer-to-peer
authentication, as well as for PKI-based
authentication.</t>
</section>
<section title="Conventions Used in This Document">
<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"
pageno="false" format="default"></xref>.</t>
<t>In this document, the GSS-API initiator or acceptor is
referred to as the peer when the description is
applicable to both the initiator and the acceptor.</t>
</section>
<section anchor="pku2urealm" title="The PKU2U Realm Name">
<t>The PKU2U realm name is defined as a reserved Kerberos
realm name per <xref target="KRB-NAMING"/>, and it has
the value of "WELLKNOWN:PKU2U".</t>
<t>Unless otherwise specified, the realm name in any
Kerberos message used by PKU2U is the PKU2U realm
name.</t>
</section>
<section anchor="naming" title="PKU2U Principal Naming">
<t>PKU2U principal names are certificate names and subject
alternative names <xref target="RFC3280"/> as they
appear in the certificate of any PKU2U peer, as well as
any names agreed to out of band where a certificate
authenticates a name that does not appear in the
certificate.</t>
<t>Thus certificates may be associated with multiple
principal names. This presents problems for the GSS-API
bindings of a PKI-based mechanism. We resolve these
problems as follows:</t>
<t>
<list style="symbols">
<t>We define multiple GSS-API name types
corresponding to several GeneralName choices
<xref target="RFC3280"/>, along with syntaxes,
display forms, and exported name token formats
for each. For most of the name-types listed
below the exported name token formats consists
of a BER-encoded GeneralName with the usual
exported name token header as per-RFC2743. Two
name-types are shared with the Kerberos V
mechanism and use the Kerberos V mechanism's
exported name token format.</t>
<t>The cred_name of credential object acquired with
a desired_name other than GSS_C_NT_NO_NAME MUST
be equal to the name used as the
desired_name.</t>
<t>We provide that the cred_name of a default
credential, or of a credential acquired with the
GSS_C_NT_NO_NAME desired_name MUST be the first
id-pkinit-san subject alternative name of the
certificate, if there is one, or else it MUST be
the DN of its certificate.</t>
<t>We provide a method by which initiators can
assert one of these names to the other, and we
provide a default of asserting the certificate
DN. We also provide a method of asserting names
that do not appear in the caller's certificate.
This assertion consists of a traditional
Kerberos V principal name appearing in the
expected 'cname' fields of various Kerberos V
PDUs used to construct PKU2U security context
tokens, and an optional authorization-data type
consisting of an integer which identifies one of
the several names of the initiator's
certificate.</t>
<t>We provide a method of matching host-based
service principal names to acceptor
certificates, so that: a) initiators need not
know the particulars of an acceptor's
certificates' names a priori, b) acceptors can
select a credential to accept a security context
with that the initiator will accept.</t>
</list>
</t>
<t>Thus GSS-API initiators that use the GSS_C_NO_NAME as the
desired_name arguments of GSS_Acquire_cred() and
GSS_Add_cred(), or GSS_C_NO_CREDENTIAL as the cred
argument of GSS_Init_sec_context() will assert the
selected certificate's DN, and that certificate's DN
will be the name returned by GSS_Inquire_cred() and
GSS_Inquire_cred_by_mech().</t>
<t>And portable GSS-API initiator applications using
GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e.,
for importing a name to use as the targ_name input
argument of GSS_Init_sec_context()) will have a
reasonable chance of success in authenticating peers
with certificates predating this specification.</t>
<section anchor="name_DN" title="GSS_C_NT_DN">
<t>We introduce a new name type, GSS_C_NT_DN, with OID
<TBD>, corresponding to the 'Name' ASN.1 type
defined in <xref target='RFC3280'/>.</t>
<t>The query syntax and display form for names of this
type SHALL be as described in <xref
target='RFC4514'/>.</t>
<t>There is no reasonable way to canonicalize names of
this type without providing a directory against
which to lookup the name. The canonical form of
this name is the same as that provided to
GSS_Import_name() with GSS_C_NT_DN as the
input_name_type.</t>
<t>The exported name token format for names of this type
SHALL be the DER encoding of a GeneralName with
directoryName as the choice.</t>
<t>Implementation support for this name type is
REQUIRED.</t>
</section>
<section anchor="name_dNSName" title="GSS_C_NT_HOSTNAME">
<t>We introduce a new name type, GSS_C_NT_HOSTNAME, with
OID <TBD>, corresponding to the 'dNSName'
choice of the 'GeneralName' ASN.1 type defined in
<xref target='RFC3280'/>.</t>
<t>The query syntax for names of this type SHALL be a
DNS name <xref target='RFC1034'/> in either ACE or
Unicode form <xref target='RFC3490'/>.</t>
<t>The display and canonical form of names of this type
SHALL be a DNS domainname in ACE form, with
character case folded down.</t>
<t>The exported name token format for names of this type
SHALL be the DER encoding of a GeneralName with
dNSName as the choice and the DNS domainname in ACE
form and case folded down.</t>
<t>Implementation support for this name type is
OPTIONAL.</t>
</section>
<section anchor="name_iPAddress" title="GSS_C_NT_IP_ADDR">
<t>We introduce a new name type, GSS_C_NT_IP_ADDR, with
OID <TBD>, corresponding to the 'iPAddress'
choice of the 'GeneralName' ASN.1 type defined in
<xref target='RFC3280'/>.</t>
<t>The query syntax, and display and canonical forms for
names of this type SHALL be the text representation
of an IPv4 or IPv6 address (XXX add references).</t>
<t>The exported name token form for this name type SHALL
be a DER-encoded GeneralName with the iPAddress
choice.</t>
<t>Implementation support for this name type is
OPTIONAL.</t>
</section>
<section anchor="name_rfc822Name" title="GSS_C_NT_EMAIL_ADDR">
<t>We introduce a new name type, GSS_C_NT_EMAIL_ADDR,
with OID <TBD>, corresponding to the
'rfc822Name' choice of the 'GeneralName' ASN.1 type
defined in <xref target='RFC3280'/>.</t>
<t>The query syntax and display form for names of this
type SHALL be the text representation of an
'addr-spec' as defined in <xref
target='RFC0822'/>.</t>
<t>The canonical form of names of this type SHALL be the
query form with case folded down.</t>
<t>The exported name token form for this name type SHALL
be a DER-encoded GeneralName with the rfc822Name
choice.</t>
<t>Implementation support for this name type is
OPTIONAL.</t>
</section>
<section anchor="name_user_name" title="GSS_C_NT_USER_NAME">
<t>For PKU2U the generic name type GSS_C_NT_USER_NAME
SHALL be an alias of GSS_C_NT_EMAIL_ADDR.</t>
<t>Implementation support for this name type is
OPTIONAL.</t>
</section>
<section anchor="name_krb5" title="GSS_KRB5_NT_PRINCIPAL_NAME">
<t>PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME
names <xref target='RFC1964'/>. These appear as
expected in various 'cname', 'crealm', 'sname' and
'srealm' fields of the Kerberos V PDUs used to
construct PKU2U security context tokens. For PKU2U
names of this type correspond to subject alternative
names of type 'id-pkinit-san' <xref
target='RFC4556'/>. When no such SAN appears in
a certificate, then names of this type correspond to
certificates as agreed out of band (e.g., there may
be a table mapping certificates to Kerberos V
principal names).</t>
<t>The canonical form of names of this type SHALL be as
specified in RFC4121. (XXX Here we have two
mechanisms sharing a single name type that
originally was mechanism-specific. This may cause
problems with some mechglue implementations; we
should describe this in detail.)</t>
<t>Implementation support for this name type is
REQUIRED.</t>
</section>
<section anchor="name_anon" title="GSS_C_NT_ANONYMOUS">
<t>This is a generic GSS-API name-type. Implementation
support for this name type is OPTIONAL. See <xref
target="as_req"/> for more information.</t>
</section>
<section anchor="hostbased" title="Matching host-based
service principal names to acceptor certificates">
<t>Support for GSS_C_NT_HOSTBASED_SERVICE names is
REQUIRED as described herein.</t>
<t>The query and display forms of this name type are as
per-RFC2743. The canonical and exported name token
forms are as per-RFC1964.</t>
<t>Initiators using names of type
GSS_C_NT_HOSTBASED_SERVICE to identify target
acceptors represent these names as Kerberos V
principal names as per <xref target='RFC4121'/> but
with a well-known realm name of "WELLKNOWN:PKU2U"
(see <xref target="as_req"/>).</t>
<t>Acceptors match such names to acceptor certificates
as follows. Initiators then match the certificate
chosen by the acceptor in the same manner.</t>
<t>Initiators can also assert host-based service names as
the initiator name. In this case acceptors MUST
also apply the matching rules below to validate the
initiator's assertion.</t>
<t>
<list style="numbers">
<t>If the acceptor has a certificate with an
id-pkinit-san subject alternative name
matching the initiator-provided acceptor
name, then the certificate matches.</t>
<t>If the acceptor has a certificate with a
dNSName SAN that matches the hostname part
of the host-based service principal name,
and either the anyExtendedKeyUsage extended
key usage (EKU), or no EKU is present, or an
EKU is present which corresponds to the
service part of the host-based service
principal name, then the certificate
matches. The id-kp-serverAuth EKU SHALL be
considered to match the 'HTTP' service
name. (See <xref target="iana"/>, IANA
considerations, where the GSS-API service name
registry is extended to include an EKU for
each service name.)</t>
<t>Implementations SHOULD, subject to local
configuration, allowing matches where the CN
of the DN of a cert matches the hostname
part of the host-based service name, for
some or all service names. This feature is
needed to allow the use of existing web
certificates.</t>
<t>If there is an out-of-band binding of the
peer's host-based service name to its
certificate, then the certificate
matches.</t>
</list>
</t>
</section>
</section>
<section anchor="protocol" title="The Protocol Description and
the Context Establishment Tokens">
<t>The PKU2U mechanism is a GSS-API mechanism based on <xref
target="RFC4120"/>, <xref target="RFC4556"/> and
<xref target="RFC4121"/>.</t>
<t>The per-message tokens of the PKU2U mechanism are the
same as those of the Kerberos V GSS-API mechanism <xref
target="RFC4121"/>.</t>
<t>The PKU2U security context token exchange consists of
KRB-AS-REQ and KRB-AS-REP (and KRB-ERROR) Kerberos KDC
PDUs (with minor changes/requirements described below)
as context tokens, with the acceptor as the KDC,
followed by context tokens from <xref target="RFC4121"/>
using the Kerberos V Ticket PDU issued by the
acceptor-as-KDC. PKINIT <xref target="RFC4556"/> is the
only acceptable pre-authentication method. Caching that
ticket issued by the acceptor allows subsequent security
context exchanges between the same to peers to use a
single context token round-trip -- a "fast restart"
feature.</t>
<t>PKU2U differs from Kerberos V with PKINIT in several
minor ways:</t>
<t>
<list style='symbols'>
<t>KDC PDUs are not exchanged as usual in Kerberos,
but wrapped as GSS-API context tokens</t>
<t>PKU2U allows the use of out-of-band binding of
certificates to principal names</t>
<t>PKU2U does not require the use of KDC
certificates</t>
<t>PKU2U adds pa-data types for carrying the
initiator's assertion of its name and the
targ_name passed to GSS_Init_sec_context()</t>
</list>
</t>
<t>PKU2U differs from the Kerberos V GSS-API mechanism in
several ways:</t>
<t>
<list style='symbols'>
<t>KDC PDUs are not exchanged as usual in Kerberos,
but wrapped as GSS-API context tokens</t>
<t>PKU2U allows the use of principal names matching
PKI naming</t>
<t>PKU2U adds an extension to the RFC4121 initial
context token for binding the AP-REQ to the AS
exchange that precedes is (that is, when the
initiator has to request a ticket from the
acceptor)</t>
<t>The number of round-trips can vary. If the
initiator already has a ticket for the
acceptor then the context token exchange will be
half a round-trip or one round-trip, as per
RFC4121. Otherwise one or two round-trips are
added for the AS exchanges needed to acquire a
ticket. Note that two AS exchanges may
be required when the initiator's initial choice
of certificate does not match the acceptor's
trust anchors, in which case the acceptor will
reply with a KRB-ERROR with
TD-TRUSTED-CERTIFIERS indicating what the
acceptor's trust anchors are, and then the
initiator can engage in a second AS exchange
within the same context token exchange.</t>
</list>
</t>
<t>To recapitulate, the acceptor and the initiator
communicate by tunneling the authentication service
exchange messages through the use of the GSS-API tokens
and application traffic. The reliable delivery of the
authentication service exchange messages at the GSS-API
token level is mandatory. In the event of message loss,
message duplication, or out of order message delivery,
the security context MUST fail to establish.</t>
<t>All context establishment tokens MUST follow the
InitialContextToken syntax defined in Section 3.1 of
<xref target="RFC2743"/>. PKU2U is identified by the
Objection Identifier (OID) id-kerberos-pku2u.</t>
<t>All context establishment tokens consist of some Kerberos
V PDU or another, prefixed with a two-octet token type
ID, and the InitialContextToken header (see above).</t>
<figure>
<preamble>The PKU2U OID is:</preamble>
<artwork>
id-kerberos-pku2u ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
pku2u(7) }
</artwork>
</figure>
<t>The innerToken described in section 3.1 of <xref
target="RFC2743"/> and subsequent GSS-API mechanism
tokens have the following formats: it starts with a
two-octet token-identifier (TOK_ID), followed by a
Kerberos message. The TOK_ID values for the KRB_AS_REQ
message and the KRB_AS_REP message are defined in the
table blow:</t>
<figure>
<artwork>
Token TOK_ID Value in Hex
-----------------------------------------------
KRB_AS_REQ 05 00
KRB_AS_REP 06 00
</artwork>
</figure>
<t>The TOK_ID values for all other Kerberos messages are the
same as defined in <xref target="RFC4121"/>.</t>
<t>By using anonymous PKINIT <xref target="KRB-ANON"/>,
PKU2U can provide server-authentication without
revealing the client's identity.</t>
<section anchor="as_req" title="Context token derived from
KRB_AS_REQ">
<t>When the initiator does not have a service ticket to
the acceptor, it requests a ticket from the acceptor
instead of the KDC by constructing a KRB_AS_REQ PDU
<xref target="RFC4120"/> and using it as the context
token, with a token type ID prefixed. This will be
the initiator's initial context token, therefore it
MUST also have the standard header bearing the OID
of the mechanism being used (in this case, PKU2U's
OID).</t>
<t>If the initiator wishes to assert a name of type
GSS_C_NT_ANONYMOUS then it MUST set the cname field
to WELLKNOWN/WELLKNOWN with name type
KRB_NT_WELLKNOWN <xref target="KRB-ANON"/>, and it
MUST NOT use a certificate <xref
target="KRB-ANON"/>. If the initiator wishes to
assert a name of type GSS_KRB5_NT_PRINCIPAL_NAME,
then it MUST set the cname and realm fields of the
KRB_AS_REQ to match. Otherwise the initiator MUST
add a pa-data element (see below) stating the name
that the initiator wishes to assert, it MUST set the
cname field to the anonymous principal name, and it
MUST set the realm field to "WELLKNOWN:PKU2U" with
type "other" <xref target="KRB-NAMING"/>.</t>
<t>If the targ_name passed to GSS_Init_sec_context() is
of GSS_C_NT_ANONYMOUS type, then the sname field of
the AS-REQ SHALL be set to WELLKNOWN/WELLKNOWN with
name type KRB_NT_WELLKNOWN <xref
target="KRB-ANON"/>. If the targ_name passed to
GSS_Init_sec_context() is of type
GSS_C_NT_HOSTBASED_NAME then the initiator sets the
sname field to match the parsed name as per <xref
target="RFC4121"/>, and there is no notion of
server realm name in this case. In all other cases
the initiator MUST produce the exported name token
for the given targ_name and MUST include it as the
pa-value of an pa-data element whose pa-type SHALL
be <TBD>, and the initiator MUST set the sname
field of the AS-REQ to WELLKNOWN/WELLKNOWN with name
type KRB_NT_WELLKNOWN [KRB-ANON] -- the presence of
the targ_name pa-data element means the targ_name is
not of type GSS_C_NT_ANONYMOUS.</t>
<t>The token type ID for this token SHALL be 05 00.</t>
<t>The pa-data element for the initiator's name
assertion SHALL be of ad-type <TBD> and its
ad-value SHALL consist of the BER encoding of the
following:</t>
<figure>
<artwork>
InitiatorNameAssertion ::= CHOICE {
-- -1 -> certificate DN
-- 0..16384 -> subjectAltName named by
-- this index
sanIndex INTEGER (-1..16384),
nameNotInCert GeneralName -- from RFC3280
}
</artwork>
</figure>
<t>The acceptor MUST validate this token as a Kerberos V
KDC would validate a PKINIT AS-REQ, and also MUST
check that the initiator's asserted name is present
in the initiator's certificate or otherwise bound to
the initiator's certificate by out-of-band
negotiation (e.g., by a table lookup). Failure to
validate this token MUST cause
GSS_Accept_sec_context() to return an error and,
optionally, to output a KRB-ERROR context token as
per-RFC4121.</t>
</section>
<section anchor="as_rep" title="Context token derived from
KRB_AS_REP">
<t>When the initiator's initial context token is a
KRB_AS_REQ then the acceptor MUST reply with either
a KRB-ERROR token as per <xref target="RFC4121"/> or
a token derived from a KRB_AS_REP PDU <xref
target="RFC4120"/> constructed to respond to the
initiator's KRB_AS_REQ.</t>
<t>The acceptor MUST only accept PKINIT
pre-authentication. If the initiator's KRB_AS_REQ
token is valid, and the initiator's asserted name is
bound to the certificate (see <xref
target="as_req"/> and <xref target="naming"/>)
then the acceptor MUST select a certificate (if it
has more than one) which matches the initiator's
targ_name (or any certificate at all, if the
initiator's targ_name is the anonymous name), and
then the acceptor MUST construct a KRB_AS_REP as
usual for PKINIT, except that there is no
requirement to use a KDC certificate.</t>
<t>The initiator then validates this token according to
Section 3.1.5 of <xref target="RFC4120"/> and
Section 3.2.4 of <xref target="RFC4556"/>. The
inclusion of the EKU KeyPurposeId <xref
target="RFC3280"/> id-pkinit-KPKdc in the X.509
certificate in the response is not applicable when
PKU2U is used because there is no KDC involved in
this protocol. The initiator MUST verify that the
acceptor's certificate matches the targ_name passed
in to GSS_Init_sec_context().</t>
</section>
<section anchor="ap_exchange" title="Context tokens imported from
RFC4121">
<t>Once the initiator has a Kerberos V Ticket for the
acceptor the security context token exchange will
continue with those of the Kerberos V GSS-API
mechanism <xref target="RFC4121"/> with the
following modifications:</t>
<t>
<list style="symbols">
<t>the mechanism OID of PKU2U SHALL be used
instead of that of the Kerberos V GSS-API
mechanism;</t>
<t>a sub-session key MUST be included in the
initiator's Authenticator;</t>
<t>if the initiator's initial context token is a
KRB_AS_REQ token (i.e., not KRB_AP_REQ
token), then the Exts field in the
Authenticator of the KRB_AP_REQ-derived
token <xref target="GSS-EXTS"/> MUST contain
an extension of the type GSS_EXTS_FINISHED
(extension type ID <TBA>) and the
extension data contains a DER-encoded value
of the Kerberos V 'Checksum' type, where the
checksum (actually, a MAC, see <xref
target="RFC3961"/>) is taken over all
the preceding context tokens in this
exchange (including the InitialContextToken
header), concatenated in chronological order
(remember, GSS-API context token exchanges
are synchronous). The key usage number for
this checksum is KEY_USAGE_FINISHED (number
41).</t>
</list>
</t>
<t>The acceptor MUST process this token as usual for
RFC4121, except that if the context token exchange
included an AS eschange, then the acceptor MUST also
validate the GSS_EXTS_FINISHED and return an error
if it is not valid or not present. But if this is
the initial context token then the acceptor MUST
return an error if GSS_EXTS_FINISHED is present.</t>
<t>The GSS_EXTS_FINISHED (along with the ticket) binds
the second part of the context token exchange to the
first, and it binds the pa-data used in the request
as well (this needs to be done because PKINIT does
not bind pa-data other than PKINIT pa-data from the
request). GSS_EXTS_FINISHED also protects all
otherwise unauthenticated plaintext in Kerberos V
PDUs. Note that GSS_EXTS_FINISHED also protects the
mechanism OID in the InitialContextToken header.</t>
<figure>
<artwork>
KEY_USAGE_FINISHED 41
</artwork>
</figure>
</section>
</section>
<section title="Guidelines for Credentials Selection">
<t>If a peer, either the initiator or the acceptor, has
multiple pairs of public-key private keys, a choice is
to be made in choosing the best fit. The
trustedCertifiers field in the PA-PK-AS-REQ structure
<xref target="RFC4556"/> SHOULD be filled by the
initiator, to provide hints for guiding the selection of
an appropriate certificate chain by the acceptor.</t>
<t>If the initiator's X.509 certificate cannot be validated
according to <xref target="RFC3280"/>, the acceptor
SHOULD send back the TD-TRUSTED-CERTIFIERS structure
<xref target="RFC4556"/> that provides hints for guiding
the selection of an appropriate certificate by the
initiator. In this case GSS_Accept_sec_context()
returns GSS_S_CONTINUE_NEEDED, and the initiator gets
to try again in its subsequent AS-REQ token.</t>
<t>The GSS-API does not provide a way to make this
credential selection interactive, however, whenever the
context allows for direct interaction of the mechanism
with the user then it is RECOMMENDED that
implementations do so.</t>
<t>If the certificates cannot be selected interactively, and
multiple certificates can be used, it is RECOMMENDED
that initiators fail the context establishment thus
avoid confusions caused by an unexpected programmatic
selection. Users should be able to retry using a
specific credential (this requires that distinct
credentials have distinct names that can be used to
acquire each credential separately).</t>
</section>
<section anchor="seccons" title="Security Considerations" toc="default">
<t>The security considerations in <xref target="RFC4556"/>
apply here. This mechanism relaxes some requirements of
PKINIT and adds a device for protecting otherwise
unauthenticated plaintext in the protocol -- it is
crucial that this device be faithfully implemented. It
is also crucial that both the initiator and the acceptor
MUST be able to verify the binding between the signing
key and the associated identity. </t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Jeffrey Hutzelman for his
insightful comments on the earlier revisions of this
document.</t>
<t>In addition, the following individuals have provided
review comments for this document: Nicolas Williams, Sam
Hartman, Leif Johansson, Olga Kornievskaia, Martin Rex,
and Sunil Gottumukkala.</t>
<t> Ari Medvinsky provided help in editing the initial
revisions of this document.</t>
<t>The text for the DN mapping is compiled directly from the
email discussions among the following individuals:
Howard Chu, Martin Rex, Nicolas Williams, Jeffrey
Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson,
and Olga Kornievskaia. Howard and Jeffery clearly
illustrated the challenges in creating a unique mapping,
while Nicolas and Martin demonstrated the relevance and
interactions to GSS-API and Kerberos. </t>
</section>
<section anchor="iana" title="IANA Considerations">
<t><xref target="pku2urealm"/> defines the PKU2U realm. The
IANA registry for the reserved names should be updated
to reference this document.</t>
<t>This document defines GSS_EXTS_FINISHED extension type.
The corresponding IANA registry need to be updated to
reference this document. The following single
registration should be added in the registry for
"Kerberos V GSS-API mechanism extension types":
GSS_EXTS_FINISHED, "GSS-API token checksum", "Extension
to provide a checksum for GSS-API tokens", the RFC # of
this document.</t>
<t>This document also expands the existing GSS-API service
name registry, that IANA maintains, to have a an
assignment of one or more OIDs for each service name.
The id-kp-serverAuth OID <xref target="RFC3280"/> is
immediately registered as the OID for the "HTTP" service
name.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;&RFC0822;&RFC1034;&RFC3490;&RFC4120;&RFC4121;
&RFC2743;&RFC3280;&RFC1964;&RFC4556;&RFC3961;&RFC4514;
<reference anchor="GSS-EXTS">
<front>
<title>Kerberos Version 5 GSS-API Channel Binding Hash Agility</title>
<author initials="S." surname="Emery">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-krb-wg-gss-cb-hash-agility-03.txt"/>
</reference>
<reference anchor="KRB-ANON">
<front>
<title>Kerberos Anonymity Support</title>
<author initials="L." surname="Zhu">
<organization></organization>
</author>
<author initials="P." surname="Leach">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft"
value="draft-ietf-krb-wg-anon-04.txt"/>
</reference>
<reference anchor="KRB-NAMING">
<front>
<title>Additional Kerberos Naming Constraints</title>
<author initials="L." surname="Zhu">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft"
value="draft-ietf-krb-wg-naming-04"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:03:59 |