NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation
Intended status: Standards Track J. Altman
Expires: July 30, 2008 Secure Endpoints
January 27, 2008
Public Key Cryptography Based User-to-User Authentication - (PKU2U)
draft-zhu-pku2u-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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
Kerberos Key Distribution Center (KDC). Furthermore, the binding of
PKU2U for the Generic Security Service Application Program Interface
(GSS-API) per RFC2743 is defined based on RFC4121.
Zhu & Altman Expires July 30, 2008 [Page 1]
Internet-Draft PKU2U January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3
4. PKU2U Principal Names . . . . . . . . . . . . . . . . . . . . 4
5. The Protocol Description and the Context Establishment
Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. The GSS-API Binding for PKU2U . . . . . . . . . . . . . . . . 7
7. Guidelines for Credentials Selection . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. PKU2U ASN.1 Module . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Zhu & Altman Expires July 30, 2008 [Page 2]
Internet-Draft PKU2U January 2008
1. Introduction
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.
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 [RFC4120] and [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).
To remedy this, the PKU2U protocol extends [RFC4120] and [RFC4556] to
support peer-to-peer authentication without the help of a Key
Distribution Center (KDC) [RFC4120]. This mechanism can act as a
bridge between Public Key Infrastructure (PKI) and GSS-API for such
environments.
In addition, the binding of PKU2U for GSS-API is defined based on
[RFC4121].
2. Conventions Used in This Document
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 [RFC2119].
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.
3. The PKU2U Realm Name
The PKU2U realm name is defined as a reserved Kerberos realm name per
[KRB-NAME], and it has the value of "WELLKNOWN:PKU2U".
Unless otherwise specified, the realm name in any Kerberos message
used by PKU2U is the PKU2U realm name.
Zhu & Altman Expires July 30, 2008 [Page 3]
Internet-Draft PKU2U January 2008
4. PKU2U Principal Names
PKU2U Principal names can be constructed as follows:
o If the X.509 certificate [RFC3280] of a peer contains an id-
pkinit-san Subject Alternative Name (SAN) as defined in Section
3.2.2 of [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. If the realm in the
KRB5PrincipalName structure is specified, it MUST be the PKU2U
realm.
o If the X.509 certificate of the peer contains a dNSName SAN
[RFC3280], then unless otherwise specified the peer's Kerberos
principal name is a two-component NT-SRV-HST type name as defined
in Section 6.2.1 of [RFC4120], with the first component as "host"
and the second component as the name in the dNSName SAN of the
certificate, and the realm of this Kerberos principal is the PKU2U
realm.
It should be noted that a certificate that does not have any of the
above name attributes can be used in PKU2U as long as there is a
binding between the key pair and the peer principal that can be
verified, and such bindings can be maintained via a trusted table
such as a database that the peers learn via leap-of-faith ways, or
via PKI where the certificate is the binding.
A Distinguished Name (DN) can be transformed into a string and
represented as the NT-X500-PRINCIPAL name type, but the current
definition of this name type in [RFC4120] does not guarantee a
canonical form. Additional work is anticipated to start with
[RFC4514] but add further constraints: require Distinguished Encoding
Rules (DER) [X680] [X690] for values of unknown syntax, restrict the
use of escape characters, force the case of case-insensitive string
values, etc. It is anticipated that any name that appears in a
certificate, either as its DN or as a SAN, can be used via
GSS_Import_name() and GSS_Acquire_cred(). In order to do that, a
GSS-API name type is expected to be defined for each kind of PKI name
(DN, and every kind of SAN that may be useful), and a generic human-
readable syntax is expected to be defined for each such name-type.
The DN remains, however, as the canonical principal name. This work
is out of the scope to this document and it is generic to integrating
Distinguished Names into GSS-API.
Implementations conforming to this document MUST support the binding
schema specified in this section.
The rest of this document assumes there is a binding between a
Zhu & Altman Expires July 30, 2008 [Page 4]
Internet-Draft PKU2U January 2008
Kerberos principal name and the asymmetric key pair used for
authentication. The Kerberos principal name is returned by GSS-API
primitives such as GSS_Export_name() and GSS_Display_name().
5. The Protocol Description and the Context Establishment Tokens
The PKU2U protocol is based on [RFC4120], and it can only be used in
conjunction with GSS-API.
This section describes how PKU2U works and how it differs from
[RFC4120].
If initially the initiator has a service ticket to the acceptor, the
initiator, acting as the client in the parlance of [RFC4120],
performs the client-server authentication exchange according to
[RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as
the server.
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 [RFC4120]. The initiator always
includes the PA_PK_AS_REQ pre-authentication data computed according
to Section 3.2.1 of [RFC4556]. In a modification to [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 [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 [RFC2743], in the output token.
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 [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 [RFC4556]. The acceptor MUST verify
the binding between the initiator's name and the initiator's public
key. Unless otherwise specified, the initiator's X.509 certificate
MUST contain either the id-pkinit-KPClientAuth [RFC4556] Extended Key
Usage (EKU) extension or the id-kp-clientAuth EKU [RFC3280].
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
Zhu & Altman Expires July 30, 2008 [Page 5]
Internet-Draft PKU2U January 2008
Section 3.1.3 of [RFC4120].
If an error occurs, however, the response is a KRB_ERROR message
generated according to Section 3.1.4 of [RFC4120].
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().
The initiator then processes the reply token according to Section
3.1.5 of [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
[RFC4556]. The inclusion of the EKU KeyPurposeId [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.
Furthermore, PKU2U differs from [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.
The GSS-API acceptor is identified using the targ_name parameter of
the GSS_Init_sec_context() call, the initiator MUST verify the
binding between the targ_name and the acceptor in order to
authenticate the acceptor. In addition, unless otherwise specified
the acceptor's X.509 certificate MUST contain either the id-kp-
serverAuth EKU [RFC3280] or the id-pkinit-KPClientAuth EKU [RFC4556].
If an error message was returned, the initiator processes the
response according to Section 3.1.6 of [RFC4120].
With the obtained ticket, the initiator then, acting as the client in
the parlance of [RFC4120], performs the client-server authentication
exchange according to [RFC4121] and Section 3.2 of [RFC4120], with
the acceptor acting as the server.
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.
Zhu & Altman Expires July 30, 2008 [Page 6]
Internet-Draft PKU2U January 2008
The syntax of the initial context establishment token follows the
initialContextToken syntax defined in Section 3.1 of [RFC2743].
PKU2U is identified by the Objection Identifier (OID) id-kerberos-
pku2u.
id-kerberos-pku2u ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
pku2u(7) }
Subsequent context establishment tokens MUST NOT be encapsulated in
this GSS-API generic token framing.
The innerToken described in section 3.1 of [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:
Token TOK_ID Value in Hex
-----------------------------------------------
KRB_AS_REQ 05 00
KRB_AS_REP 06 00
The TOK_ID values for all other Kerberos messages are the same as
defined in [RFC4121].
By using anonymous PKINIT [KRB-ANON], PKU2U can provide server-
authentication without revealing the client's identity.
6. The GSS-API Binding for PKU2U
Section 5 defines the context establishment tokens. PKU2U per-
message tokens are defined as the per-message tokens in [RFC4121].
The Kerberos principal name form and the host-based service Name
described in [RFC1964] MUST be supported by implementations
conforming to this specification.
For implementations comforming to this specification, the
authenticator subkey in the AP-REQ [RFC4120] [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.
Zhu & Altman Expires July 30, 2008 [Page 7]
Internet-Draft PKU2U January 2008
GSS_EXTS_FINISHED TBA
--- The type for the checksum extension.
KRB-FINISHED ::= SEQUENCE {
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 GSS-API token.
-- The checksum is performed over the GSS-API
-- tokens in the order that the tokens were sent.
...
}
The gss-mic field contains a checksum of all the GSS-API tokens sent
from the initiator to the acceptor in the order they were sent, prior
to the current token. This checksum is performed over these GSS-API
tokens in the order that the tokens were sent by the initiator and
the acceptor. In the parlance of [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.
KEY_USAGE_FINISHED 41
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.
7. Guidelines for Credentials Selection
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
[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 [RFC3280], the acceptor SHOULD send back the TD-TRUSTED-
CERTIFIERS structure [RFC4556] that provides hints for guiding the
selection of an appropriate certificate by the initiator.
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.
If the certificates cannot be selected interactively, and multiple
Zhu & Altman Expires July 30, 2008 [Page 8]
Internet-Draft PKU2U January 2008
certificates can be used, it is RECOMMENDED that implementations fail
the context establishment thus avoid confusions caused by an
unexpected programmatic selection.
8. Security Considerations
The security considerations in [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.
9. Acknowledgements
The authors would like to thank Jeffrey Hutzelman for his insightful
comments on the earlier revisions of this document.
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.
Ari Medvinsky provided help in editing the initial revisions of this
document.
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.
10. IANA Considerations
Section 3 defines the PKU2U realm. The IANA registry for the
reserved names should be updated to reference this document.
This document defines GSS_EXTS_FINISHED extension type. The
corresponding IANA registry need to be updated to reference this
document.
11. References
Zhu & Altman Expires July 30, 2008 [Page 9]
Internet-Draft PKU2U January 2008
11.1. Normative References
[GSS-EXTS]
Emery, S., "Kerberos Version 5 GSS-API Channel Binding
Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility,
work in progress.
[KRB-ANON]
Zhu, L. and P. Leach, "Kerberos Anonymity Support",
draft-ietf-krb-wg-anon, work in progress.
[KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints",
draft-ietf-krb-wg-naming, work in progress.
[REFERALS] Raeburn, K. and L. Zhu, "Generating KDC Referrals to
Locate Kerberos Realms,
draft-ietf-krb-wg-kerberos-referrals, work in progress.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
Zhu & Altman Expires July 30, 2008 [Page 10]
Internet-Draft PKU2U January 2008
11.2. Informative References
[KRB-ANON]
Zhu, L. and P. Leach, "Kerberos Anonymity Support",
draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
Appendix A. PKU2U ASN.1 Module
PKU2U-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pku2u(TBA)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
Checksum
FROM KerberosV5Spec2 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) kerberosV5(2)
modules(4) krb5spec2(2) };
-- as defined in RFC 4120.
KRB-FINISHED ::= SEQUENCE {
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 GSS-API token.
-- The checksum is performed over the GSS-API
-- tokens in the order that the tokens were sent.
...
}
END
Authors' Addresses
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Jeffery Altman
Secure Endpoints
255 W 94th St
New York, NY 10025
US
Email: jaltman@secure-endpoints.com
Zhu & Altman Expires July 30, 2008 [Page 11]
Internet-Draft PKU2U January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zhu & Altman Expires July 30, 2008 [Page 12]