One document matched: draft-zhu-pku2u-08.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 RFC2744 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2744.xml'>
<!ENTITY RFC5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.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 RFC4401 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4401.xml'>
<!ENTITY RFC4402 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4402.xml'>
<!ENTITY RFC4514 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4514.xml'>
<!ENTITY RFC4517 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
<!ENTITY X680 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X680.2002.xml'>
<!ENTITY X690 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.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-08">
<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 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="RFC5280"/>, 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="RFC5280"/>) 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>The PKU2U realm name has no meaning, but is intended to be
used in the Kebreros V PDUs that are re-used by PKU2U
wherever realm names are needed. Unless otherwise
specified, the realm name in any Kerberos message used by
PKU2U is the PKU2U realm name.</t>
</section>
<section anchor="null_name" title="The NULL Principal Name">
<t>The NULL Kerberos principal name is defined as a well-known
Kerberos principal name based on <xref
target="KRB-NAMING"/>. The value of the name-type field
is KRB_NT_WELLKNOWN <xref target="KRB-NAMING"/>, and the
value of the name-string field is a sequence of two
KerberosString components: "WELLKNOWN", "NULL".</t>
<t>The NULL Kerberos principal name is used in the Kerberos
messages where there is no Kerberos representation of the
principal name, for example, when the client name is a
Distinguished Name. When the NULL principal name is used in
the Kerberos messages, the principal name is either not used
or provided separately (for example in the PA-PKU2U-NAME
padata defined in <xref target="as_req"/>).</t>
</section>
<section anchor="naming" title="PKU2U Principal Naming">
<t>PKU2U principal names can be Kerberos principal names, and
they can also be distiguished names, or subject alternative
names <xref target="RFC5280"/> as they appear in the
certificate of any PKU2U peer, as well as any names agreed
to out of band that do not appear in the peer
certificates.</t>
<t>Certificates may be associated with multiple principal names.
This presents problems for the GSS-API bindings of a
PKI-based mechanism because, for example, for any given,
established GSS-API security mechanism there can be only one
initiator name, and one acceptor name, and credential
handles may be associated with only one name. 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="RFC5280"/>,
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 DER-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 query and display syntaxes, canonicalization
rules, and exported name token format.
<vspace blankLines="1"/></t>
<t>The cred_name of a credential handle acquired with
GSS_C_NT_NO_NAME as the desired_name SHOULD be the DN of
the certificate underlying the credential. If there are
multiple certificates and private keys, then either one MUST be
selected as the default credential by local,
implementation-specific means, or credential acquisition
with GSS_C_NT_NO_NAME MUST fail (implementors may choose
which of these two behaviors to provide).
<vspace blankLines="1"/></t>
<t>When using desired_name values other than
GSS_C_NT_NO_NAME for credential handle acquisition then
the implementation MUST use exact matching of the given
desired_name to a certificate's DN or SANs for all
name-types given below, except for GSS_C_NT_DN, where
matching rules are fuzzier and given below. The names
of a cert will be compared to the given desired_name in
this order: certificate DN first, then
subjectAlternativeNames in the order in which they
appear in the certificate. When multiple certificates
and private keys are available the order in which the
various certificates are searched is significant; no
canonical certificate collation order is defined herein.
<vspace blankLines="1"/></t>
<t>The cred_name of a credential object acquired with a
desired_name other than GSS_C_NT_NO_NAME MUST be equal
to the certificate DN or SAN matched by the given
desired_name.
<vspace blankLines="1"/></t>
<t>We provide a method (see below) by which initiators can
assert, in their context tokens, one of these names of
the initiator. We also provide a method of asserting
names that do not appear in a X.509 certificate, in
which case the binding of X.509 certificate to the
asserted name is done out-of band. The name to be
asserted, of course, is the cred_name of the cred_handle
passed to GSS_Init_sec_context().
<vspace blankLines="1"/></t>
<t>The initiator's context tokens may also indicate what is
the expected name of the acceptor -- the targ_name
passed in to GSS_Init_sec_context().
<vspace blankLines="1"/></t>
<t>We provide support for targ_name = GSS_C_NO_NAME in
GSS_Init_sec_context(). In this case the resulting
security context's acceptor's name will be the DN of its
certificate.
<vspace blankLines="1"/></t>
<t>No attempt is made to map Kerberos V realm names to trust
anchor certificate authority (CA) names.
<vspace blankLines="1"/></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, c) existing
certificates for web servers, may be used as host-based
service principal names as though the service name were
"HTTP".</t>
</list>
</t>
<t>Thus GSS-API initiator applications 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 X.509
certificate's subject DN, and that X.509 certificate's
subject 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 X.509 certificates
predating this specification.</t>
<section anchor="name_DN" title="GSS_C_NT_DN">
<t>The name type GSS_C_NT_DN, with OID <TBD> (see
<xref target="iana"/>), is defined. This corresponds to
the 'directoryName' choice of the 'GeneralName' ASN.1
<xref target="CCITT.X680.2002"/> type defined in <xref
target='RFC5280'/>.</t>
<t>The query syntax and display form for names of this type
SHALL be as described in <xref target='RFC4514'/>.</t>
<t>As RFC4514 says, "[c]omparison of DNs for equality is to
be performed in accordance with the
distinguishedNameMatch matching rule <xref
target='RFC4517'/>.</t>
<t>There is no reasonable way to canonicalize names of this
type without providing certificates to match query forms
of GSS_C_NT_DN against, such as in the form of a
directory. Therefore GSS_Canonicalize_name() as applied
to names imported with the GSS_C_NT_DN name-type MUST
search available certificate databases, or directories,
or MUST fail. No method of locating and searching
directories for matching certificate DNs is specified
herein. Note though that GSS_Inquire_cred_by_mech() and
GSS_Inquire_sec_context() can and, indeed, MUST return
"mechanism names" (MN; ; see <xref
target="RFC2743"/>).</t>
<t>The exported name token format for names of this type
SHALL be the DER <xref target="CCITT.X680.2002"/> <xref
target="CCITT.X690.2002"/> 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>The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is
defined. This corresponds to the 'dNSName' choice of the
'GeneralName' ASN.1 type defined in <xref
target='RFC5280'/>.</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. Canonicalization consists
merely of applying the toACE() function and case-folding
the result.</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_rfc822Name" title="GSS_C_NT_EMAIL_ADDR">
<t>The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>,
is defined. This corresponds to the 'rfc822Name' choice
of the 'GeneralName' ASN.1 type defined in <xref
target='RFC5280'/>.</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. Note that the
domainname part of an addr-spec is a "domainname slot"
and so the canonicalization rules for GSS_C_NT_HOSTNAME
given above apply here as well.</t>
<t>The exported name token form for this name type SHALL be
the DER-encoding of a GeneralName with the rfc822Name
choice.</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'/>.</t>
<t>The query, display, canonical and exported name token
forms of names of this type SHALL be as specified in
RFC4121. The realm name part of
GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the
query syntax; when canonicalized, names of this type
lacking a realm name will have the well-known PKU2U
realm name affixed.</t>
<t>When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME
is defaulted or otherwise is the well-known PKU2U realm
name, then the ''cname'' or sname fields of the Kerberos
V PDUs used to construct PKU2U security context tokens
MUST be set to the principal name part of the given
NAME. Otherwise the PA-PKU2U-NAME pre-authentication
data MUST be used to indicate a name of id-pkinit-san
type <xref target='RFC4556'/> corresponding to the given
NAME. See <xref target="name_krb5"/>.</t>
<t>No attempt is made to map Kerberos V realm names to trust
anchor certificate authority (CA) names.</t>
<t>Note that having more than one mechanism share name-types
has implications for multi-mechanism, pluggable GSS-API
implementations (commonly referred to as "mechglue").
Specifically:
<vspace blankLines="1"/>
<list style='symbols'>
<t>It must be the responsibility of the mechanism,
not of the mechglue, to ensure that the standard
exported name token header (which includes a
mechanism OID), is included in exported name
tokens. Otherwise the exported name token for a
GSS_KRB5_NT_PRINCIPAL_NAME MN produced by PKU2U
would have PKU2U's mechanism OID in the header,
instead of the Kerberos V mechanism's OID.</t>
<t>A pluggable mechglue must be able to find a
mechanism that can import an exported name token
if an available mechanism can produce that
exported name token. For example, a pluggable
mechglue where PKU2U is available but where the
Kerberos V mechanism <xref target='RFC1964'/> is
not should still be able to import exported
Kerberos V name tokens since PKU2U can create
such tokens. One way to do this would be for
the mechglue to try the mechanism named in the
exported name token header, if it is available,
else try all other available mechanisms until
one succeeds or all fail. It would be
reasonable for a mechglue implementor to require
that the Kerberos V mechanism be available if
PKU2U is too.</t>
<t>It must be possible for GSS_Acquire_cred(),
GSS_Add_cred() to use a Kerberos V "mechanism
name" (MN; see <xref target="RFC2743"/>) as
desired_name argument value to acquire a PKU2U
credential. Similarly, it must be possible to
use a Kerberos V MN as the target_name in a call
to GSS_Init_sec_context with PKU2U as the mech
OID. A multi-mechanism mechglue implementor
would likely have a mechglue-layer NAME object
that internally keeps a reference to a NAME
object produced by the underlying mechanism, but
a pluggable mechglue could not expect two
different mechanisms to be able to share their
internal NAME objects. A clever implementor can
work around this by exporting the one
mechanism's MN and then re-importing using the
target mechanism's GSS_Import_name() service
function.</t>
<t>It must be possible for the credential inquiry
functions (e.g., GSS_Inquire_cred() and
GSS_Inquire_cred_by_mech()) to return a
cred_name that is an MN of a different mechanism
than the credential element being inquired.</t>
</list>
</t>
<t>Implementation support for this name type, with defaulted
realm name or with the PKU2U realm name is
REQUIRED, but it is OPTIONAL for use with any other
realm names.</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>
<t>See <xref target="RFC2743"/> and <xref target="RFC2744"/>
for more information about this name type.</t>
<t>The PKU2U mechanism only supports anonymous initiators,
not acceptors.</t>
<t>Implementation support for this name type is
RECOMMENDED.</t>
</section>
<section anchor="hostbased" title="GSS_C_NT_HOSTBASED_SERVICE -
Matching Host-based Principal Names to Acceptor
Certificates">
<t>Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED
as described herein.</t>
<t>The query form of this name type is as per-RFC2743. The
canonical and exported name token forms are as
per-RFC1964. The display form of this name type is left
unspecified, but should either be as per-RFC2743 or the
same as the display form for GSS_KRB5_NT_PRINCIPAL_NAME
<xref target="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='RFC1964'/> but with a well-known realm name
of "WELLKNOWN:PKU2U" (see <xref target="name_krb5"/>).</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, in order, to validate the
initiator's assertion.</t>
<t>
<list style="numbers">
<t>If there is an out-of-band binding of the peer's
host-based service name to its certificate, then
the certificate matches.
<vspace blankLines="1"/></t>
<t>If the peer has a certificate with an
id-pkinit-san subject alternative name matching
the initiator-provided acceptor name, then the
X.509 certificate matches.
<vspace blankLines="1"/></t>
<t>If a X.509 certificate has 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
X.509 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.)
<vspace blankLines="1"/></t>
<t>Implementations SHOULD, subject to local
configuration, allow matches where the
single-component cn of the DN of a X.509
certificate 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 X.509 web certificates.</t>
</list>
</t>
<t>Implementation support for this name type as an acceptor
name is REQUIRED. Implementation support for this name
type as an initiator name is OPTIONAL.</t>
</section>
<section anchor="unspec_targ_names" title="Unspecified Target Names">
<t>When the initiator uses GSS_C_NO_NAME as the target name
then it MUST use the NULL name (see <xref
target="null_name"/>). See <xref target="as_req"/>
for information on naming padata in this case.</t>
<t>The acceptor name associated with the resulting security
context MUST be the DN of the acceptor's
certificate.</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 GSS_Pseudo_random() function <xref target="RFC4401"/> of
the PKU2U is the same as that of the Kerberos V GSS-API
mechanism <xref target="RFC4402"/>.</t>
<t>The PKU2U security context token exchange consists of
KRB-AS-REQ and KRB-AS-REP (and KRB-ERROR) Kerberos KDC PDUs
(with no changes to their ASN.1 description, but with other
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 in this document. Caching the
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 reconnect" feature.</t>
<t>PKU2U differs from Kerberos V with PKINIT in several minor
ways as follows (this is not a complete list):</t>
<t>
<list style='symbols'>
<t>KDC PDUs are not exchanged as usual in Kerberos, but
wrapped as [the first two] GSS-API context tokens.
<vspace blankLines="1"/></t>
<t>PKU2U does not use KDC certificates.
<vspace blankLines="1"/></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 described in <xref
target="RFC4120"/>, but wrapped as GSS-API
context tokens.
<vspace blankLines="1"/></t>
<t>PKU2U allows the use of principal names matching PKI
naming (see <xref target="naming"/>). PKU2U does
support the use of Kerberos V naming, but requires
only support of Kerberos V naming to a limited
extent (full support is optional).
<vspace blankLines="1"/></t>
<t>PKU2U adds an extension <xref target="GSS-EXTS"/> 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). <vspace blankLines="1"/></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 X.509 certificate does not match
the acceptor's trust anchors, in which case the
acceptor SHOULD 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 GSS-API
context.</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. In the event of security context token loss,
message duplication, or out of order message delivery, the
security context MUST fail to establish.</t>
<t>All security 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>
<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>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>
<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>It should be noted that by using anonymous PKINIT <xref
target="KRB-ANON"/>, PKU2U can authenticate the acceptor
without revealing the initiator'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 from 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>The initiator MUST NOT set any KDC options in the
'kdc-options' field of the AS-REQ.</t>
<t>The 'from', 'rtime', 'addresses',
'enc-authorization-data', and 'additional-tickets'
fields of the AS-REQ MUST be absent.</t>
<t>The 'till' field of the AS-REQ MUST be set to either
"19700101000000Z" (see <xref target="RFC4120"/>, section
5.4.1), or "19700101000001Z". The latter indicates that
the initiator would like a ticket valid for a single
use.</t>
<t>The 'realm' field of the AS-REQ MUST be set to the PKU2U
well-known PKU2U realm name ("WELLKNOWN:PKU2U" <xref
target="KRB-NAMING"/>.</t>
<t>If the initiator wishes to assert a name of type
GSS_C_NT_ANONYMOUS then it MUST set the AS-REQ's 'cname'
field to the anonymous principal name <xref
target="KRB-ANON"/>, and it MUST NOT use a X.509
certificate <xref target="KRB-ANON"/>. If the initiator
wishes to assert a name of type
GSS_KRB5_NT_PRINCIPAL_NAME or
GSS_C_NT_HOSTBASED_SERVICE, then it MUST set the 'cname'
field of the AS-REQ accordingly if and only if the realm
name part of the given name object is defaulted or the
well-known PKU2U realm name. 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 NULL principal name as defined in
<xref target="null_name"/>.</t>
<t>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 of the AS-REQ to match the parsed name as
per <xref target="RFC4121"/>. If the target name is not
sepecified (GSS_C_NO_NAME) or does not have a
representation as a Kerberos principal name per <xref
target="RFC1964"/>, then the initiator MUST add a
pa-data element (see below) stating the given targ_name
and the initiator MUST set the 'sname' field of the
AS-REQ to the NULL principal name as defined in <xref
target="null_name"/>.</t>
<t>The padata used to convey initiator and target names is
of type PA-PKU2U-NAME and it's value consists of the DER
<xref target="CCITT.X680.2002"/> <xref
target="CCITT.X690.2002"/> encoding of the ASN.1
type InitiatorNameAssertion (with explicit tagging).</t>
<figure>
<artwork>
InitiatorName ::= CHOICE {
-- -1 -> certificate DN
-- 0..16384 -> subjectAltName named by
-- this index
sanIndex INTEGER (-1..16384), -- DN or SAN
nameNotInCert GeneralName, -- name not present in cert
-- (see RFC5280 for definition
of GeneralName)
...
}
TargetName ::= CHOICE {
exportedTargName OTCET STRING, -- exported krb5 name
generalName [0] GeneralName, -- all other PKI names
-- (tagged to distinguish
-- from nameNotInCert
-- choice of InitiatorName)
...
}
InitiatorNameAssertion ::= SEQUENCE {
initiatorName InitiatorName OPTIONAL,
targetName TargetName OPTIONAL,
...
}
</artwork>
</figure>
<t>The initiatorName, if present, contains the initiator's
name. The initiator can fill out either the sanIndex
field or the nameNotInCert field to indicate the name of
the initiator.</t>
<t>The sanIndex field, if present, is used to refer to
either the Distinguished Name or the SubjectAltName in
the initiator's X.509 certificate. A sanIndex value of
-1 value refers to the initiator's certificate's DN.
All other legal values of sanIndex refer to the
corresponding element of the SubjectAltName sequence. A
value of 0 means the first instance of GeneralName in
the SubjectAltName sequence, and 1 means the second, and
so on. If the sanIndex value is equal or biger than the
number of GeneralName elements in the SubjectAltName,
the security context establishment attempt MUST fail.</t>
<t>The nameNotInCert field, if present, contains the
initiator's GeneralName.</t>
<t>If an initiator name assertion is included, the acceptor
MUST verify that this asserted name is either present in
the initiator's certificate or otherwise bound to the
initiator's certificate by out-of-band provisioning
(e.g., by a table lookup). Failure to validate the
asserted initiator's name MUST cause
GSS_Accept_sec_context() to return an error and,
optionally, to output a KRB-ERROR context token as
per-RFC4121.</t>
<t>The initiatorName field MUST NOT be present if the
initiator is anonymous or if the 'cname' field of the
AS-REQ is not the NULL name (see <xref
target="null_name"/>).</t>
<t>Target names passed to GSS_Init_sec_context() that can be
represented as Kerberos V principal names, namely, names
of GSS_KRB5_NT_PRINCIPAL_NAME and
GSS_C_NT_HOSTBASED_SERVICE, MUST be represented as the
'sname' field of the AS-REQ or as the exportedTargName
choice of TargetName (if the realm part is not the PKU2U
realm name). The contents of the exportedTargName octet
string MUST be an exported name token for the Kerberos V
mechanism containing a Kerberos V principal name.</t>
<t>Other target names are represented as a generalName
choice of TargetName. These may be present in an
acceptor certificiate, or agreed out of band.</t>
<t>The acceptor MUST select an appropriate acceptor
credential that matches the AS-REQ's 'sname' (if not
NULL) or the targetName provided in the
InitiatorNameAssertion, when present. If the 'sname' is
NULL and the targetName is not present then any
certificate will do.</t>
<t>The targetName field MUST NOT be present if the 'sname'
field of the AS-REQ is not the NULL name. The
targetName field MUST be present if the 'sname' field of
the AS-REQ is the NULL name and targ_name is not
GSS_C_NO_NAME.</t>
<t>The PA-PKU2U-NAME padata SHOULD NOT be present when the
initiatorName and targetName both shouldn't be
present. Acceptors MUST ignore PA-PKU2U-NAME padata
when it should not be present (but it must still be
integrity protected).</t>
<t>Implementation note: the encrypted part of a PKU2U Ticket
can be anything at all since the only entity that will
consumer a given PKU2U Ticket is the same entity that
issued it. Implementors may choose to use the
traditional EncTicketPart ASN.1 type <xref
target="RFC4120"/> and DER encoding </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 initiator MUST use PKINIT pre-authentication and the
acceptor MUST require it. If the initiator does not use
PKINIT pre-authentication then the acceptor MAY respond
with a KRB-ERROR, and MAY, but need not indicate that
PKINIT is required.</t>
<t>If the initiator's KRB-AS-REQ token is valid, and the
asserted initiator's name, if present, is bound with the
initiator's certificate, and the acceptor can select a
certificate based on the initiator's asserted targ_name,
the acceptor then constructs a KRB-AS-REP using PKINIT
as described in <xref target="RFC4556"/>, except that
the acceptor's certificate is used in the place of the
KDC certificate. If and only if the initiator's X.509
certficate is validated using PKI, the acceptor SHOULD
include an authorization element AD_INITIAL_VERIFIED_CAS
in the returned ticket [XXX - Why do we care what
authz-data is on PKU2U Tickets?].</t>
<t>The initiator then validates the KRB-AS-REP reply context
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="RFC5280"/> 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 is bound with the targ_name
passed in to GSS_Init_sec_context(), by verifying either
the targ_name matches with either the subject DN or one
instance of the SubjectAltName name in the acceptor's
certificate, or otherwise the targ_name is bound with
the acceptor's certificate by out-of-band provisioning
(e.g., by a table lookup). Failure to validate this
name binding MUST cause the authentication to be
rejected.</t>
<t>The 'last-req' field of the AS-REP MUST be an empty
SEQUENCE.</t>
<t>The 'key-expiration' field of the AS-REP MUST be
absent.</t>
<t>The 'flags' field of the AS-REP MUST have only the
'initial' and 'pre-authent' flags set.</t>
<t>The 'authtime' field of the AS-REP MUST be set to the
acceptor's current time as it is when it formats the
AS-REP. The 'starttime' and 'renew-till' fields of the
AS-REP MUST be absent. As usual with Kerberos V, the
'endtime' field of the AS-REP indicates when the issued
Ticket will expire, but the acceptor MAY set it to the
same time as the starttime field to indicate that the
issued Ticket may not be reused for other security
context establishment attempts.</t>
<t>The 'caddr' field of the AS-REP MUST be absent.</t>
<t>Otherwise all other aspects of the AS-REP are as
described in <xref target="RFC4120"/>.</t>
<t>The values of the tkt-vno, realm and 'sname' fields of
the Ticket issued by the acceptor are unspecified. The
initiator MUST NOT examine them for correctness.
Cut-n-paste attacks are prevented by the fact that PKU2U
provides integrity protection for all cleartext in
Kerberos V PDUS used by PKU2U (and for the mechanism
OID).</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;
<vspace blankLines="1"/></t>
<t>The 'cname' and 'crealm' fields of the
initiator's Authenticator MUST be set to the
NULL name and the PKU2U realm name,
respectively; <vspace blankLines="1"/></t>
<t>The sub-session key MUST be included in the
initiator's Authenticator;
<vspace blankLines="1"/></t>
<t>The 'ap-options' field of the AP-REQ MUST have
the 'use-session-key' (see above) and
'mutual-required' flags set.
<vspace blankLines="1"/></t>
<t>The contents of the encrypted part of the Ticket
can be implementation specific since the only
entity consuming it will be the same entity that
issues it;
<vspace blankLines="1"/></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 MUST contain an
extension <xref target="GSS-EXTS"/> of the type
GSS_EXTS_FINISHED as defined next in this
section.</t>
</list>
</t>
<t>The 'cusec', 'ctime', 'seq-number' and
'authorization-data' fields of the Authenticator are set
as per <xref target="RFC4121"/> and <xref
target="RFC4120"/>.</t>
<t>The 'cksum' field of the Authenticator MUST be set as per
<xref target="RFC4121"/>. The extension data of the
GSS_EXTS_FINISHED extension type <xref
target="GSS-EXTS"/> contains the DER encoding of the
ASN.1 structure KRB-FINISHED.</t>
<figure>
<artwork>
GSS_EXTS_FINISHED 2
--- The type for the checksum extension.
KRB-FINISHED ::= SEQUENCE {
gss-mic [1] Checksum,
-- Contains the checksum (RFC3961) of the GSS-API tokens
-- that have been exchanged between the initiator and the
-- acceptor and prior to the containing AP-REQ GSS-API token.
-- The checksum is performed over the GSS-API
-- context tokens in the order that the tokens were sent.
...
}
</artwork>
</figure>
<t>The gss-mic field contains a Kerberos checksum <xref
target="RFC3961"/> that is computed over all the
preceding context tokens of this GSS-API context
(including the InitialContextToken header), concatenated
in chronological order (note that GSS-API context token
exchanges are synchronous). The checksum type is the
required checksum type of the enctype of the subkey in
the authenticator, the protocol key for the checksum
operation is the authenticator subkey, and the key usage
number is KEY_USAGE_FINISHED.</t>
<figure>
<artwork>
KEY_USAGE_FINISHED 41
</artwork>
</figure>
<t>The acceptor MUST process the KRB-AP-REQ 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 a KRB-AP-REQ
context token 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>
</section>
<section anchor="authz-data" title="Authorization-Data Type to
Aid Acceptor Implementors">
<t>The issuer of a PKU2U Ticket is the only possible
consumer for it. Therefore the contents of the
encrypted part of a PKU2U Ticket can be anything at all,
to the convenience of the implementor.</t>
<t>However, many PKU2U implementors will likely begin with a
Kerberos V implementation and will likely re-use the
EncTicketPart ASN.1 type from <xref target="RFC4120"/>.
Such implementors, if they wish to support PKU2U Ticket
re-use, will need a way to store information about the
initiator, as well as the acceptor name that should be
associated with any security context established with a
re-used PKU2U Ticket.</t>
<t>As an aid to implementors, we reserve three Kerberos V
authorization-data types, AD-PKU2U-INFO-1,
AD-PKU2U-INFO-2, and AD-PKU2U-INFO-3. An implementor
might, for example, store the initiator's certificate in
AD-PKU2U-INFO-1, an exported name token for the
initiator's name in AD-PKU2U-INFO-2, and an exported
name token for the acceptor's name in
AD-PKU2U-INFO-3.</t>
<t>The numbers for these three authorization-data types are:
<list style='symbols'>
<t><TBD> (AD-PKU2U-INFO-1)</t>
<t><TBD> (AD-PKU2U-INFO-2)</t>
<t><TBD> (AD-PKU2U-INFO-3)</t>
</list>
</t>
</section>
<section anchor="errors" title="Errors">
<t>Some Kerberos V error codes in KRB-ERROR replies to
AP-REQ initial security context tokens are fatal, and
some are not. All Kerberos V error codes in KRB-ERROR
replies to AP-REQ non-initial security context tokens
are fatal. All Kerberos V error codes in KRB-ERROR
replies to AS-REQ initial security context tokens are
non-fatal. All error codes in KRB-ERROR replies to
AS-REQ non-initial security context tokens are
fatal.</t>
<t>When the acceptor produces a KRB-ERROR PDU
with a fatal error code then GSS_Accept_sec_context()
GSS_S_FAILURE, and the GSS_Init_sec_context() MUST
return GSS_S_FAILURE upon consuming the KRB-ERROR.</t>
<t>The following Kerberos V error codes in KRB-ERROR replies
to AP-REQ initial security context tokens are non-fatal:
<list style='symbols'>
<t>KRB_AP_ERR_TKT_EXPIRED</t>
<t>KRB_AP_ERR_REPEAT</t>
<t>KRB_AP_ERR_BADMATCH</t>
<t>KRB_AP_ERR_BADVERSION</t>
<t>KRB_AP_ERR_MSG_TYPE</t>
<t>KRB_AP_ERR_MODIFIED</t>
<t>KRB_AP_ERR_BADKEYVER</t>
<t>KRB_AP_ERR_NOKEY</t>
<t>KRB_AP_ERR_MUT_FAIL</t>
</list>
</t>
<t>All other Kerberos V KRB_AP_ERR_* error codes in
KRB-ERROR replies to AP-REQ initial security context
tokens are fatal.</t>
<t>Implementation note: PKU2U acceptors may use the
KRB_AP_ERR_BADKEYVER error code to indicate that the
Ticket used by the initiator is stale. PKU2U Tickets
may become stale at any time due to implementation
specific events (e.g., when the application starts it
generates ephemeral keys for encrypting the encrypted
parts of PKU2U Kerberos V Tickets, and it loses the
previous keys whenever it restarts).</t>
</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 and certificates, 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="RFC5280"/>, 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 programming interface to make
this credential selection interactive, though implementors
may provide methods for user interaction related to
credential selection and acquisition (e.g., name and
password/PIN prompts). Whenever the execution context
allows for direct interaction of the mechanism with the user
then it is RECOMMENDED that implementations interact with
the user to select a credential whenever multiple
credentials are equally usable and no other mechanism is
available to inform the credential selection.</t>
<t>If the certificates cannot be selected interactively,
multiple certificates are equally usable, and there is no
other mechanism available for credential selection, then it
is RECOMMENDED that initiators fail the context. 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="RFC4120"/>,
<xref target="RFC4121"/>, <xref target="RFC4556"/> and <xref
target="RFC5280"/> apply here. This mechanism relaxes
some requirements of PKINIT and adds a device for protecting
otherwise unauthenticated plaintext in the protocol (see
<xref target="ap_exchange"/>) -- 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 asserted
identity.</t>
<t>Note that PKU2U is just as susceptible to replays of AP-REQs
as the traditional Kerberos V GSS-API mechanism <xref
target="RFC4121"/>, though only when using an AP-REQ as
the initial security context token. It is important,
therefore, to use a replay cache to detect replays.</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: 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 from the email
discussions among the following individuals: Howard Chu,
Martin Rex, 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>This document defines the PKU2U realm and the place-holder
well-known principal name. The IANA registry for the
reserved names should be updated to reference this document.
Two entries are added: one entry for the well-known realm
"WELLKNOWN:PKU2U", and another for the well-known principal
name "WELLKNOWN/NULL".</t>
<t>This document defines GSS_EXTS_FINISHED extension type. The
corresponding IANA registry <xref target="GSS-EXTS"/> 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": 2, "GSS-API
token checksum", "Extension to provide a checksum for
GSS-API tokens", the RFC # of this document.</t>
<t>This document also instructs the IANA to extend the "SMI
Security for Name System Designators Codes (nametypes)"
registry to include an OID for each registration, and to
allocate OIDs for the following GSS-API name-types in that
registry:
<list style='symbols'>
<t>gss-distinguished-name (GSS_C_NT_DN)</t>
<t>gss-hostname (GSS_C_NT_HOSTNAME)</t>
<t>gss-IP-address (GSS_C_NT_IP_ADDR)</t>
<t>gss-e-mail-address (GSS_C_NT_EMAIL_ADDR)</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;&RFC0822;&RFC1034;&RFC3490;&RFC4120;&RFC4121;
&RFC2743;&RFC2744;&RFC5280;&RFC1964;&RFC4556;&RFC3961;
&RFC4401;&RFC4402;&RFC4514;&RFC4517;
&X680;&X690;
<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"/>
</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"/>
</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"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:03:45 |