Network Working Group K.M. Igoe Internet Draft National Security Agency Intended Status: Informational February 17, 2010 Expires: August 21, 2010 Suite B Cryptographic Suites for Secure Shell draft-igoe-secsh-suiteb-01 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 August 21, 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 waranty as described in the BSD License. Igoe Informational [Page 1] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 Abstract This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B secure shell makes use of elliptic curve Diffie-Hellmann (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. Table of Contents 1. Suite B and Secure Shell.........................................3 2. Previous Work....................................................3 3. Security Mechanism Negotiation and Initialization................4 3.1. SSH_MSG_KEXINIT.............................................5 3.2. SSH_MSG_KEXECDH_INIT........................................6 3.3. SSH_MSG_KEXECDH_REPLY.......................................6 3.4. SSH_MSG_USERAUTH_REQUEST....................................7 4. Confidentiality and Data Integrity of SSH Binary Packets.........8 4.1. Galois/Counter Mode.........................................8 4.2. Data Integrity..............................................9 5. Rekeying.........................................................9 6. Security Considerations..........................................9 7. References.......................................................9 7.1. Normative References........................................9 7.2. Informative References.....................................10 Igoe Informational [Page 2] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 1. Suite B and Secure Shell At the 2005 RSA Conference the Information Assurance Directorate of the National Security Agency announced a new suite of unclassified cryptographic algorithms which may be used to protect both unclassified and classified information. Suite B uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for authentication, the Elliptic Curve Diffie-Hellman protocol (ECDH) for key establishment, the SHA-2 family of secure hashes, and the Advanced Encryption Standard (AES) for privacy. Many Suite B applications use AES in Galois Counter Mode (GCM) to simultaneously provide both data integrity and privacy. Similarly, Suite B applications often use X509v3 certificates to bind a given digital identity to a corresponding public key. 2. Previous Work Several RFCs have been drafted that document how each of the Suite B components are to be integrated into Secure Shell: kex algorithms ecdh-sha2-nistp256 [SSH-ECC] ecdh-sha2-nistp384 [SSH-ECC] server host key algorithms x509v3-ecdsa-sha2-nistp256 [SSH-X509] x509v3-ecdsa-sha2-nistp384 [SSH-X509] encryption algorithms (both client_to_server and server_to_client) AEAD_AES_128_GCM [SSH-GCM] AEAD_AES_256_GCM [SSH-GCM] mac algorithms (both client_to_server and server_to_client) AEAD_AES_128_GCM [SSH-GCM] AEAD_AES_256_GCM [SSH-GCM] [RFC5759], Suite B Certificates and Certificate Revocation List (CRL) Profile, is the authoritative source on the requirements for Suite B X.509v3 certificates. The purpose of this document is to draw all of these components together in a single document and provide guidance as to how these are to be used in Suite B compliant implementations of secure shell. Note that use of the appropriate Suite B algorithms does not in and of itself imply a given implementation of secure shell is suitable for use in protecting classified data. An implementation of Suite B secure shell must be validated by the appropriate authority before such usage is permitted. The devil, as always, is in the details. The two elliptic curves used in Suite B appear in the literature under two different names. For sake of clarity we list both names below. Igoe Informational [Page 3] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 Curve NIST name SECG name OID [SEC2] --------------------------------------------------------------- P-256 nistp256 secp256r1 1.2.840.10045.3.1.7 P-384 nistp384 secp384r1 1.3.132.0.34 A description of these curves can be found in [NIST] or [SEC2]. 3. Security Mechanism Negotiation and Initialization As described in [SSH-Tran], the exchange of SSH_MSG_KEXINIT between the server and the client establishes which key agreement algorithm, mac algorithms, host key algorithm (server authentication algorithm), and encryption algorithms are to be used. This section describes how the Suite B components are to be used in the secure shell algorithm negotiation, key agreement serve authentication and user authentication. Negotiation and initialization of a Suite B secure shell connection involves the following secure shell messages (where C->S denotes a message from the client to the server and S->C denotes a server to client message): SSH_MSG_KEXINIT C->S Contains lists of algorithms acceptable to the client. SSH_MSG_KEXINIT S->C Contains lists of algorithms acceptable to the server. SSH_MSG_KEXECDH_INIT C->S Contains the client's ephemeral elliptic curve Diffie-Hellman key. SSH_MSG_KEXECDH_REPLY S->C Contains a certificate with the server's ECDSA public signature key, the server's ephemeral ECDH contribution, and an ECDSA digital signature of the newly formed exchange hash value. SSH_MSG_USERAUTH_REQUEST C->S Contains the user's name, the name of the service the user is requesting, the name of the authentication method the client wishes to use, and method specific fields. When not in the midst of processing a key exchange, either party may initiate a key re-exchange by sending an SSH_MSG_KEXINIT packet. All packets exchanged during the re-exchange are encrypted and authenticated using the current keys until the conclusion of the re-exchange, at which point a SSH_MSG_NEWKEYS initiates a change to Igoe Informational [Page 4] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 the newly established keys. Otherwise the re-exchange protocol is identical to the initial key exchange protocol. See section 9 of [SSH-Tran]. 3.1. SSH_MSG_KEXINIT As described in [SSH-Tran], the SSH_MSG_KEXINIT packet has the following structure: byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) name-list kex_algorithms name-list server_host_key_algorithms name-list encryption_algorithms_client_to_server name-list encryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-list mac_algorithms_server_to_client name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client name-list languages_client_to_server name-list languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) In Suite B, the kex algorithm, server host key, encryption algorithm, and mac algorithm name lists MUST be populated as follows: The kex algorithm name list MUST consist solely of one or more of the following: ecdh-sha2-nistp256 ecdh-sha2-nistp384 The server host key name list MUST consist solely of one or more of the following: x509v3-ecdsa-sha2-nistp256 x509v3-ecdsa-sha2-nistp384 The server and client encryption algorithm name lists MUST consist solely of one or more of the following: AEAD_AES_128_GCM AEAD_AES_256_GCM The server and client mac algorithm name lists MUST be precisely the same as the corresponding encryption name list. Further the mac algorithm selected to provide data integrity MUST be the same as the encryption algorithm selected to provide privacy. Igoe Informational [Page 5] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 3.2. SSH_MSG_KEXECDH_INIT In Suite B, the key agreement MUST use one of the following key agreement methods to generate a shared secret value (SSV): ecdh-sha2-nistp256 ephemeral-ephemeral elliptic curve Diffie-Hellman on nistp256 with SHA-256 ecdh-sha2-nistp384 ephemeral-ephemeral elliptic curve Diffie-Hellman on nistp384 with SHA-384 and the format of the SSH_MSG_KEXECDH_INIT message is: byte SSH_MSG_KEXDH_INIT string Q_C // client's ephemeral contribution to the ECDH // exchange, encoded as an octet string where the encoding of the elliptic curve point Q_C as an octet string is as specified in section 2.3.3 of [SEC1]. As specified in [SSH-Tran], the encryption keys and initialization vectors needed by secure shell are derived directly from the SSV using the hash function specified by the key agreement algorithm (SHA-256 for ecdh-sha2-nistp256 and SHA-384 for ecdh-sha2-nistp384). The client to server channel and the server to client channel will have independent keys and initialization vectors. These keys will remain constant until a re-exchange results in the formation of a new SSV. 3.3. SSH_MSG_KEXECDH_REPLY The SSH_MSG_KEXECDH_REPLY contains the server's contribution to the ECDH exchange, the server's public signature key, and a signature of the exchange hash value formed from the newly established shared secret value. In Suite B secure shell server authentication MUST use either: x509v3-ecdsa-sha2-nistp256 elliptic curve digital signature algorithm on nistp256 with SHA-256. x509v3-ecdsa-sha2-nistp384 elliptic curve digital signature algorithm on nistp384 with SHA-384. The client MUST support verification of both x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384 signatures. The server MUST support at least one of these methods, but need not support both. Note that this requires the server to have either a nistp256 certificate or a nistp384 certificate (or both). The format of the SSH_MSG_KEXECDH_REPLY is: byte SSH_MSG_KEXECDH_REPLY Igoe Informational [Page 6] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 string K_S // A string encoding an X.509v3 certificate // containing the server's ECDSA public host key string Q_S // server's ephemeral contribution to the ECDH // exchange, encoded as an octet string string Sig_S // an octet string containg the server's // signature of the newly established exchange // hash value Details on the structure and encoding of the X.509v3 can be found in section 2 of [SSH-X509]. The encoding of the elliptic curve point Q_C as an octet string is as specified in section 2.3.3 of [SEC1] and the encoding of the ECDSA signature Sig_S as an octet string is as described in section 3.3 of [SSH-X509]. 3.4. SSH_MSG_USERAUTH_REQUEST This section describes how x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384 are to be used for user authentication. All Suite B secure shell server implementations MUST support verification of both of these methods, and Suite B secure shell client implementations MUST support one or more of the x509v3-ecdsa-sha2-* based user authentication methods. Suite B does not require that these methods must be employed. The server's security policy determines which user authentication methods it will accept. The ceritificate based x509v3-ecdsa-sha2-* user authentication methods are merely two of the options that the server can be configured to accept. As described in [SSH-Auth], user authentication does not occur until the KEX protocol has been successfully completed and a secure tunnel has been established between the client and the server. The secure shell user authentication protocol uses the SSH_MSG_USERAUTH_* family of messages as described in [SSH-Auth]. The client MAY send a SSH_MSG_USERAUTH_REQUEST message which serves to both ask if the proposed public key authentication methods is acceptable to the server and to convey the user's public key to the server. The structure of this type of message is: byte SSH_MSG_USERAUTH_REQUEST string user_name // in ISO-10646 UTF-8 encoding string service_name // service name in US-ASCII string "publickey" boolean FALSE string public_key_algorithm_name string public_key_blob When the public key algorithm is either x509v3-ecdsa-sha2-nistp256 or x509v3-ecdsa-sha2-nistp384, the public_key_blob MUST be an X.509v3 certificate containing the appropriate user public ECDSA key. Details on the structure and encoding of the X.509v3 certificate can Igoe Informational [Page 7] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 be found in section 2 of [SSH-X509]. A second type of SSH_MSG_USERAUTH_REQUEST message is used to perform the actual authetntication: byte SSH_MSG_USERAUTH_REQUEST string user_name // in ISO-10646 UTF-8 encoding string service_name // service name in US-ASCII string "publickey" boolean TRUE string public_key_algorithm_name string signature As described in section 3.3 of [SSH-ECC], an ECDSA signature consists of a pair of mpints. See section 5 [SSH-Arch] for a discussion on the use of mpints in secure shell. When x509v3-ecdsa-sha2-* user authentication is being used, the public key blob in the SSH_MSG_USERAUTH_REQUEST is an octet string containing the user's X.509v3 followed by an ECDSA signature of the session identifier. The ECDSA signature is a pair of secure shell mpints, Additional authentications MAY be requested once the certificate based ECDSA authentication has been successfully completed. 4. Confidentiality and Data Integrity of SSH Binary Packets Secure shell transfers data between the client and the server using its own binary packet structure. The SSH binary packet structure is independent of any packet structure on the underlying data channel. Each content of each binary packet and portions of the header are encrypted and each packet is authenticated with its own message authentication code. AES GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity. 4.1. Galois/Counter Mode [SSH-GCM] describes how AES Galois Counter Mode is to be used in secure shell. Suite B SSH implementations MUST use support AEAD_AES_GCM_128 and SHOULD support AEAD_AES_GCM_256 to provide both confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted. These algorithms rely on two counters: Invocation Counter: A 64-bit integer, incremented after each call to AES-GCM to process an SSH binary packet. The initial value of the invocation counter is determined by the SSH initialization vector. Igoe Informational [Page 8] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 Block Counter: A 32-bit integer, set to one at the start of each new SSH binary packet and incremented as each 16-octet block of data is processed. Ensuring that these counters are properly implemented is crucial to the security of the system. The reader is referred to [SSH-GCM] for details on the format, initialization and usage of these counters and their relationship to the initialization vector and the SSV. 4.2. Data Integrity The reader is reminded that, as specified in [SSH-GCM], Suite B requires that all 16-octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet. 5. Rekeying Secure Shell allows either the server or client to request that the secure shell connection be rekeyed. Suite B places no constraints on how frequently this is to be done, but it does require that the cipher suite being employed MUST NOT be changed when a rekey occurs. 6. Security Considerations The security considerations of [SSH-Arch] apply. 7. References 7.1. Normative References [AEAD] McGrew, D., "An Interface and algorithms for Authenticated Encryption", RFC 5116, January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC5759] Solinas, J. and L.Zieglar, Suite B Certificates and Certificate Revocation List (CRL) Profile, RFC 5759, January 2010. [SSH-Arch] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. Igoe Informational [Page 9] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 [SSH-Auth] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [SSH-Tran] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SSH-ECC] Green, J. and D.Stebila, Ed., "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, December 2009. [SSH-GCM] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, August 2009. [SSH-X509] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", draft-igoe-secsh-x509v3-01 (work in progress), January 2009. 7.2. Informative References [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-30D, November 2007. [NIST] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1 v2.0, May 2009, . [SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000. . Author's Addresses Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency EMail: kmigoe@nsa.gov Acknowledgement Igoe Informational [Page 10] Internet Draft draft-igoe-secsh-suiteb-01 Feb 17, 2010 Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Igoe Informational [Page 11]