Re: [OPSEC] minutes part 2

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

Hi Ran,

Thanks for the conclusion, but the talk here is about 2 documents.

The first document is about "Issues with crypto mechanisms in existing
routing protocols" and the second document is the support of a minimum
set of crypto algorithms to get interoperability because multiple
Crypto Algorithms are currently supported for the same protocol. This
is in line with what has been done in IPsec.

What you seem to state is whether a particular crypto algorithm is
better than the other for the IGP cases. The documents about adding
other crypto algorithm support for IGP is already part of the
respective IGP working group. You have been added as a co-author of
one such draft and have authored another one. If you have issues
regarding this we can discuss this but the IGP working group is a part
of the document. Please raise the issues in the correct forum.

If my language is not clear, do let me know if we can discuss the same
in Hindi, Kumaoni, Gujarati or any other language that I know. I am
sorry I am not as well versed in English. :))

> Separately, I'm pleased that there is agreement that work on
> Key Management for IGPs would be useful.  An "IGP key management
> requirements" draft might be a reasonable place for someone to start.
Yes there has always been consensus and like I said the same has been
talked about multiple times in the SAAG list. If you have a solution
please propose it in the right forum and we can work on this.

Thanks again,
Vishwas

On Tue, Dec 16, 2008 at 3:40 PM, R Atkinson <[e-mail]> wrote:
>
> On  16 Dec 2008, at 14:18, Vishwas Manral wrote:
>>
>>  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.
>
> I'm not clear which document you are referring to.
>
> My comments were reactions to the meeting minutes,
> as the Subject line indicated and the quoted text indicated.
>
> OSPF with Digital Signatures is an existing mechanism (RFC-2154).
> Is it discussed at the same level of detail as other 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.
>
> I can't parse the above, terribly sorry.
>
>> 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.
>
> To the extent you are describing an operational security matter
> with routing protocols and IPsec, which seemed to be your prior claim,
> then that is indeed within charter for the IETF OPsec WG (i.e. here).
>
>> 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.
>
> Here are some references:
>        RFC-2082
>        RFC-4822
>        RFC-5304
>        draft-rja-ospf-hmac-shs-00.txt [1]
>
> Some folks on this list might or might not have read:
>        draft-ietf-isis-hmac-sha-07.txt
>        draft-ietf-ospf-hmac-sha-03.txt
>        draft-ietf-ospf-md5-02 [1]
>
> [1] A search engine is best to find this, as it is defunct.
>
>>>> 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.
>
> Generally, they have been, for example in the references above.
>
>> 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.
>
> RFC-2328, Page 243, makes a narrow precise claim:
>
>   "...is believed to be secure against passive attacks and
>   provide significant protection against active attacks."
>
> No claim that the mechanism is secure against all nor
> even against most active attacks is made by the OSPF RFC.
>
> Separately, the several mechanisms' various limitations
> are widely understood within the Internet community,
> as was evident throughout the KMART BOF.  The discussion
> there was not so much about the current issues, which were
> believed to be well understood, as about possible futures.
>
>>> - 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.
>
> Which specific cases ?
>
> Please provide a URL for your note to the OPsec list
> where you detailed those cases.  I have looked, and
> I can't find that note in the OPsec list web archives,
> terribly sorry.
>
>>> - 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!!!
>
> Thank you.  So, for now, we don't know of any active attacks
> being undertaken against any IGP.  There might have been some,
> I think we all agree, but we don't actually know of any.
>
> So we agree that we don't have any known active attacks,
> and that we have existing mechanisms that users believe
> are suitable for their threat environment.
>
>>> 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.
>
> (My last note to the OPsec list repeated the main comments from me
> that seem to be missing from the KMART meeting minutes.)
>
>> 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.
>
> IETF OPsec is an appropriate forum to discuss both risks and
> possible future directions for IGPs in general.  (Of course,
> any protocol specification work would need to be undertaken
> elsewhere. :-)
>
>>> 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?
>
> Ah, try to change the topic and ask a different question,
> rather than read RFC-2154 and comment upon it.  Interesting.
>
> In general, I have long suggested that AH is a reasonable approach
> to protecting IGPs.  AH, or for that matter ESP, isn't perfect
> either, but using IPsec is different and also seems like a
> reasonable approach that someone might take.
>
> Historically, one of the primary reasons that the IGPs have their
> own mechanisms was that AH/ESP availability in routers during the
> middle 1990s was either limited or non-existent (depending on
> which router platform one considers).  Had IPsec been widely
> available in routers, and implemented in a way that facilitated
> its use with IGP authentication, the IETF might well have avoided
> going down the path of per-IGP authentication mechanisms.
> The same basic history applies to TCP MD5 to protect BGP,
> and explains why AH/ESP aren't widely used today to protect BGP.
>
> (And, just to be clear, I have no issues with anyone proposing
> or defining new mechanisms.  My own sense -- opinion -- is that
> for a new mechanism to be "interesting" it either needs to be
> a lot simpler to deploy than what is on the shelf right now
> and with similar risk reduction properties OR the new mechanism
> needs to provide significantly better risk reduction properties.
> RFC-2154 provides significantly better risk reduction properties
> than any of the existing mechanisms.  Ultimately, the market
> decides what gets deployed, of course.)
>
> I don't think, however, that the facts available right now
> justify this WG formally encouraging users to move to SHA
> (or HMAC-SHA) authentication from some other existing IGP
> authentication approach.
>
>> I have suggested a way like using BTNS for the same.
>
> Great.  It is always good to have more ideas for the
> community to consider.
>
>> 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.
>
> My comments were on the meeting minutes, as the Subject line and the
> text I quoted indicated, not on any particular draft.
>
> I'm unclear which draft you are referring to above.
>
>> 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.
>
> I haven't seen any email indicating that anyone was actually
> implementing any of the SHA mechanisms.  Perhaps that note
> got lost in transit someplace.
>
>> 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.
>
> Users would be interested to know whether/when implementations
> are likely to exist.
>
> The OPsec meeting minutes indicated (perhaps just confusing wording ?)
> that a proposal was made that this OPsec WG should encourage all users
> to move to HMAC-SHA  -- which is very difficult to do if multiple
> implementations are not readily available.
>
>>>> 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 you agree above that HMAC-SHA is not necessarily stronger,
> and has similar properties to the existing mechanisms --
> so far as any of us are aware right now.
>
> And we all hope that if anyone hears otherwise, they will share
> that information here.
>
> To Summarise:
>
> From the meeting minutes, and given the agreement just above,
> it seems that the proposal discussed in the meeting minutes was
> to encourage users to move to a mechanism that (1) isn't obviously
> better and that (2) we know relies upon algorithms (i.e. SHA)
> that NIST is in the process of deprecating (due to concerns
> about SHA that are equivalent to the concerns about MD5).
>
> The only reason that I know of to move to SHA is to comply
> with some local organisational policy.   That policy-compliance
> reasoning is what drove the creation of RFC-4822, pure and
> simple.
>
> So it seems non-obvious to me that this WG should make a
> recommendation that users migrate to HMAC-SHA mechanisms
> in preference to other mechanisms.
>
> Separately, I'm pleased that there is agreement that work on
> Key Management for IGPs would be useful.  An "IGP key management
> requirements" draft might be a reasonable place for someone to start.
>
> Yours,
>
> Ran
> [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