Re: [OPSEC] minutes part 2

["Vishwas Manral" <[e-mail]>]

Hi Ran,

Thanks for the comments. You have mixed a lot of things in one mail,
including current solutions, problems, future solutions, history, your
opinions and a lot more. Let us try to discuss things one at a time
and it will be helpful. I have taken the first major portion of the
mail for now and to discuss the comments on the "Issues draft".

On Tue, Dec 16, 2008 at 8:04 AM, 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. :-)
Thanks for the detailed mail. I hope this can compensate for you not
being able to attend the meeting. :)

> 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.
Thanks for the information about insider attacks. I have raised issues
with using IPsec ESP for OSPFv3 protection about 3 years back, as we
cannot block packets in all such cases (as the firewall may not know
of the contents inside the ESP packet). Although this is a "routine"
like you said we can add it is a solutions document. However the
document is about issues and not solutions.

> 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.
Agree its always the weakest link that anyone would want to exploit,
not the strongest one. However if you see most drafts "security
considerations" section, they state that using cryptographic
authentication is a panicia for all evils. Our aim is to bring out
issues even when cryptographic authentication is available.

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

This seems to contradict what you stated as the first point about
"First, let me observe that IGP attacks are all insider attacks."

Well we do not have to wait for the first attack to act, we need to
react even before the attacks occur. You may have noted a similar move
in all Security groups even though attacks themselves have not occured
yet.

Also note we have to consider the havoc to the forwarded traffic that
can be caused if the routing infrastructure is compromised. So the
effect of an attack is more than just attacking an end user site.

> 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.
Agree partially. It is a goal but not the only goal of cryptographic mechanisms.

> 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.
Comments given above.

> % 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.
IPsec with Manual Keying still states there can be no Replay protection.

> % 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.
The only known user interest to your knowledge. As noted by the
Routing AD's, IETF manadates we move out of support for MD5 and into
supporting other algorithms as stated.

> 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".)
We know of a few including a big router vendor. :))

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

> 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).
The urge is to get into HMAC-SHA1 not SHA1.

I will cover the rest in another mail some day later.

Thanks,
Vishwas

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