draft-miller-secsh-umac-00.txt

[Damien Miller <djm%mindrot.org@localhost>]

Hi,

Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as
a SSH MAC. OpenSSH -current implements the umac-64 method described
in the draft under the name "umac-64%openssh.com@localhost".

We'd be interested in hearing from anyone else who wants to implement it.

-d



Network Working Group                                          D. Miller
Internet-Draft                                                P. Valchev
Intended status: Standards Track                                 OpenSSH
Expires: December 13, 2007                                 June 11, 2007


          The use of UMAC in the SSH Transport Layer Protocol
                     draft-miller-secsh-umac-00.txt

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 December 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This memo describes the use of the UMAC Message Authentication Code
   in the SSH transport protocol.









Miller & Valchev        Expires December 13, 2007               [Page 1]

Internet-Draft     UMAC message authentication for SSH         June 2007


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  MAC calculation . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  New MAC methods . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  umac-32 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.2.  umac-64 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.3.  umac-96 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.4.  umac-128  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 6





































Miller & Valchev        Expires December 13, 2007               [Page 2]

Internet-Draft     UMAC message authentication for SSH         June 2007


1.  Requirements notation

   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.  Overview

   SSH [RFC4251] is a popular protocol for secure remote login and data
   transfer on the Internet.  Among the security properties that SSH
   offers is integrity of communication against active adversaries.
   This integrity is provided in the SSH transport protocol [RFC4253]
   through the use of a per-packet Message Authentication Code (MAC).

   This memo describes the use of the UMAC Message Authentication Code
   [RFC4418] in the SSH transport protocol.  UMAC offers improved
   performance over the current HMAC-based MACs supported by SSH.
   Furthermore, UMAC represents a different cryptographic approach to
   message authentication to that of HMAC, and its use in SSH would
   provide a diversity that may be of benefit if HMAC or one of its
   underlying hash algorithms is found to be vulnerable to a new attack.

   UMAC offers a choice of four authentication tag sizes: 32, 64, 96 and
   128 bits.  This allows users to trade between fast, compact tags and
   longer tags that are slower to generate but offer better security.
   These four tag sizes are represented in the new MAC methods
   introduced in this memo: "umac-32", "umac-64", "umac-96" and "umac-
   128".


3.  MAC calculation

   Message authentication tags in the SSH transport protocol are
   specified to be calculated over the packet sequence number followed
   by the entire unencrypted packet:

           mac = MAC(key, sequence_number || unencrypted_packet)

   However, UMAC accepts a 64 bit nonce as an explicit input to MAC
   calculation.  In order for the security proofs that accompany UMAC to
   apply, this nonce must never be repeated under a given key.  In the
   context of the SSH protocol, this may be achieved by using the packet
   sequence number as the nonce.  The sequence number is guaranteed to
   be unique over the life of the MAC key by the requirement that
   implementations perform a key re-exchange before the sequence number
   wraps (section 9.3.3 of [RFC4251]).




Miller & Valchev        Expires December 13, 2007               [Page 3]

Internet-Draft     UMAC message authentication for SSH         June 2007


   To use the sequence number as the MAC nonce, it is encoded into a SSH
   protocol uint64 (as described in section 5 of [RFC4251]) and it is
   supplied to the UMAC algorithm instead of prepending it to the packet
   to be authenticated:

           mac = UMAC(key, sequence_number, unencrypted_packet)

   Note that, because the sequence number is a 32 bit quantity, the
   initial 32 bits of the nonce will always be zero.


4.  New MAC methods

   This memo introduces four new MAC methods, one for each UMAC
   authentication tag length specified in [RFC4418]: "umac-32",
   "umac-64", "umac-96" and "umac-128".

4.1.  umac-32

   Calculate message authentication tags using the UMAC-32 algorithm
   specified in [RFC4418], section 4.2.

4.2.  umac-64

   Calculate message authentication tags using the UMAC-64 algorithm
   specified in [RFC4418], section 4.2.

4.3.  umac-96

   Calculate message authentication tags using the UMAC-96 algorithm
   specified in [RFC4418], section 4.2.

4.4.  umac-128

   Calculate message authentication tags using the UMAC-128 algorithm
   specified in [RFC4418], section 4.2.


5.  Security Considerations

   As mentioned above, it is imperative that implementations perform a
   re-keying operation before reusing a packet sequence number as a UMAC
   nonce.  Implementations conforming to [RFC4251] are already required
   to do this.







Miller & Valchev        Expires December 13, 2007               [Page 4]

Internet-Draft     UMAC message authentication for SSH         June 2007


6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC4418]  Krovetz, T., "UMAC: Message Authentication Code using
              Universal Hashing", RFC 4418, March 2006.


Authors' Addresses

   Damien Miller
   OpenSSH

   Email: djm%openssh.com@localhost


   Peter Valchev
   OpenSSH

   Email: pval%openssh.com@localhost
























Miller & Valchev        Expires December 13, 2007               [Page 5]

Internet-Draft     UMAC message authentication for SSH         June 2007


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@localhost.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Miller & Valchev        Expires December 13, 2007               [Page 6]