Internet DRAFT - draft-adamson-nfsv4-spkm3
draft-adamson-nfsv4-spkm3
Network Working Group W. Adamson
Internet-Draft O. Kornievskaia
Expires: April 17, 2006 October 14, 2005
Low Infrastructure Mutual Authentication Using SPKM-3
draft-adamson-nfsv4-spkm3-00.txt
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 April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memorandum describes a method whereby one can use GSS-API
[RFC2078] to supply a secure channel between a user on a client and a
server, authenticating both the user and server with public key
certificates [RFC3280], without the need for an external Public Key
Infrastructure for certificate verification. The method leverages
the existing Simple Public Key Mechanism Version 3 (SPKM-3)
[RFC2847]. In addition to describing the use of SPKM-3 for mutual
authentication, this memorandum updates RFC2847, reflecting
implementation experience.
Adamson & Kornievskaia Expires April 17, 2006 [Page 1]
Internet-Draft SPKM-3 Mutual Auth October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mutual Authentication Requirements of SPKM-3 . . . . . . . . . 4
2.1 SPKM_REQ token . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 requestToken . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 certif-data . . . . . . . . . . . . . . . . . . . . . 5
2.2 SPKM-REP-TI token . . . . . . . . . . . . . . . . . . . . 5
2.3 SPKM-REP-IT token . . . . . . . . . . . . . . . . . . . . 5
3. Clarifications . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Certificates . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Misc for now . . . . . . . . . . . . . . . . . . . . . . . 7
4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
A. Appendix A: Imported Types . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Adamson & Kornievskaia Expires April 17, 2006 [Page 2]
Internet-Draft SPKM-3 Mutual Auth October 2005
1. Introduction
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].
This memorandum describes the use of SPKM-3 to provide mutual
authentication between a user with public key certificates [RFC3280],
and a server with public key certificates. Mutual authentication can
be accomplished via the Simple Public Key Mechanism (SPKM) [RFC2025],
but requires a great deal of public key infrastructure. SPKM-3 can
perform mutual authentication in the case of no public key
infrastructure, where the target and initiator have no knowledge of
each others certificates and no way to obtain them except through
SPKM.
Adamson & Kornievskaia Expires April 17, 2006 [Page 3]
Internet-Draft SPKM-3 Mutual Auth October 2005
2. Mutual Authentication Requirements of SPKM-3
SPKM-3 describes a method of obtaining a secure channel between an
anonymous user on the client an a server. The secure channel is then
used by the LIPKEY GSS-API mechanism [RFC2847] to transport a
username and password to the server. This section describes some
changes to how SPKM-3 operates in order to realize the low
infrastructure model of mutual authentication.
2.1 SPKM_REQ token
The initiator constructs an SPKM-REQ token as described for anonymous
authentication in [RFC2847] SPKM-3 with the following changes.
2.1.1 requestToken
The SPKM-REQ token contains a required requestToken.
2.1.1.1 Key Establishment Algorithm (K-ALG)
The requestToken has a req-contents, which has a key-estb-set. The
key-estb-set must be dhKeyAgreement, because the initiator doesn't
know the target's public key, and so cannot encrypt a session key
with the target's public key. And the initiator can't encrypt a
session with her private key, because then anyone will be able to
know what the session key is since the initiator's public key is,
well, public.
2.1.1.2 target-certif-data-required
The requestToken has a req-contents, which has a req-data, which has
an options field. The target-certif-data-required option must be
set. While this is not a difference from anonymous authentication
defined in [RFC2847] SPKM-3, it is mentioned because it is critical.
2.1.1.3 mutual-state
The req-data options field also contains a mutual-state option which
must be set to TRUE. As noted in [RFC2025], this derives from the
mutual-req-flag provided to the GSS-API gss_init_sec_context call.
2.1.1.4 Alg-Id
The requestToken has an algId field used for the req-integrity field.
The algId needs to be one of id-dsa-with-sha1, md4WithRSAEncryption,
or sha1WithRSAEncryption. The signature will be based on the
initiator's certificate in the userCertif field (Section 2.1.2).
Adamson & Kornievskaia Expires April 17, 2006 [Page 4]
Internet-Draft SPKM-3 Mutual Auth October 2005
2.1.2 certif-data
The SPKM-REQ token contains an optional certif-data. The certif-data
has an optional certificationPath field. The certificationPath field
has an optional userCertif field which contains the user Certificate.
This field needs to be set, because it is needed in order for the
target to authenticate the initiator in a later step.
2.2 SPKM-REP-TI token
The target verifies the initiator's SPKM-REQ token by verifying that
the req-integrity field was computed by the owner of the userCertif
field. This is phase 1 of authenticating the target. The target
produces the SPKM-REP-TI token as defined in [RFC2847] and [RFC2025].
2.3 SPKM-REP-IT token
Unlike [RFC2847], because mutual authentication was requested, the
initiator must construct a SPKM-REP-IT token. This is because
attackers could replay SPKM-REQ tokens, and since the target doesn't
have an infinite cache, and since SPKM-1 and SPKM-3 do not require
synchronized time, a 3-way handshake is needed.
It should be mostly clear from [RFC2025](Section 3.1.3) how to do
this. However, there's one point that isn't clear. The randTarg
field in the SPKM-REP-IT responseToken is randomly generated by the
initiator, and so should be the same value that was in the
SPKM-REP-TI rep-ti-contents randTarg field. Similarly, the randSrc
field in the SPKM-REP-TI rep-ti-contents is the same value as the
SPKM-REQ requestToken req-contents randSrc field.
The SPKM-REP-IT token algId field used to create the rep-it-integ
field should use id-dsa-with-sha1, md5WithRSAEncryption, or
sha1WithRSAEncryption. The initiator verifies the SPKM-REP-IT token
by verifying that the req-it-integ field was computed by the owner of
the targets certificate, obtained in the SPKM-REP-TI certif-data
certificationPath userCertif field.
Adamson & Kornievskaia Expires April 17, 2006 [Page 5]
Internet-Draft SPKM-3 Mutual Auth October 2005
3. Clarifications
3.1 Naming
In this section, we clarify the construction and verification of
names in SPKM-3. Names are constructed by both the initiator and the
target. The initiator always constructs a target name. When mutual
authentication is requested, the initiator also constructs a source
name. The initiator retrieves its source name information (ie., the
Distinguished Name) from its own certificate which the initiator
acquired by calling GSS_acquire_cred(). The initiator should encode
the source name in a single RDN sequence and use a
GSS_SPKM_NT_USER_NAME name type. The target, like the initiator,
constructs the target name using its certificate, but uses a
GSS_SPKM_NT_MACHINE_UID_NAME name type.
We assume that during the construction of the REQ_TOKEN the initiator
has no access to the target's certificate and therefore has to
construct the target name with the information provided by the
application which might be of the form "service@host". In such case,
the initiator should convert the name to a common name "CN=service/
host", encoded in a single RDN sequence, and use a
GSS_SPKM_NT_MACHINE_UID_NAME name type.
During the validation of a name (either when the target validates the
name of the initiator or vice versa), a match occurs:
o if the target name is the same as the subject name or a DN entry
for the subject alternate name in the target certificate.
o if the target name is just a common name and the common name
matches the CN portion of the subject name or the CN portion of a
DN entry for the subject alternate name in the target certificate.
o if the target name is a service name ("CN=service/host") and the
host matches the CN portion of the subject name or a DNS entry for
the subject alternate name in the target certificate.
For anonymous SPKM-3, GSS_display_name() returns the string
"<anonymous>". Define an OID for it?
3.2 Certificates
SPKM-3 must support X509 v3 certificates.
In SPKM-3, certificate validation follows the SSL model where the
source provides its certificate and the certification chain up to the
root certificate. The target then provides its certificate and the
Adamson & Kornievskaia Expires April 17, 2006 [Page 6]
Internet-Draft SPKM-3 Mutual Auth October 2005
certification chain up to the root certificate. Thus, the
certification data consists of the forward root certificate followed
by any reverse certificates required to reach the user certificate.
In authenticated SPKM-3, both parties (initiator and target) always
send their certificates and certification chains. Consequently, the
field target-certif-data-required is always TRUE. Also, in SPKM-
REP_TI the certif-data field is no longer OPTIONAL.
3.3 Misc for now
o padding in cast5.
o how to generate 8byte DES key from the key material.
o key length for hmac-md5.
o encoding of DH parameters and keys.
o add AES to C-ALG.
o channel binding.
o clarify the description of the "Integrity" field in SPKM-3 tokens.
o spkm3_parse_token() should not be a mandatory function.
o Numbering of bits in ASN1 BIT_STRING is left-to-right.
Adamson & Kornievskaia Expires April 17, 2006 [Page 7]
Internet-Draft SPKM-3 Mutual Auth October 2005
4. Issues
SPKM-3 should not use NULL-MAC or md5WithRSAEncryption as integrity
algorithms for exchange of messages after the security context has
been established. By doing a DH key agreement, the initiator and the
target establish a symmetric key which can be used by HMAC-md5 (or a
like protocols). Trying to use NULL-MAC reduces security because
only hashing is performed on a message and using md5WithRSAEncryption
reduces performances because a public key operation (signing) is
applied to every message.
In anonymous SPKM-3, the only choice for the integrity algorithm in
the REQ-TOKEN is NULL-MAC. HMAC-MD5 cannot be used because no
symmetric key has been established. md5WithRSAEncryption cannot be
used because the initiator does not have a certificate.
In SPKM-3, the only choice for the integrity algorithm in the REP-TI-
TOKEN is md5WithRSAEncryption. In anonymous case, to avoid the man-
in-the-middle attack, the target has to authenticate to the
initiator. The target needs to sign the rep-ti-contents using
md5WithRSAEncryption (or a like protocols). In mutual
authentication, the target uses md5WithRSAEncryption to authenticate
to the initiator.
Adamson & Kornievskaia Expires April 17, 2006 [Page 8]
Internet-Draft SPKM-3 Mutual Auth October 2005
5. Security Considerations
Security issues are discussed throughout this memo.
Adamson & Kornievskaia Expires April 17, 2006 [Page 9]
Internet-Draft SPKM-3 Mutual Auth October 2005
Appendix A. Appendix A: Imported Types
The ASN.1 types in Appendix B of RFC2025 imported from
InformationFramework (1993) and AuthenticationFramework (1993), and
[PKCS3] are outdated. Both the InformationFrameWork and the
AuthenticationFramework have moved forward to new versions.
Implementations of this specification MUST be capable of processing
the Version 3 X.509 certificates and extensions described in the
RFC3280 appendix A.1 "Explicitly Tagged Module, 1988 Syntax" with the
following OID.
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-
explicit(18) }
6. References
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2847] Eisler, M. and Zambeel, "LIPKEY - A Low Infrastructure
Public Key Mechanism Using SPKM", RFC 2847, June 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.
Authors' Addresses
William A. (Andy) Adamson
CITI, University of Michigan
535 W. William
Ann Arbor MI 48103
USA
Email: andros@umich.edu
Adamson & Kornievskaia Expires April 17, 2006 [Page 10]
Internet-Draft SPKM-3 Mutual Auth October 2005
Olga Kornievskaia
Email: aglo@umich.edu
Adamson & Kornievskaia Expires April 17, 2006 [Page 11]
Internet-Draft SPKM-3 Mutual Auth October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Adamson & Kornievskaia Expires April 17, 2006 [Page 12]
