Internet DRAFT - draft-igoe-secsh-suiteb
draft-igoe-secsh-suiteb
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]
