Re: [OPSEC] minutes part 2

["Glen Kent" <[e-mail]>]

I don't understand your concern. When I read the
draft-ietf-opsec-routing-protocols-crypto-issues  for the first time
what it told me was that Yes, using cryptographic authentication is
all fine but there can still be some attacks despite using such
schemes. What you're saying is that the attackers need not go that far
and that there are simpler ways to launch DoS attacks against the
routers. Agreed, so what? This doesn't make the existing issues with
crypto protection any less criminal? This also doesn't preclude the
need to document the issues that can exist with the current
authentication mechanisms. I could have understood your dissent if a
WG were proposing solutions to the problems cited in the issues draft
on the grounds that those are not needed, however, a draft such as
this needs to be present so that the community knows that
cryptographic protection as offered by IGPs is not a panacea to all
security problems - ISSUES still exist!

OPSEC must only document such issues. Its up to the other WGs to
decide whether they want to act on it or not.

Glen

On Tue, Dec 16, 2008 at 9:34 PM, RJ Atkinson <[e-mail]> wrote:
> 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
>
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec