Re: [OPSEC] minutes part 2

[RJ Atkinson <[e-mail]>]

All,

This note is a response to parts of the above email.
(I was presenting a paper at a research conference,
so I was unable to attend IETF/MSP in person and
make these comments then/there.  I can't be in
two cities at the same time. :-)

First, let me observe that IGP attacks are all insider attacks.
Sites routinely block IGP packets from entering from outside
their administrative domain.  (This would be a sensible thing
for OPsec to recommend if it hasn't already done so.)
Similarly, ISPs normally block IGP packets from arriving
on customer-facing interfaces or other exterior interfaces.

Second, prospective attackers are both smart and lazy.  They
are not likely to use a computationally expensive attack
vector (e.g. something cryptographic) when a simpler/easier
attack (e.g. DoS on the router CPU) exists.

Third, I am not aware of any active attacks on any deployed
IGP.  I've worked at more than one network operator in the
past, and for multiple equipment suppliers.  I've never heard
of even one.  If active attacks were widespread or common,
then they would have received much more reporting in the
trade press (as different from the zero reports that I've
seen over the past ~20 years).

Fourth, the *only* goal of the various cryptographic IGP
authentication mechanisms (excepting: RFC-2154) always
has been to remove only the "passive attack" risks described
long ago in RFC-1704.  Such passive attacks are trivially
easy to mount, even easier than a simple DOS attack, which
is why they are sensible to protect against.

Fifth, the existing cryptographic authentication mechanisms
are not really widely deployed operationally.  Many enterprise
users don't enable any form of authentication.  Some enable
clear-text passwords; relatively few bother to enable
cryptographic authentication.  Among ISPs, security mechanisms
are more widely deployed, but even in that community the
existing cryptographic authentication mechanisms appear not
to be widely used today.  This is not because operators/users
are silly or uninformed.  Instead, this is because they are
performing sensible risk/threat analyses and deploying what
actually makes sense for their operational environments.

% OSPF cryptographic sequence number spoofing or replay

 From a technical perspective, these are solved problems.
Please see RFC-2154.  Note that the absence of commercial
implementations of RFC-2154 reflects the total absence
of user/operator concern about either of these issues,
along with user/operator concern about the complexity
of a digital signature approach.
% Need to move from md5 to stronger crypto.
There is no obvious reason for a site to move from either
Keyed-MD5 or HMAC-MD5 to something else.  There are no known
vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by
IETF routing protocols.  By contrast, moving to SHA will
significantly increase a router's vulnerability to DOS attacks,
while providing negligible decrease in risk.  (Also see
the comments 3 paragraphs down about SHA's own issues.)

There is only one known user with any interest in SHA
authentication for routing protocols.  They have said
that the only reason for that interest is "policy compliance".
Even they have not yet indicated that SHA support is required
of their equipment suppliers.

Further, there are no known shipping implementations of
SHA authentication for any IETF-specified IGP.  (I don't
know of any that are even "in progress".)

Also, the concerns about collision attacks on MD5 (which
are not known to affect either Keyed-MD5 or HMAC-MD5)
are not fundamentally different from the concerns about
collision attacks on SHA.

1.  Several published academic papers about SHA issues
  are quite easily found by an online search:
<http://scholar.google.com/scholar?q=SHA+attack&hl=en&lr=&btnG=Search>

2.  NIST is working to replace SHA anyway (Nov 2007 announcement)
<http://csrc.nist.gov/news_events/news_archive/news_archive_2007.html#nov20 
 >

So it seems silly to urge users to move to a security mode
(e.g. SHA) that those users can't actually acquire or deploy,
and whose underlying algorithm itself is likely to be deprecated
in the near future by its own standards body (SHA is a NIST Federal
Information Processing Standard).

% Keys shared across the broadcast domain,
% need to move to a stronger key identifier.

1.  All IGPs multicast/broadcast their update packets,
  so sharing a key across that same multicast/broadcast
  domain is not a silly approach.

2.  Adding a Key-ID does not actually increase the
  security of anything.  It can make it slightly simpler
  for an implementation to locate the correct Security
  Association to use in attempting to authenticate a
  received packet, however the most widely deployed
  implementations *ignore* the Key-ID and instead just
  try all configured and valid SAs on the router.

% For OSPFv3 relies on ipsec, because manual key sequence number,
% replay protection cannot be used.

See comment up top with reference to RFC-2154.

% IS-IS MD5 but no sequence number not notion of keyid
% for pdu key must be validated.

See previous comments.

Separately, IS-IS is carried directly over the link-layer,
so off-link attacks are automatically precluded.  This means
that the only possible threat model is an on-link insider.
There are simpler/easier attacks (e.g. DOS) on the routing
infrastructure.  So adding a sequence number doesn't really matter.
Again, the KeyID is merely an implementer convenience, rather than
some form of risk reduction.

% Need to update from md5

There are no known attacks on either Keyed-MD5 or HMAC-MD5,
so there is no obvious reason for a user/operator to deploy
SHA authentication (or OSPF with Digital Signatures).  Also
recall that SHA itself has published issues.

% ripv2, no authentication of ip or udp headers.  can change
% source address and receiver will still think it's a valid
% neighbor

If MD5 authentication is enabled, packets can't be forged.

If one wants something stronger, a completely different
"Digital Signature" approach (analagous to that described
in RFC-2154 for OSPF) is the right direction to head (as
the RIPv2 Authentication RFC already says).

None of the recent documents in IGP authentication make any moves
towards use of Digital Signatures, probably because there is no
visible user/operator interest in this.

% We need a distributed keyserver and the ospf guys need it
% even more than we do.

This is entirely believable, not because it increases security,
but because it solves real-world operational/deployment issues.

One logical approach to this would be to use a key distribution
center (e.g. Kerberos).  While Kerberos can be complex to deploy
on all hosts in a large campus network, largely because of varying
administrative domains, Kerberos is reportedly straight forward
to deploy among all routers within a single administrative domain
(although obviously it requires ordinary planning and care in
deployment).

At least one very large multi-continent ISP had deployed Kerberos
over 10 years ago.  Two widely deployed brands of router have
already shipped Kerberos support, so this approach might be
easier to get router implementers to support.  Folks interested
in this might want to put together a "requirements" draft as a first  
step.

% gathering a group of people to identify the needs and go and
% beat on msec

Agreed.  Using work from the IETF MSEC WG is another reasonable
approach to adding key management for IGPs.

% Second draft, minimum cryptographic requirements.  the fact is
% cryptographic algorithms continue to be attacked.  we need to
% keep track of this.  the idea of this document is to keep
% modifying it but to track the minimum requirements for  
interoperability

I see this document as largely valueless.  Most users/operators
aren't enabling any form of cryptographic authentication today,
because their risk/threat environment makes that not sensible
for their operational domain.

The market (i.e. users and RFPs) drive which IETF specifications
are widely implemented by equipment suppliers.  The days when
IETF recommendations were widely and automatically obeyed by
product managers at many equipment vendors has been gone
for more than a decade now.

I am not aware of *any* known attacks on any deployed IGP with
any form of cryptographic authentication configured.  If someone
has actually seen such himself/herself, please provide the details
here as that would be significant news.

Again, there are no known vulnerabilities in either Keyed-MD5 or
HMAC-MD5, and it is not obvious that SHA is necessarily either
better or stronger (although it is measurably more computationally
expensive for the router trying to authenticate a received packet).
So there is no obvious security reason for an operational
site to deploy something other than MD5.  Heck, many sites don't even
go that far today because their risk/threat model doesn't need it.

In summary, the actual *operational* issue that this group can
make an impact with would be to specify some requirements (from
an operator/user perspective) for IGP authentication key management
(so that IGP authentication is easier to configure/deploy/manage),
and then work with other appropriate groups (e.g. Kerberos, MSEC)
to have those groups add the necessary capabilities in their
protocols.  It seems to me that this would be a much better focus.

If folks really think that the current approaches to IGP authentication
aren't adequate, then they really ought to consider working on adding
"Digital Signature" support for RIPv2 + IS-IS and they also ought
to be asking their router suppliers to implement RFC-2154 support.

Yours,

Ran Atkinson
[e-mail]

_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec