Re: [OPSEC] minutes part 2

[R Atkinson <[e-mail]>]

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