One document matched: draft-zhu-pku2u-03.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 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 RFC4178 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.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 RFC2253 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2253.xml'>
<!ENTITY RFC4346 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY RFC3961 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.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-03">
<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>
<date year="2007"></date>
<area>Security</area><workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines the public key cryptography based user-to-user authentication protocol - PKU2U.
This mechanism provides security services in peer to peer networking environments
without requiring a trusted third party. Furthermore, the binding of PKU2U for the Generic Security Service
Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. </t>
</abstract>
</front><middle>
<section anchor="introduction" title="Introduction">
<t> Peer-to-peer systems are increasingly popular today. In a peer-to-peer system,
all clients provide resources that contribute positively to the total capacity of the overall system and there is no single point of failure.
This distributed nature makes such systems highly scalable and robust. </t>
<t>A true peer-to-peer system is self-organized, typically there is no trusted third party in such environments.
Consequently the Kerberos protocol as defined in <xref target="RFC4120"/> and <xref target="RFC4556"/> is inadequate
to provide security services. Currently there is no interoperable GSS-API mechanism
for establishing trust in the information received from the peer.
The inability to authenticate the messages exchanged among peers enables
many attacks such as poisoning (e.g. providing data contents are different from the description) and
polluting (e.g. inserting "bad" packets).</t>
<t> To remedy this, the PKU2U protocol extends <xref target="RFC4120"/> and <xref target="RFC4556"/> to support
peer-to-peer authentication without the help of a Key Distribution Center (KDC) <xref target="RFC4120"/>.
In addition, the binding of PKU2U for GSS-API is defined based on <xref target="RFC4121"/>.</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 [KRB-NAME], and it has the value of
"RESERVED: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="pku2upn" title="PKU2U Kerberos Principal Names">
<t> If the X.509 certificate <xref target="RFC3280"/> of a peer contains an id-pkinit-san Subject
Alternative Name (SAN) as defined in Section 3.2.2
of <xref target="RFC4556"/> or an id-ms-sc-logon-upn SAN as defined in [REFERALS],
then the Kerberos Principal Name for the peer is as specified in that SAN in the certificate.</t>
<t>If the acceptor's X.509 certificate contains a dNSName SAN <xref target="RFC3280"/>, the acceptor's
Kerberos principal name is a two-components NT-SRV-HST type name as defined in Section 6.2.1 of <xref target="RFC4120"/>,
with the first component as "host" and the second component as the name in the dNSName SAN of
the certificate.</t>
<t>Otherwise unless otherwise specified, the peer's Kerberos principal name is of the NT-X500-PRINCIPAL type <xref target="RFC4120"/>, and
the name-string field <xref target="RFC4120"/> contains a single component whose value is a string representation
of the peer's Distinguished Name [X500] encoded according to <xref target="RFC2253"/>.
The Distinguished Name contained in the PKU2U Kerberos principal name MUST begin with the most specific attribute
and continue with progressively broader attrbiutes.</t>
</section>
<section anchor="protocol" title="The Protocol Description and the Context Establishment Tokens">
<t>The PKU2U protocol is based on <xref target="RFC4120"/>, and it can only be used in conjunction with GSS-API.</t>
<t> This section describes how PKU2U works and how it differs from <xref target="RFC4120"/>.</t>
<t>If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of <xref target="RFC4120"/>,
performs the client-server authentication exchange
according to <xref target="RFC4121"/> and Section 3.2 of <xref target="RFC4120"/>, with the acceptor acting as the server.</t>
<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 message, where
the acceptor is identified as the server and the initiator is identified as the client, according to Section 3.1.1 of <xref target="RFC4120"/>.
The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according to Section 3.2.1 of <xref target="RFC4556"/>.
In a modification to <xref target="RFC4120"/>,
the KRB_AS_REQ message is not sent directly to the acceptor, but instead returned within the output GSS-API token.
GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED status <xref target="RFC2743"/> indicating at least one more token is needed in order to establish the context,
and the KRB_AS_REQ message is returned as the innerContextToken defined in Section 3.1 of <xref target="RFC2743"/>, in the output token. </t>
<t> This output token that contains the KRB_AS_REQ message is then passed to GSS_Accept_security_context() as the input token in accordance with GSS-API.
The acceptor processes the KRB_AS_REQ request
according to Section 3.1.2 of <xref target="RFC4120"/>.
The acceptor MUST verify that the server name in the request is that of the acceptor itself.
The acceptor validates the pre-authentication data in the request according to Section 3.2.2 of
<xref target="RFC4556"/>. The acceptor MUST verify the binding between the initiator's name and
the initiator's public key. The initiator's X.509 certificate MUST contain the
id-pkinit-KPClientAuth <xref target="RFC4556"/> Extended Key Usage (EKU) extension or the id-kp-clientAuth EKU <xref target="RFC3280"/>. </t>
<t>If all goes well, processing the KRB_AS_REQ message will result in
the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section
3.1.3 of <xref target="RFC4120"/>.</t>
<t>If an error occurs, however, the response is a KRB_ERROR message generated according to Section 3.1.4 of <xref target="RFC4120"/>.</t>
<t>In other words, the output token of GSS_Accept_security_context()
is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented
a ticket from being issued. The reply token is then passed to the initiator as the input token
to GSS_Init_sec_context().</t>
<t>The initiator then processes the reply token according to Section 3.1.5 of <xref target="RFC4120"/> if a ticket has been returned.
Upon receipt of the KRB_AS_REP message, the initiator MUST validate the PA_PK_AS_REP pre-authentication data in the reply according to 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 the binding between the acceptor's name and the acceptor's public key.
</t>
<t>
Furthermore, PKU2U differs from <xref target="RFC4556"/> in that it allows the use of self-signed certificates given the binding between the named principal and the public
key can be verified and cannot be spoofed.</t>
<t>The GSS-API acceptor
is identified using the targ_name parameter <xref target="RFC2743"/> of the GSS_Init_sec_context() call, the initiator MUST verify the binding
between the targ_name and the acceptor in order to provide authentication of the acceptor. In addition,
the acceptor's X.509 certificate MUST contain the id-kp-clientAuth EKU <xref target="RFC3280"/> or id-kp-serverAuth EKU <xref target="RFC3280"/> or
the id-pkinit-KPClientAuth EKU <xref target="RFC4556"/>. </t>
<t> If an error message was returned, the initiator processes the response according to Section 3.1.6 of <xref target="RFC4120"/>.</t>
<t>With the obtained ticket, the initiator then, acting as the client in the parlance of <xref target="RFC4120"/>, performs the client-server authentication exchange
according to <xref target="RFC4121"/> and Section 3.2 of <xref target="RFC4120"/>, with the acceptor acting as the server.</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>The syntax of the initial context establishment token follows 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>
<artwork>
id-kerberos-pku2u ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
pku2u(7) }
</artwork>
</figure>
<t> Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic
token framing.</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 <xref target="RFC4120"/> 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, thus provide
functional equivalency of Transport Layer Security (TLS) <xref target="RFC4346"/>.</t>
</section>
<section title="The GSS-API Binding for PKU2U">
<t><xref target="protocol"/> defines the context establishment tokens. PKU2U per-message tokens are defined as the per-message tokens in <xref target="RFC4121"/>.</t>
<t> The Kerberos principal name form and the host-based service Name described in <xref target="RFC1964"/> MUST
be supported by implementations conforming to this specification.</t>
<t> When the Kerberos principal name type is NT-X500-PRINCIPAL <xref target="RFC4120"/>, the name-string field
contains a single component that is a string representation of a Distinguished Name [X500].
The single string representation of an NT-X500-PRINCIPAL Kerberos principal name is computed as follows: the Kerberos principal name is first
converted to a single string according to Section 2.1.1 of <xref target="RFC1964"/> and then enclosed in a pair of
open and close angle brackets. For example, the following string is a single-string representation of a user:</t>
<figure>
<artwork>
CN=Larry, O=Microsoft, L=Redmond, S=Washington, C=US
</artwork>
</figure>
<t> For implementations comforming to this specification, the authenticator subkey in the AP-REQ <xref target="RFC4120"/> <xref target="RFC4121"/> MUST alway be present,
and the Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an extension of the type GSS_EXTS_FINISHED
and the extension data contains the ASN.1 DER encoding of the structure KRB-FINISHED. </t>
<figure>
<artwork>
GSS_EXTS_FINISHED 1
--- The type for the checksum extension.
KRB-FINISHED ::= {
gss-mic [1] Checksum,
-- Contains the checksum of the GSS-API tokens
-- exchanged between the initiator and the acceptor,
-- and prior to the containing AP-REQ [RFC4120]
-- GSS-API token.
-- The checksum is performed over the GSS-API
-- tokens in the order that the tokens were sent.
...
}
</artwork>
</figure>
<t>The gss-mic field in the KRB-FINISHED structure contains a checksum of all the GSS-API
tokens exchanged between the initiator and the acceptor, and prior to the GSS-API token containing the AP-REQ <xref target="RFC4120"/>.
This checksum is performed over these GSS-API tokens in the order that the tokens were sent.
In the parlance of <xref target="RFC3961"/>, the checksum type is the required checksum type
for 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 42
</artwork>
</figure>
<t> The GSS-API acceptor MUST then verify
the checksum contained in the GSS_EXTS_FINISHED extension. This checksum provides
integrity protection for the messages exchanged including
the unauthenticated clear texts in the Kerberos messages exchanged between the two parties.</t>
</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. 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.</t>
<t>It is RECOMMENDED that implementations of this protocol expose sufficient information based on the hints described above to the
users and allow the certificates to be selected interactively. </t>
<t>If the certificates cannot be selected interactively, and multiple certificates can be used, it is RECOMMENDED that implementations fail the context establishment thus avoid
confusions caused by an unexpected programmatic selection.</t>
</section>
<section anchor="securityconsideration" title="Security Considerations" toc="default">
<t> The security considerations in <xref target="RFC4556"/> apply here.
It is crucial that both the initiator and the acceptor MUST be able to verify the binding between the signing key and the associated identity. </t>
<t>Any of the attributes defined in the directory schema may be used to make up a Distinguished Name. The order of the component attribute value pairs is important.
PKU2U requires that the most specific attribute comes first in the Distinguished Name. The security considerations in Section 7 of <xref target="RFC2253"/> apply.</t>
<t>The string representation of Distinguished names in PKU2U requires
that the most specific attribute comes first. This assumes that the Distinguished Names are
defined in a hierarchical manner such that the closer to the leaf entity the more specific the name attribute component is.
Incorrect interpretation of the attribute order could cause permissions granted to a principal that otherwise do not entitle to thus result in a security weakness.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Jeffery Hutzelman for his insightful comments on the earlier revisions of this document.</t>
<t> Ari Medvinsky provided help in editing the initial revisions of this document.</t>
</section>
<section 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>
</section>
</middle>
<back>
<references title="Normative References">&RFC2119;&RFC4120;&RFC4121;&RFC2743;&RFC4178; &RFC3280;&RFC1964; &RFC4556;&RFC2253;&RFC4346; &RFC3961;
<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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:05:26 |