Network Working Group K.M. Igoe Internet Draft National Security Agency Intended Status: Informational September 11, 2008 Expires: March 15, 2009 Suite B Cryptographic Suites for Secure Shell draft-igoe-secsh-suiteb-00 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 March 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Igoe Informational [Page 1] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 Abstract This document describes the basic architecture of a Suite B compliant implementation of the Secure Shell Transport Layer 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 Overview.................................................3 1.1. Suite B Elliptic Curves........................................3 2. Suite B SSH Security Mechanisms..................................3 2.1. Key Agreement..................................................3 2.2. Authentication.................................................3 2.2.1. Certificates.................................................4 2.2.2. Server Authentication........................................4 2.2.3. User Authentication..........................................4 2.3. Confidentiality and Data Integrity of SSH Binary Packets.......4 2.3.1. Galois/Counter Mode..........................................5 2.3.2. Initialization Vectors.......................................5 2.3.3. Data Integrity...............................................5 2.3.4. Confidentiality..............................................6 3. Rekeying.........................................................6 4. Security Considerations..........................................6 5. References.......................................................6 5.1. Normative References...........................................6 5.2. Informative References.........................................7 Igoe Informational [Page 2] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 1. Suite B Overview At the 2005 RSA Conference, Dan Wolf, then Chief of 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. This suite of cryptographic algorithms, known as Suite B, consists of publicly known and vetted algorithms. 1.1. Suite B Elliptic Curves There are two elliptic curves specified for use in Suite B SSH: 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]. 2. Suite B SSH Security Mechanisms 2.1. Key Agreement Suite B SSH uses elliptic curve Diffie-Hellmann (ECDH) to establish an unauthenticated ephemeral shared secret value (SSV) known to both the client and the server. See [SSH-ECC] and [SSH-Tran]. Suite B Basic ECDH on P-256 with SHA-256 ecdh-sha2-1.2.840.10045.3.1.7 Suite B High ECDH on P-384 with SHA-384 ecdh-sha2-1.3.132.0.34 The key agreement results in both the server and client having a common shared secret value (SSV). The encryption keys and initialization vectors needed by SSH are derived directly from the SSV using the specified hash function (SHA-256 for Suite B Basic and SHA-384 for Suite B High). 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 rekey results in the formation of a new SSV. 2.2. Authentication Suite B authentication uses the elliptic curve digital signature algorithm (ECDSA): Igoe Informational [Page 3] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 Suite B Basic ECDSA on P-256 with SHA-256 secg-ecc-1.2.840.10045.3.1.7 Suite B High ECDSA on P-384 with SHA-384 secg-ecc-1.3.132.0.34 2.2.1. Certificates All ECDSA signing keys MUST be authenticated using X.509 certificates. Details upon the use of such certificates can be found in [X.509]. In order to make certificate management easier, a Suite B High certificate MAY be used for authentication in Suite B Basic. However a Suite B Basic certificate MUST NOT be used for authentication with Suite B High. All implementations of Suite B SSH MUST support verification of both Suite B High and Suite B Basic signatures. 2.2.2. Server Authentication SSH server authentication is based upon the SSH_MSG_KEX_ECDH_REPLY message sent from the server to the client. This message MUST contain the server's ECDSA X.509 certificate. One small point needs to clarified here. SSH server authentication requires the server to sign a value EH (the Exchange Hash) formed by hashing the shared secret value together with data exchanged during the KEX protocol and in the initial handshake. The hash used to form EH is SHA-256 for Suite B Basic and SHA-384 for Suite B High. The ECDSA signature process begins by appropriately padding the EH and running through a hash function. This hash function is determined by the signer's certificate, not by the SSH key establishment protocol. 2.2.3. User Authentication 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 public key blob sent from the client to the server in the SSH_MSG_USERAUTH_REQUEST message MUST contain an X.509 certificate containing the user's ECDSA signing key. Additional authentications MAY be requested once the certificate based authentication has been successfully completed. 2.3. 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 Igoe Informational [Page 4] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 independent of any packet structure on the underlying data channel. Each binary packet is encrypted and carries its own message authentication code. 2.3.1. Galois/Counter Mode As defined in [SSH-GCM], Suite B SSH uses AES Galois/Counter Mode (GCM) to provide confidentiality and ensure data integrity. Suite B Basic AES-128 Galois/Counter Mode aead-aes-128-gcm-ssh Suite B High AES-256 Galois/Counter Mode aead-aes-256-gcm-ssh 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. 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. Insuring that these counters are properly implemented is crucial to the security of the system. 2.3.2. Initialization Vectors The SSH key establishment process provides both client and server with initialization vectors derived from the SSV, one IV for client to server traffic and a separate IV for server to client traffic. The size of the SSH-IV is determined by the size of the hash used, (32 octets for Suite B Basic and 48 for Suite B High). AES-GCM requires a 12-octet AES-IV, broken into a 4-octet (the fixed field) and a 64-bit integer (the initial value of the invocation counter). The first 4-octets of the SSH-IV are used to set the fixed field and the next 8-octets initialize the invocation counter (using network order in the conversion of the octet string to an integer). Each binary packet requires a distinct AES-IV. This is achieved by incrementing the invocation counter (modulo 2^64) after each binary packet has been processed. In theory one should ensure that no more than 2^64 binary packets are processed before the SSH connection is rekeyed, but is practice this will not be a problem. 2.3.3. Data Integrity Igoe Informational [Page 5] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 AES-GCM produces a 16-octet data integrity tag. Suite B requires that all 16-octets be used as the SSH data integrity value of the SSH binary packet. The AES-GCM authentication tag is formed using a 128-bit hash sub-key (HSK) formed by encrypting the all-zero block using the current encryption key. Since SSH uses different keys for the client to server and the server to client communications, each of these will have its own HSK. However these HSK's remain constant until the SSH connection is rekeyed. 2.3.4. Confidentiality AES requires a 16-octet input each time a 16-octet block of data is encrypted or decrypted. The 16-octet input consists of three fields: uint32 fixed; // 4 octets uint64 invocation_counter; // 8 octets uint32 block_counter; // 4 octets The fixed field is the first 4 octets of the SSH-IV derived from the SSV in the KEX procedure. The invocation_counter is initially set be the next 8 octets of the SSH-IV and is incremented modulo 2^64 whenever an SSH binary packet has been processed. The block_counter is set to one at the start of each SSH binary packet and incremented after each block of has been data in processed. (Setting the block_counter to zero is reserved for use in forming the authentication tag (GMAC) of the data.) 3. 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 or infrequently this is to be done, but it does require that the cipher suite being employed must not be changed when a rekey occurs. 4. Security Considerations The security considerations of [SSH-Arch] apply. 5. References 5.1. Normative References [AEAD] McGrew, D., "An Interface and algorithms for Igoe Informational [Page 6] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 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. [SSH-Arch] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [SSH-Auth] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [SSH-Mode] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, January 2006. [SSH-Tran] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [X.509] 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 3280bis, April 2008. 5.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. [SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000. [SSH-ECC] Green, J. and D.Stebila, Ed., "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", draft-green-secsh-ecc-02, January 2008. [SSH-GCM] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", draft-igoe-ssh-aes-gcm, April 2008. Igoe Informational [Page 7] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 Author's Addresses Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency EMail: kmigoe@nsa.gov Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Igoe Informational [Page 8] Internet Draft draft-igoe-secsh-suiteb-00 Sep 11, 2008 Administrative Support Activity (IASA). Igoe Informational [Page 9]