Re: [secdir] Review of draft-ietf-ospf-hmac-sha-05.txt

[RJ Atkinson <[e-mail]>]

Hilarie,

Thank you very much for your careful review.  Thanks to your
efforts, several errors were caught and have been corrected.
A detailed response to your review follows in-line.

Earlier, Hilarie Orman wrote:
% Review of draft-ietf-ospf-hmac-sha-05.txt
%
%"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.

We do not know of a crisp reference that can be cited here.

Several of the authors have heard interest from operators;
operators are also present in OSPF WG meetings.  This draft
has been discussed in more than one OSPF WG meeting.

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

Changing this would reduce WG Consensus, so we have kept
the current text.

% Section 3.1 says that the combining method is described in section
% 3.2, but 3.3 is the actual location.

This correction has been made.

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

That sentence has been corrected to read:
	This is noted as "K" in Section 3.3 below.

% 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".

That correction has been made.

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

Changing the text would reduce WG Consensus.

It is believed that the current text is more clear
than the proposed edits would make the text.

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

The current text represents a compromise within the WG, and
is strictly correct.  Most importantly, it makes no claims
that are not supported by a reference to the literature.
Changing the text would reduce consensus in the WG.

Moving to the SHA family is primarily driven by operators
with local policy preferences for SHA (e.g. US/UK Governments).

% Is there a reference for the US govmt's preference
% for the SHA family?

The authors do not know of a specific reference to cite,
but are happy to accept the word of the Security AD.
At least one author has heard this directly from USG
employees.

% 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).

At least some implementations have not adhered to that
RFC-2328 guidance.  It is difficult to ascertain if those
implementations are in active use at present, as the OSPF
installed base is quite large.

% Further, a passive observer of two sessions can insert replay
% packets, with appropriate sequence numbers, at any time,
% because the authentication key is static.

Yes, provided the OSPF SA never changes, that is true.

It is at least conceivable that an operator would use
implementation-specific methods (e.g. a provisioning
script built around Tcl/Expect, SSH, and a particular
implementation's CLI) to create and remove OSPF SAs.
We do not discuss that approach in this draft because
it is inherently non-standard and this is a standards-
track document.

% RFC2838 seems to mandate a tear-down on any sequence
% number mismatch.

Tearing down the OSPF Security Association would cause
the OSPF routers to be unable to communicate, and interior
routing would fail.  This is considered strongly
undesirable in the operational world.

Changing the OSPF behaviour to mandate such a tear-down
would greatly reduce consensus within the OSPF WG.

% Altogether, this seems more serious to me than the
% MD5 collisions.

At least one author (me) agrees with the reviewer, but
some other authors are known to believe that use of MD5
is the greater vulnerability.  The existing text is,
therefore, a compromise.

In any event, in reaction to the preceding 4 comments,
portions of the Security Considerations text have been
revised to read as follows:

    This mechanism is vulnerable to a replay attack by any on-link
    node.  An on-link node could record a legitimate OSPF packet
    sent on the link, then replay that packet at the next time the
    recorded OSPF packet's sequence number is valid.  This replay
    attack could cause significant routing disruptions within the
    OSPF domain.

    Ideally, for example to prevent the preceding attack, each OSPF
    Security Association would be replaced by a new and different
    OSPF Security Association before any sequence number were reused.
    As of the date this document was published, no form of automated
    key management has been standardised for OSPF.  So, as of the
    date this document was published, common operational practice has
    been to use the same OSPF authentication key for very long
    periods of time.  This operational practice is undesirable for
    many reasons.  Therefore, it is clearly desirable to develop and
    standardise some automated key management mechanism for OSPF.

We further note that the IETF KMART effort has the subject of
the last paragraph above firmly within its sights.  There is
no obvious benefit to delaying this document until the KMART
process has finished its work.

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

We have edited that paragraph to read:

   Because of implementation considerations, including the need
   for backwards compatibility, this specification uses the same
   mechanism as specified in RFC 2328 and limits itself to adding
   support for additional cryptographic hash functions.  Also,
   some large network operators have indicated they prefer to
   retain the basic mechanism defined in RFC 2328, rather than
   migrate to IP Security, due to deployment and operational
   considerations.[RFC 4301] If all the OSPFv2 routers supported
   IPsec, then IPsec tunnels could be used in lieu of this
   mechanism.  This would, however, relegate the topology to
   point-to-point adjacencies over the mesh of IPsec tunnels.

% I'm not sure that "full digital signatures" would be a stronger
% authentication method.

That paragraph currently reads:
   If a stronger authentication were believed to be required,
   then the use of a full digital signature [RFC 2154] would be
   an approach that should be seriously considered.  Use of full
   digital signatures would enable precise authentication of the
   OSPF router originating each OSPF link-state advertisement,
   in addition to eliminating the replay issue that was noted
   above.

(Aside: The longish author list is the result of merging
2 drafts together.  There is both IESG and RFC-Editor
precedent for longish author lists in such a case.)

Yours,

Ran Atkinson
[e-mail]
(Active document editor)