X.509v3 Certificates for Secure Shell Authentication
draft-igoe-secsh-x509v3-02

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 October 1, 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 (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
2.  X.509 Version 3 Certificates
    2.1.  Certificate Extensions
        2.1.1.  KeyUsage
        2.1.2.  ExtendedKeyUsage
3.  Signature Encoding
    3.1.  x509v3-ssh-dss
    3.2.  x509v3-ssh-rsa
    3.3.  x509v3-ecdsa-sha2-*
4.  Server Authentication (public key algorithm) Using X.509v3 Certificates
5.  User Authentication (publickey authentication) Using X.509v3 Certificates
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Example
Appendix B.  Acknowledgements
§  Authors' Addresses

1.  Introduction

There are two Secure Shell (SSH) protocols that use public key cryptography for authentication. The Transport Layer Protocol, described in [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.), 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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) 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 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:

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.

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.) and X.509v3 certificates [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.).

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. (NOTE TO RFC EDITOR: This paragraph should not appear in the final RFC. A note about the previous I-D also appears in the Acknowledgements.)

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 RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  X.509 Version 3 Certificates

The reader is referred to [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) 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 trusted root certificate authority and its 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] (Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” June 1999.). 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] (International Telecommunications Union, “Abstract Syntax Notation One (ASN.1): Specification of basic notation,” July 2002.). An example of an SSH key exchange involving one of these public key algorithms is given in Appendix A (Example).

Additionally, the following constraints apply:

• 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.
• Each following certificate MUST certify the one preceding it.
• The self-signed certificate specifying the root authority MAY be omitted.
• To improve the chances that a peer can verify certificte chains and OCSP responses, individual certificates and OCSP responses SHOULD be signed using only signature algorithms corresponding to public key algorithms supported by the peer, as indicated in the server_host_key_algorithms field of the SSH_MSG_KEXINIT packet (see Section 7.1 of [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.)). However, other algorithms MAY be used. The choice of signature algorithm used by any given certificate or OCSP response is independent of the signature algorithms chosen by other elements in the chain.
• Verifiers MUST be prepared to receive certificate chains and OCSP resposnes that use algorithms not listed in the server_host_key_algorithms field of the SSH_MSG_KEXINIT packet, including algorithms which potentially have no Secure Shell equivalent. However, peers sending such chains should recognize that such chains are more likely to be unverifiable than chains which use only algorithms listed in the server_host_key_algorithms field.
• There is no requirement on the ordering or number of OCSP responses.

Upon receipt of a certificate chain, implementations MUST verify the certificate chain according to Section 6.1 of [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) based on a root of trust configured by the system administrator or user.

Issues associated with the use of certificates (such as expiration of certificates and revocation of compromised certificates) are addressed in [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) and are outside the scope of this document. However, compliant implementations MUST comply with [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.). Implementations providing and processing OCSP responses MUST comply with [RFC2560] (Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” June 1999.).

[RFC5480] (Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, “Elliptic Curve Cryptography Subject Public Key Information,” March 2009.) and [RFC5758] (Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, “Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA,” January 2010.) describes the structure of X.509v3 certificates to be used with ECDSA public keys. [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) describes the structure of X.509v3 certificates to be used with RSA and DSA public keys. [RFC5759] (Solinas, J. and L. Zieglar, “Suite B Certificate and Certificate Revocation List (CRL) Profile,” January 2010.) provides additional guidance for ECDSA keys in Suite B X.509v3 certificate and certificate revocation list profiles.

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] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.), 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:

• The digitalSignature KeyUsage identifier MAY be used with certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-ecdsa-sha2-* public key algorithms.
• 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] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.).

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, which indicates that the key can be used for a Secure Shell client, and id-kp-secureShellServer, which indicates that the key can be used for a Secure Shell server. In accordance with Section 4.2.1.12 of [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.), 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:

• id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
• id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose identifiers
• id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }
• id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 }

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‑3] (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) using the SHA-1 hash [FIPS‑180‑2] (National Institute of Standards and Technology, “Secure Hash Standard,” August 2002.).

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.).

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] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) using the SHA-1 hash [FIPS‑180‑2] (National Institute of Standards and Technology, “Secure Hash Standard,” August 2002.).

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.).

3.3.  x509v3-ecdsa-sha2-*

Signing and verifying using the x509v3-ecdsa-sha2-* key formats is performed according to the ECDSA algorithm in [FIPS‑186‑3] (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) using the SHA2 hash function family [FIPS‑180‑3] (National Institute of Standards and Technology, “Secure Hash Standard,” October 2008.). 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] (Stebila, D. and J. Green, “Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer,” December 2009.).

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] (Stebila, D. and J. Green, “Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer,” December 2009.).

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] (Stebila, D. and J. Green, “Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer,” December 2009.).

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 (X.509 Version 3 Certificates).

The mapping between certificates and host names is left as an implementation and configuration issue for implementers and system administrators.

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 blob" string contain an encoding of the data structure specified in Section 2 (X.509 Version 3 Certificates).

The mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators.

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] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) for the use of X.509v3 certificates, [RFC2560] (Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” June 1999.) for the use of OCSP response, [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.) for server authentication, and [RFC4252] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) for user authentication. The use of revoked certificates, while not RECOMMENDED, is allowed; as certificates may be revoked for a variety of reasons -- including the compromise of the private key or the issuance of a certificate to a wrong party -- authentication properties may not longer hold when revoked certificates are not rejected.

7.  IANA Considerations

Consistent with Section 8 of [RFC4251] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) and Section 4.6 of [RFC4250] (Lehtinen, S. and C. Lonvick, “The Secure Shell (SSH) Protocol Assigned Numbers,” January 2006.), this document makes the following registrations:

In the Public Key Algorithm Names registry:

• The SSH public key algorithm "x509v3-ssh-dss".
• The SSH public key algorithm "x509v3-ssh-rsa".
• 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 (ExtendedKeyUsage) were assigned from an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document.

8.  References

8.1. Normative References

8.2. Informative References

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

Appendix B.  Acknowledgements

The authors acknowledge helpful comments from Joseph Galbraith, Jeffrey Hutzelman, Jan Pechanec, Sean Turner, and Nicolas Williams.

O. Saarenmaa and J. Galbraith previously prepared an Internet-Draft on a similar topic.

Authors' Addresses