Re: [OPSEC] minutes part 2

Hi Ran,

Thanks again for the thoughtful comments. Most of the comments are
about solutions to get the problems solved. Let me again state that
this document lists issues with existing cryptographic mechanisms. It
is not a solutions document, if we have solutions like Digital
Signatures we can have the mechanisms. If you do not agree to the
solutions drafts of which you are a co-author (and the work is in
other working groups), we can see what can be done.

> (NB: All of my references to "SHA" include "SHA1 and "SHA2" also.)
>
> On  16 Dec 2008, at 12:27, Vishwas Manral wrote:
>>
>> 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).
>
> Your claim above is not obvious.
> Please explain when/why you believe the claim above is true.
Please see the discussion on the IPsec Maintainance working group.
Check the topic "Deep Inspecting ESP-NULL Packets" and the related
draft solutions currently being proposed. However this is not in the
scope of this document or discussion. If you have issues with this let
us discuss the same in the right forum.

>>> 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.
>
> That is NOT true for any of the IGP authentication RFCs or I-Ds.
> In fact, the IGP authentication RFCs tend to be unusually clear
> about the limitations of those mechanisms.
I opened the base OSPF RFC Page 242 please note that they talk about
only security when athentication is enabled. They do not delve into
issues that might occur with the security mechanisms themselves into
picture.

>> Our aim is to bring out issues even when cryptographic
>> authentication is available.
>
> The limitations are generally already documented in the IGP
> authentication documents' "Security Considerations" sections.
No it isnt. Can you please map the RFC2328 security section with the
OSPF vulnerabilities mentioned. Please do the same exercise for BFD,
or for other protocols. It will be clear what we are talking about.

>>> 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."
>
> Not at all.  This looks like an English language issue to me:
May be I misunderstood what you stated.

> - All IGP attacks would have to be insider attacks,
>  because external packets are normally filtered anyway.
I have mentioned cases where they may not be able to be filtered. This
is an old discussion please go through the IPsec archives and you will
get the gist.

> - I am not aware of any IGP attacks ever occurring in the
>  deployed world.  There might be some, but I am not aware
>  of any published reports during the past ~20 years.
> - If someone has seen an actual active attack on any IGP,
>  that would be VERY interesting to learn more about.
Fair enough!!! Like I said we do not leave the door open in the house
because noone has broken into the house yet. :)

>> 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.
>
> Network operators have a range of mechanisms available now in shipping
> routers.  Which mechanisms, if any, make sense to deploy is entirely
> up to their judgement -- based on their risk/threat model for their
> specific deployment.
>
>> 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.
>
> Again, there are a range of existing mechanisms that network operators
> can choose to use -- and there seem to be no reports of any IGP attack
> in the real world.
Please note my basic comment mentioned above.

>>> 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.
>
> You personally might have different goals for IGP authentication,
> but the various mechanisms extant (excepting RFC-2154) were only
> designed to protect against passive attacks (as described in RFC-1704).
>
> I have either authored or co-authored every one of those IGP mechanisms
> (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the
> OSPF RFCs).  They protect against a limited set of issues.  The
> limitations are widely understood in the community.  For example,
> at the BOF held at IETF/Dublin, the entire room appeared to understood
> from the beginning that the current mechanisms are very limited.  I was
> quite clear in my comments during that BOF that the current mechanisms
> are limited.
>
> If one wants more, then the work that other folks have done with
> "Digital Signatures" (RFC-2154) seems like the right direction to go.
> That approach provides MUCH more comprehensive protections than
> any other current mechanisms.  (This is all a rehash of comments
> I made during the KMART BOF at IETF/PHL, not all of which comments
> made it into the minutes.)
If you made comments in the KMART which were not shared, please share
them with us. If you have some Digital Signature based algorithm in
mind please bring it up in the right context in the right forum. We
have had discussions about this in the SAAG group too.

> IS-IS and RIP likely would benefit from having equivalent specifications
> developed; for OSPF, RFC-2154 already exists.
>
> (I have no personal interest in developing such "Digital Signature"
> specifications for either IS-IS or RIP, but perhaps other folks here
> do.  I think it would be helpful to have the specifications completed
> and openly specified so that users who wanted something stronger
> could ask for something specific.)
>
>>> 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.
>
> None of which comments above address the text which you have quoted.
>
>>> % 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.
>
> RFC-2154 does not use IPsec.  So a comment about IPsec
> is orthogonal to the discussion.  Please go read RFC-2154.
The comments may be Orthogonal but if I am not mistaken they include
the use of Public Key Cryptography. We have problems of getting to the
PKI before we have the route etc, and this problem has been debated
too. Can you discuss why a mechanism of using IPsec is not better than
the mechanism you mention?

I have suggested a way like using BTNS for the same.

>>> 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.
>
> Yes, of course -- to my own knowledge.
>
> Do you know of anyone other than US DoD that wants this ?
> (US DoD are the only ones that I can identify, and they are
> saying their interest is only for "policy reasons".)
>
> If so, which users ? which RFPs ?
>
> For that matter, are there any users/operators on this list
> that have concrete plans to move to SHA for IGP authentication
> anytime soon ?
>
>> As noted by the Routing AD's, IETF manadates we move out of support
>> for MD5 and into supporting other algorithms as stated.
>
> Yes, the requirement is for algorithm agility, which we already had
> with the older Keyed-MD5 mechanisms.  The mechanisms themselves
> were algorithm-independent, although only one algorithm happened
> to be specified at the time (due to limited user interest).
>
> Algorithm agility is a fine thing, as I noted in a paper written
> for IEEE Network [1], but it is different from urging folks
> to change their deployed algorithms.  I had suggested that
> changing the deployed algorithm from MD5 to SHA seemed unwarranted.
> You haven't addressed that comment.
I said it is not mentioned in the draft. The draft is an issues draft
and does not talk about using MD5 or SHA1, it gives issues with the
current crypto mechanisms.

>>> 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. :))
>
> Please do name all of the names. :-)
> I think it would be helpful for everyone to know which
> implementations have already shipped and which might be
> coming soon.
Well we have disccused this and you are on the CC list for the same. I
do not have contacts in all the vendors, so cannot tell you for now.
Once the draft is to be made a standards track we can do the
implementation report and get the data. Again this is an aside and
this is not part of the draft.

>>> 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.
>
> Given that you agree the concerns are the same,
> then why does your draft push SHA over MD5 ?
>
>>> 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.
>
> Moving to HMAC-SHA1 does NOT necessarily improve security
> over current algorithms.
>
> Moving to HMAC-SHA1 does mean that the CPU on a router
> receiving a DOS attack via some IGP would be more severely
> impacted (because SHA1 is more computationally expensive
> than MD5).[2]
>
> In fact, there are no known attacks (so far) upon any of these:
>        - Keyed MD5
>        - HMAC MD5
>        - HMAC SHA/SHA1/SHA2
>
> [If someone knows of a published attack on any of the above,
> please do post a full bibliographic citation here, so that WG
> participants can go find/read the paper in question.
> If some new discovery has happened, I'm personally quite keen
> to learn about it. :-]
I agree so am I and the rest of the world.

> So I've shown in my earlier note that there are equivalent concerns
> with aspects of both cryptographic hash functions specified
> by the IETF:
>        - MD5
>        - SHA/SHA1/SHA2
>
> And we know from the URL I provided earlier that NIST is actively
> moving to deprecate all use of SHA/SHA1, including HMAC-SHA1.
>
> So one can see that there is no obvious net gain for users moving
> to HMAC-SHA for IGP authentication, relative to either HMAC-MD5
> or Keyed-MD5.  Moreover, there is increased impact on the router CPU
> (and hence the router control plane generally) of a prospective
> DOS attack on IGP packets if any form of SHA is used.[2]
>
> And to repeat another central point:
>
> - Key management for IGP authentication really could benefit from
>  some IETF standards work.  It would make any of this MUCH easier
>  to configure and deploy.  MSEC and Kerberos are among possible
>  approaches to IGP key management.  For this group, the role might
>  be to draft an "IGP KM Requirements" document for the other WGs
>  to work from.
I agree we need to get a solution for this and we are seeing
mechanisms that may help in such a case.

Thanks Ran,
Vishwas
>
> Yours,
>
> Ran
> rja@extremenetworks.com
>
>
> [1] R. Atkinson, "Toward a More Secure Internet",
>    IEEE Computer, Vol. 30, Number 1, January 1997.
>
> [2] One example DOS attack was presented in an IETF WG session
>    by someone else some years back (1990s).  Basically, the
>    adversary creates a packet that is syntatically valid to
>    the IGP specification, then puts arbitrary bits into the
>    Authentication Data field of the packet, and sends it to
>    a router.  The receiving router receives the packet and
>    the router CPU then performs expensive cryptographic computations
>    that are all wasted CPU cycles (because the bits in that
>    field were arbitrary) before tossing the DOS IGP packet.
>    Other DOS attacks exist, of course, this is just an example.
>
>
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec