Network Working Group K. Igoe
Internet-Draft National Security Agency
Intended status: Standards Track D. Stebila
Expires: October 17, 2010 Queensland University of Technology
April 15, 2010
X.509v3 Certificates for Secure Shell Authentication
draft-igoe-secsh-x509v3-03
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 specifies how to use X.509 version 3 public
key certificates in public key algorithms in the Secure Shell
protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 17, 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
Igoe & Stebila Expires October 17, 2010 [Page 1]
Internet-Draft X.509v3 Certificates for SSH April 2010
described in the Simplified 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 . . . . . . . . . . . . . . . . . . . 7
3. Signature Encoding . . . . . . . . . . . . . . . . . . . . . . 8
3.1. x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . . 8
3.2. x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . . 8
3.3. x509v3-ecdsa-sha2-* . . . . . . . . . . . . . . . . . . . 8
4. Use in public key algorithms . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Igoe & Stebila Expires October 17, 2010 [Page 2]
Internet-Draft X.509v3 Certificates for SSH April 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 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 October 17, 2010 [Page 3]
Internet-Draft X.509v3 Certificates for SSH April 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. (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].
Igoe & Stebila Expires October 17, 2010 [Page 4]
Internet-Draft X.509v3 Certificates for SSH April 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 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]. 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. All other intermediate certificates in the chain leading
Igoe & Stebila Expires October 17, 2010 [Page 5]
Internet-Draft X.509v3 Certificates for SSH April 2010
to a root authority MUST be included.
o To improve the chances that a peer can verify certificate 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]). 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.
o Verifiers MUST be prepared to receive certificate chains and OCSP
responses 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.
o 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] 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] 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].
[RFC5480] and [RFC5758] describes the structure of X.509v3
certificates to be used with ECDSA public keys. [RFC5280] describes
the structure of X.509v3 certificates to be used with RSA and DSA
public keys. [RFC5759] 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], if the KeyUsage
Igoe & Stebila Expires October 17, 2010 [Page 6]
Internet-Draft X.509v3 Certificates for SSH April 2010
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,
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], 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 October 17, 2010 [Page 7]
Internet-Draft X.509v3 Certificates for SSH April 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-3] 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 [FIPS-186-3] using the
Igoe & Stebila Expires October 17, 2010 [Page 8]
Internet-Draft X.509v3 Certificates for SSH April 2010
SHA2 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 October 17, 2010 [Page 9]
Internet-Draft X.509v3 Certificates for SSH April 2010
4. Use in public key algorithms
The public key algorithms and encodings defined in this document
SHOULD be accepted anyplace in the Secure Shell protocol suite where
public keys are used, including, but not limited to, the following
protocol messages for server authentication and user authentication:
o in the SSH_MSG_USERAUTH_REQUEST message when "publickey"
authentication is used [RFC4252]
o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased"
authentication is used [RFC4252]
o in the SSH_MSG_KEXDH_REPLY message [RFC4253]
o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]
When a public key from this specification is included in the input to
a hash algorithm, the exact bytes that are transmitted on the wire
must be used as input to the hash functions. In particular,
implementations MUST NOT omit any of the chain certificates or OCSP
responses that were included on the wire, nor change encoding of the
certificate or OCSP data. Otherwise hashes that are meant to be
computed in parallel by both peers will have differing values.
For the purposes of server authentication, the mapping between
certificates and host names is left as an implementation and
configuration issue for implementers and system administrators.
For the purposes of user authentication, the mapping between
certificates and user names is left as an implementation and
configuration issue for implementers and system administrators.
Igoe & Stebila Expires October 17, 2010 [Page 10]
Internet-Draft X.509v3 Certificates for SSH April 2010
5. 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 response, [RFC4253] for server authentication, and [RFC4252]
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.
Igoe & Stebila Expires October 17, 2010 [Page 11]
Internet-Draft X.509v3 Certificates for SSH April 2010
6. 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
an arc delegated by IANA to the PKIX Working Group. No further
action by IANA is necessary for this document.
Igoe & Stebila Expires October 17, 2010 [Page 12]
Internet-Draft X.509v3 Certificates for SSH April 2010
7. References
7.1. 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-3]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 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.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Igoe & Stebila Expires October 17, 2010 [Page 13]
Internet-Draft X.509v3 Certificates for SSH April 2010
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, December 2009.
[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",
RFC 5758, January 2010.
7.2. Informative References
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, March 2006.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and
Certificate Revocation List (CRL) Profile", RFC 5759,
January 2010.
Igoe & Stebila Expires October 17, 2010 [Page 14]
Internet-Draft X.509v3 Certificates for SSH April 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 October 17, 2010 [Page 15]
Internet-Draft X.509v3 Certificates for SSH April 2010
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.
Igoe & Stebila Expires October 17, 2010 [Page 16]
Internet-Draft X.509v3 Certificates for SSH April 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 October 17, 2010 [Page 17]