SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
draft-dbider-sha2-mac-for-ssh-03

Abstract

This memo defines algorithm names and parameters for use of some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol.

This document adds new Message Authentication Code (MAC) algorithms to the set defined in RFC 4253 [RFC4253].

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 May 17, 2012.

Copyright Notice

Copyright (c) 2011 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 Simplified BSD License.

1. Overview and Rationale

SSH [RFC4251] is a very common protocol for secure remote login on the Internet. Currently, SSH defines data integrity verification using SHA-1 and MD5 algorithms [RFC4253]. Due to recent security concerns with these two algorithms [RFC6151][RFC6194], implementors and users request support for data integrity verification using some of the SHA-2 family of algorithms.

Please send comments on this draft to ietf-ssh@NetBSD.org.

1.1. Requirements Terminology

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 [RFC2119].

2. Data Integrity Algorithms

This memo adopts the style and conventions of [RFC4253] in defining new data integrity algorithms.

The following new data integrity algorithms are defined:

hmac-sha2-256     RECOMMENDED   HMAC-SHA2-256
                                (digest length = 32 bytes,
                                 key length    = 32 bytes)

hmac-sha2-256-96  OPTIONAL      first 96 bits of HMAC-SHA2-256
                                (digest length = 12 bytes,
                                 key length    = 32 bytes)

hmac-sha2-512     OPTIONAL      HMAC-SHA2-512
                                (digest length = 64 bytes,
                                 key length    = 64 bytes)

hmac-sha2-512-96  OPTIONAL      first 96 bits of HMAC-SHA2-512
                                (digest length = 12 bytes,
                                 key length    = 64 bytes)
        

The HMAC mechanism is defined in [RFC2104].

The SHA-2 family of algorithms are defined in [FIPS-180-3].

Sample code for the SHA-based HMAC algorithms are available in [RFC6234]. The variants HMAC-SHA2-224 and HMAC-SHA2-384 algorithms were considered, but not added to this list as they have the same computational requirements of HMAC-SHA2-256 and HMAC-SHA2-512 respectively and do not seem to be much used in practise.

Test vectors for use of HMAC with SHA-2 are provided in [RFC4231].

Users, implementors, and administrators may choose to put these new Macs into the proposal ahead of the REQUIRED hmac-sha1 algorithm defined in [RFC4253] so that they would be negotiated first.

3. IANA Considerations

This document augments the MAC Algorithm Names in [RFC4253] and [RFC4250].

IANA is requested to updte the SSH algorithm registry with the following entries:

MAC Algorithm Name      Reference       Note
hmac-sha2-256           This draft      Section 2
hmac-sha2-256-96        This draft      Section 2
hmac-sha2-512           This draft      Section 2
hmac-sha2-512-96        This draft      Section 2
        

Section 4.6.2 in [RFC4250] specifies that new names MUST be done through the IETF CONSENSUS method, as described in [RFC2434].

Users, implementors, and administrators may choose to put these new Macs into the proposal ahead of the REQUIRED hmac-sha1 algorithm defined in [RFC4253] so that they would be negotiated first.

4. Security Considerations

The security considerations of RFC 4253 [RFC4253] apply to the is document.

The current attacks on HMAC-SHA1 do not yet seem to indicate a practical vulnerability when used as a message authentication code. NIST publications NIST SP 800-107 [800-107] and NIST SP 800-131 [800-131] suggest that HMAC-SHA1 and HMAC-SHA2-256 have a security strength of 128 bits and 256 bits respectively.

Even so, many users seem to be interested in the perceived safety of using a stronger algorithm.

5. References

5.1. Normative References

5.2. Informative References

Authors' Addresses

Table of Contents

• 1. Overview and Rationale
• 1.1. Requirements Terminology
• 2. Data Integrity Algorithms
• 3. IANA Considerations
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses