[secdir] Review of draft-ietf-ospf-hmac-sha-05.txt
"Hilarie Orman" <ho@alum.mit.edu> Mon, 20 July 2009 20:00 UTC
Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E1F3A6DB1; Mon, 20 Jul 2009 13:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGlSXYJBG1KB; Mon, 20 Jul 2009 12:59:53 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 1BB363A6A22; Mon, 20 Jul 2009 12:59:53 -0700 (PDT)
Received: from mx02.mta.xmission.com ([166.70.13.212]) by out01.mta.xmission.com with esmtp (Exim 4.62) (envelope-from <hilarie@purplestreak.com>) id 1MSz1P-0005S0-TF; Mon, 20 Jul 2009 13:59:39 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1MSz17-00083N-Q1; Mon, 20 Jul 2009 13:59:22 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n6KJvkko016676; Mon, 20 Jul 2009 13:57:46 -0600
Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n6KJvjQv016672; Mon, 20 Jul 2009 13:57:45 -0600
Date: Mon, 20 Jul 2009 13:57:45 -0600
Message-Id: <200907201957.n6KJvjQv016672@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Cc: rja@extremenetworks.com, mjbarnes@cisco.com, mfanto@aegisdatasecurity.com, tony.li@tony.li, acee@redback.com, manav@alcatel-lucent.com, akr@cisco.com, riw@cisco.com
Subject: [secdir] Review of draft-ietf-ospf-hmac-sha-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2009 20:00:00 -0000
Review of draft-ietf-ospf-hmac-sha-05.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. OSPFv2 is a routing protocol, and its specification includes a description of using a cryptographic key with a hash function for the purpose of message authentication. This draft specifies the use of different hash algorithms and a different way of combining the key with the data in order to form the authentication value sent with the messages. "Introduction The creation of this addition to OSPFv2 was driven by operator requests that they be able to use the NIST SHS family of algorithms in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic Authentication." A reference (minutes of a NANOG meeting?) would be helpful. Section 3 gives SHA-1 a "should". Why? I can see a "should" on MD5 for backward compatibility, but SHA-1 should have died aborning. Section 3.1 says that the combining method is described in section 3.2, but 3.3 is the actual location. Section 3.2, in the paragraph about authentication keys, refers to "K in section 3.2 above". This makes no sense; the reference should probably be deleted. In section 3.3: "K is the selected OSPFv2 key". The statement should use the terminology of section 3.2 and say "K is the authentication key for the OSPFv2 security association". Section 3.3: "B is the block size of H, measured in octets, rather than bits". Two problems: 1. the indentation format is irregular, 2. nothing has suggested measuring in bits, so the "rather than" is gratuitous. The same holds for the comment regarding the length of L. Section 4, Security Considerations. The second paragraph, while correct in the sense that it says nothing wrong, does not do a good job of explaining the numerous "concerns". There should be a plausible argument about the value of switching to the SHA family, and a little more about the value of HMAC over prepended key. Is there a reference for the US govmt's preference for the SHA family? I don't think the section does justice to the problem of replay. It's my (perhaps flawed) understanding that RFC2838 strongly recommends using a random initial sequence number, so the comments about always starting from zero seem wrong (unless there is some reason to believe that implementations do not adhere to the RFC2838 guidance). Further, a passive observer of two sessions can insert replay packets, with appropriate sequence numbers, at any time, because the authentication key is static. RFC2838 seems to mandate a tear-down on any sequence number mismatch. Altogether, this seems more serious to me than the MD5 collisions. I think that a stronger statement about IPsec (I think that is what is meant by the penultimate paragraph in section 4; there is no reference) could be made. I'm not sure that "full digital signatures" would be a stronger authentication method. The number of authors exceeds the RFC editor's guidelines. I approve.
- [secdir] Review of draft-ietf-ospf-hmac-sha-05.txt Hilarie Orman
- Re: [secdir] Review of draft-ietf-ospf-hmac-sha-0… RJ Atkinson