Network Working Group K. Igoe Internet-Draft National Security Agency Intended status: Standards Track D. Stebila Expires: July 26, 2010 Queensland University of Technology January 23, 2010 X.509v3 Certificates for Secure Shell Authentication draft-igoe-secsh-x509v3-01 Abstract X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document outlines how to incorporate X.509 version 3 public key certificates into the authentication methods of the Secure Shell protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 26, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Igoe & Stebila Expires July 26, 2010 [Page 1] Internet-Draft X.509v3 Certificates for SSH January 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. X.509 Version 3 Certificates . . . . . . . . . . . . . . . . . 5 2.1. Certificate Extensions . . . . . . . . . . . . . . . . . . 6 2.1.1. KeyUsage . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. ExtendedKeyUsage . . . . . . . . . . . . . . . . . . . 6 3. Signature Encoding . . . . . . . . . . . . . . . . . . . . . . 8 3.1. x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . . 8 3.2. x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . . 8 3.3. x509v3-ecdsa-sha2-* . . . . . . . . . . . . . . . . . . . 8 4. Server Authentication (public key algorithm) Using X.509v3 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. User Authentication (publickey authentication) Using X.509v3 Certificates . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Igoe & Stebila Expires July 26, 2010 [Page 2] Internet-Draft X.509v3 Certificates for SSH January 2010 1. Introduction There are two Secure Shell (SSH) protocols that use public key cryptography for authentication. The Transport Layer Protocol, described in [RFC4253], requires that a digital signature algorithm (called the "public key algorithm") MUST be used to authenticate the server to the client. Additionally, the User Authentication Protocol described in [RFC4252] allows for the use of a digital signature to authenticate the client to the server ("publickey" authentication). In both cases, the validity of the authentication depends upon the strength of the linkage between the public signing key and the identity of the signer. Digital certificates, such as those in X.509 version 3 (X.509v3) format, use a chain of signatures by a trusted root certification authority and its designated intermediate certificate authorites to bind a given public signing key to a given digital identity. The following public key authentication algorithms are presently available for use in SSH: +--------------+-----------+ | Algorithm | Reference | +--------------+-----------+ | ssh-dss | [RFC4253] | | | | | ssh-rsa | [RFC4253] | | | | | pgp-sign-dss | [RFC4253] | | | | | pgp-sign-rsa | [RFC4253] | | | | | ecdsa-sha2-* | [RFC5656] | +--------------+-----------+ Since PGP has its own method for binding a public key to a digital identity, this document focuses solely upon the non-PGP methods. In particular, this document defines the following public key algorithms which differ from the above solely in their use of X.509v3 certificates to convey the signer's public key. Igoe & Stebila Expires July 26, 2010 [Page 3] Internet-Draft X.509v3 Certificates for SSH January 2010 +---------------------+ | Algorithm | +---------------------+ | x509v3-ssh-dss | | | | x509v3-ssh-rsa | | | | x509v3-ecdsa-sha2-* | +---------------------+ Public keys conveyed using the x509v3-ecdsa-sha2-* public key algorithm can be used with the ecmqv-sha2 key exchange method. Implementation of this specification requires familiarity with the Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates [RFC5280]. This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms and the handling and structure of X.509v3 certificates is left to other standards documents. An earlier Internet-Draft for the use of X.509v3 certificates in the Secure Shell was proposed by O. Saarenmaa and J. Galbraith; while this document is informed in part by that Internet-Draft, it does not maintain strict compatibility. Igoe & Stebila Expires July 26, 2010 [Page 4] Internet-Draft X.509v3 Certificates for SSH January 2010 2. X.509 Version 3 Certificates The reader is referred to [RFC5280] for a general description of X.509 version 3 certificates. For the purposes of this document, it suffices to know that in X.509 a chain or sequence of certificates (possibly of length one) allows a Root Certificate Authority and its designated Intermediate Certificate Authorities to cryptographically bind a given public key to a given digital identity using public key signatures. For all of the public key algorithms specified in this document, the key format consists of a sequence of one or more X.509v3 certificates followed by a sequence of 0 or more Online Certificate Status Protocol (OCSP) responses as in Section 4.2 of [RFC2560]. Providing OCSP responses directly in this data structure can reduce the number of communication rounds required (saving the implementation from needing to perform OCSP checking out-of-band) and can also allow a client outside of a private network to receive OCSP responses from a server behind firewall. As with any use of OCSP data, implementations SHOULD check that the production time of the OCSP response is acceptable. It is RECOMMENDED, but not REQUIRED, that implementations reject certificates for which the certificate status is revoked. The key format has the following specific encoding: string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / "x509v3-ecdsa-sha2-*" uint32 certificate-count string certificate[1..certificate-count] uint32 ocsp-response-count string ocsp-response[0..ocsp-response-count] Each certificate and ocsp-response MUST be encoded as a string of octets using the DER encoding of Abstract Syntax Notation One (ASN.1) [ASN1]. An example of an SSH key exchange involving one of these public key algorithms is given in Appendix A. Additionally, the following constraints apply: o The sender's certificate MUST be the first certificate and the public key conveyed by this certificate MUST be consistent with the public key algorithm being employed to authenticate the sender. o Each following certificate MUST certify the one preceding it. o The self-signed certificate specifying the root authority MAY be omitted. Igoe & Stebila Expires July 26, 2010 [Page 5] Internet-Draft X.509v3 Certificates for SSH January 2010 o The individual certificates in the certificate chain MUST be signed using only algorithms corresponding to public key algorithms supported by the peer. The choice of signature algorithm used by any given certificate is independent of the signature algorithms chosen by other certificates in the chain. However, verifiers SHOULD be prepared to receive certificate chains that do not comply with this (in other words, using any signature algorithms), and MAY verify a non-compliant chain if they are able to do so. Issues associated with the use of certificates (such as expiration of certificates and revocation of compromised certificates) are addressed in [RFC5280] and are outside the scope of this document. However, compliant implementations MUST comply with [RFC5280]. Implementations providing and processing OCSP responses MUST comply with [RFC2560]. [I-D.solinas-suiteb-cert-profile] gives specific guidance on the structure of X.509v3 certificates to be used with Suite B ECDSA public keys. [RFC5280] provides guidance on certificates for RSA and DSA. 2.1. Certificate Extensions 2.1.1. KeyUsage The KeyUsage extension MAY be used to restrict a certificate's use. In accordance with Section 4.2.1.3 of [RFC5280], if the KeyUsage extension is present, then the certificate MUST be used only for one of the purposes indicated. There are two relevant keyUsage identifiers for the certificate corresponding to the public key algorithm in use: o The digitalSignature KeyUsage identifier MAY be used with certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-ecdsa- sha2-* public key algorithms. o The keyAgreement KeyUsage identifier MAY be used for certificates with convey keys for use with the ecmqv-sha2 key exchange method. For the remaining certificates in the certificate chain, implementations MUST comply with existing conventions on KeyUsage identifiers and certificates as in Section 4.2.1.3 on [RFC5280]. 2.1.2. ExtendedKeyUsage This document defines two ExtendedKeyUsage key purpose IDs that MAY be used to restrict a certificate's use: id-kp-secureShellClient, Igoe & Stebila Expires July 26, 2010 [Page 6] Internet-Draft X.509v3 Certificates for SSH January 2010 which indicates that the key can be used for a Secure Shell client, and id-kp-secureShellServer, which indicates that the key may be used for a Secure Shell server. In accordance with Section 4.2.1.12 of [RFC5280], if the ExtendedKeyUsage extension is present, then the certificate MUST be used only for one of the purposes indicated. The object identifiers of the two key purpose IDs defined in this document are as follows: o id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } o id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose identifiers o id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 } o id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 } Igoe & Stebila Expires July 26, 2010 [Page 7] Internet-Draft X.509v3 Certificates for SSH January 2010 3. Signature Encoding Signing and verifying using the X.509v3-based public key algorithms specified in this document (x509v3-ssh-dss, x509v3-ssh-rsa, x509v3- ecdsa-sha2-*) is done in the analogous way for the corresponding non- X.509v3-based public key algorithms (ssh-dss, ssh-rsa, ecdsa-sha2-*, respectively). For concreteness, we specify this explicitly below. 3.1. x509v3-ssh-dss Signing and verifying using the x509v3-ssh-dss key format is done according to the Digital Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. The resulting signature is encoded as follows: string "ssh-dss" string dss_signature_blob The value for dss_signature_blob is encoded as a string containing r, followed by s (which are fixed-length 160-bit integers, without lengths or padding, unsigned, and in network byte order). This format is the same as for ssh-dss signatures in Section 6.6 of [RFC4253]. 3.2. x509v3-ssh-rsa Signing and verifying using the x509v3-ssh-rsa key format is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash [FIPS-180-2]. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob The value for rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned, and in network byte order). This format is the same as for ssh-rsa signatures in Section 6.6 of [RFC4253]. 3.3. x509v3-ecdsa-sha2-* Signing and verifying using the x509v3-ecdsa-sha2-* key formats is performed according to the ECDSA algorithm in [SEC1] using the SHA2 Igoe & Stebila Expires July 26, 2010 [Page 8] Internet-Draft X.509v3 Certificates for SSH January 2010 hash function family [FIPS-180-3]. The choice of hash function from the SHA2 hash function family is based on the key size of the ECDSA key as specified in Section 6.2.1 of [RFC5656]. The resulting signature is encoded as follows: string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1 of [RFC5656]. The ecdsa_signature_blob value has the following specific encoding: mpint r mpint s The integers r and s are the output of the ECDSA algorithm. This format is the same as for ecdsa-sha2-* signatures in Section 3.1.2 of [RFC5656]. Igoe & Stebila Expires July 26, 2010 [Page 9] Internet-Draft X.509v3 Certificates for SSH January 2010 4. Server Authentication (public key algorithm) Using X.509v3 Certificates When the X.509v3-based public key algorithms in this document are used for server authentication, the server's public host key is conveyed from the server to the client in the SSH_MSG_KEX*_REPLY_MSG, where * is either DH, RSA, ECDH or ECMQV. All four key exchange protocols place the public host key in a string (K_S). When one of the public key algorithms specified in this document is used, the string K_S MUST contain an encoding of the data structure specified in Section 2. Igoe & Stebila Expires July 26, 2010 [Page 10] Internet-Draft X.509v3 Certificates for SSH January 2010 5. User Authentication (publickey authentication) Using X.509v3 Certificates When the X.509v3-based public key algorithms in this document are used for client authentication, the client initiates user authentication by sending an SSH_MSG_USERAUTH_REQUEST message to the server. One of the options available to the client is to specify that a public key authentication method is to be used. The list of user authentication public key algorithms defined for use in Secure Shell is precisely the same as the list of server authentication algorithms (public key algorithms) defined for use in Secure Shell. Note that the choice of a user authentication public key algorithm is independent of the choice of a server authentication algorithm. The client's public key is conveyed in a string called the "public key blob". The public key authentication algorithms specified in this document REQUIRE that the "public key blog" string contain an encoding of the data structure specified in Section 2. Igoe & Stebila Expires July 26, 2010 [Page 11] Internet-Draft X.509v3 Certificates for SSH January 2010 6. Security Considerations This document provides new public key algorithms for the Secure Shell protocol that convey public keys using X.509v3 certificates. For the most part, the security considerations involved in using the Secure Shell protocol apply, since all of the public key algorithms introduced in this document are based on existing algorithms in the Secure Shell protocol. However, implementers should be aware of security considerations specific to the use of X.509v3 certificates in a public key infrastructure, including considerations related to expired certificates and certificate revocation lists. The reader is directed to the security considerations sections of [RFC5280] for the use of X.509v3 certificates, [RFC2560] for the use of OCSP resonse, [RFC4253] for server authentication, and [RFC4252] for user authentication. Igoe & Stebila Expires July 26, 2010 [Page 12] Internet-Draft X.509v3 Certificates for SSH January 2010 7. IANA Considerations Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations: In the Public Key Algorithm Names registry: o The SSH public key algorithm "x509v3-ssh-dss". o The SSH public key algorithm "x509v3-ssh-rsa". o The family of SSH public key algorithm names beginning with "x509v3-ecdsa-sha2-" and not containing the at-sign ('@'). This document creates no new registries. The two object identifiers used in Section 2.1.2 were assigned from a private arc and need not be registered in an IANA registry. Igoe & Stebila Expires July 26, 2010 [Page 13] Internet-Draft X.509v3 Certificates for SSH January 2010 8. Normative References [ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002. [FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, August 2002. [FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008. [FIPS-186-2] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-2, January 2000. [I-D.solinas-suiteb-cert-profile] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", draft-solinas-suiteb-cert-profile-04 (work in progress), July 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Igoe & Stebila Expires July 26, 2010 [Page 14] Internet-Draft X.509v3 Certificates for SSH January 2010 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, December 2009. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, September 2000, . Igoe & Stebila Expires July 26, 2010 [Page 15] Internet-Draft X.509v3 Certificates for SSH January 2010 Appendix A. Example The following example illustrates the use of an X.509v3 certificate for a public key for the Digital Signature Algorithm when used in a Diffie-Hellman key exchange method. In the example, there is a chain of certificates of length 2, and a single OCSP response is provided. byte SSH_MSG_KEXDH_REPLY string 0x00 0x00 0xXX 0xXX -- length of the remaining data in this string 0x00 0x00 0x00 0x0D -- length of string "x509v3-ssh-dss" "x509v3-ssh-dss" 0x00 0x00 0x00 0x02 -- there are 2 certificates 0x00 0x00 0xXX 0xXX -- length of sender certificate DER-encoded sender certificate 0x00 0x00 0xXX 0xXX -- length of issuer certificate DER-encoded issuer certificate 0x00 0x00 0x00 0x01 -- there is 1 OCSP response 0x00 0x00 0xXX 0xXX -- length of OCSP response DER-encoded OCSP response mpint f string signature of H Igoe & Stebila Expires July 26, 2010 [Page 16] Internet-Draft X.509v3 Certificates for SSH January 2010 Appendix B. Acknowledgements The authors acknowledge helpful comments from Joseph Galbraith, Jeffrey Hutzelman, Jan Pechanec, and Nicolas Williams. O. Saarenmaa and J. Galbraith previously prepared an Internet-Draft on a similar topic. Igoe & Stebila Expires July 26, 2010 [Page 17] Internet-Draft X.509v3 Certificates for SSH January 2010 Authors' Addresses Kevin M. Igoe National Security Agency NSA/CSS Commercial Solutions Center United States of America Email: kmigoe@nsa.gov Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia Email: douglas@stebila.ca Igoe & Stebila Expires July 26, 2010 [Page 18]