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 "". 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]