Subject: Re: [OPSEC] minutes part 2

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 20:28:11 -0500

Vishwas,

Can we please get answers to these questions -- which in fact
are entirely on topic for the OPsec WG, since they are all
operational security matters ?

(Single quotes are from me; double-quotes are from Vishwas'
earlier emails.)

1:  OSPF with Digital Signatures
> OSPF with Digital Signatures is an existing mechanism (RFC-2154).
> Is it discussed at the same level of detail as other mechanisms ?

2:  Filtering of IGP packets
>> I have mentioned cases where they may not be able to be filtered.
>
> 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.

This is an immediate operational security issue, if true.
I'm sure I'm not the only person who'd like to understand
the claim more precisely.

3: User interest in SHA mechanisms for IGP authentication
> 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 ?

4:  Availability of SHA mechanisms for IGP authentication
> 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. :))

Which ?  How many ?  When ?
Are they shipping now or in progress now ?

5:  Claims made by existing IGP authentication documents
>> However if you see most drafts "security considerations" section,
>> they state that using cryptographic authentication is a panicia for  
>> all evils.

I can't find even one RFC or I-D that says anything similar
to "using cryptographic authentication is a panacea for all evils".

I checked a bunch of documents, which I enumerated in an earlier
email; none contained any such language.

Which specific document does this ?  and on which page ?

Thanks,

Ran

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 16 Dec 2008 17:59:26 -0800

Hi Ran,

This is a more precise mail. Thanks a lot for the effort.

>> Is it discussed at the same level of detail as other mechanisms ?
No, it is not discussed in the document. The RFC you mention is an
Experimental RFC. The draft talks about "Issues with Existing
Cryptographic Mechanisms with Routing Protocols". We can discuss the
same however (though I would feel it may not exactly fit the draft).

> the claim more precisely.
I have mentioned it in the mail earlier and will mention it again.
When an IGP packet is in an ESP packet (even if it is ESP NULL), a
middlebox cannot filter the packet, because the middlebox does not
know if the packet has been encrypted or not.

http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a
link to the first page of the discussion. The discussion is a long
discussion and
http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-00 is
a document trying to address the same.

>> If so, which users ? which RFPs ?
We have customers who have asked for the crypto algorithms. I do not
think this group is to discuss about particular RFP's.

Again let me state it. If you think there are issues with supporting
SHA algorithm for IGP's, please mention the issues in the WG where the
drafts belongs. Like I have mentioned multiple times, you have been
added as an author of one such document youself.

> Are they shipping now or in progress now ?
We are implementing this and so is Cisco (this has been brought to
your notice in private mails earlier but you still bring the issue).
The OSPF WG chair(Acee) knows about the other implementaions of the
draft by vendors. If we have an implementation report we will get more
details then, as I do not have information of all vendors.

It sounds interesting that you want to know vendors implementing some
solutions because we are writing an issues document with already
existing mechanisms.

>>> they state that using cryptographic authentication is a panicia for all
>>> evils.
>
Please check the drafts in this page
http://www.ietf.org/html.charters/ospf-charter.html .
As an example see the first draft in the list it states
http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt

Security Considerations

   The described technique provides the same level of security as OSPFv2
   protocol by allowing LLS data to be authenticated using the same
   cryptographic authentication that OSPFv2 uses (see Section 2.5 for
   more details).

   OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH].
   With IPsec, the AH (Authentication Header), ESP (Encapsulating
   Security Payload), or both are applied to the entire OSPFv3 payload
   including the LLS block.

Our aim is to bring forward the issues with the cryptographic
mechanisms. The issues with the cryptographic mechanisms are not
stated in the base RFC either and I have mentioned this to you
clearly. Because most RFC's draft seem to state something similar to
the above.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 21:19:31 -0500

> same however (though I would feel it may not exactly fit the draft).

It would be helpful to discuss also, as that is an IGP authentication
mechanism that we have today and that could be used.  I'm told that
there is at least one implementation, although I'm unclear on how
available that implementation might be.

> discussion

Thank you for the URLs.

> We have customers who have asked for the crypto algorithms.

Other than US DoD ?    Very Interesting.
Are they Enterprise users ?  Service Providers ? other ?

Is this for policy reasons or does a particular threat model
drive them in that direction ?

> your notice in private mails earlier but you still bring the issue).

I do not have such any private emails; they must have been lost in  
transit.

Thanks for the clarity.  So at least 2 implementations are reported
to be in progress, and none are available now.  That is useful to  
understand.

> solutions because we are writing an issues document with already

Your assumption is incorrect.

I want to know because the OPsec meeting minutes seemed to suggest
that someone proposed this WG should recommend SHA mechanisms over
MD5 mechanisms, and I was not aware of any active work to implement
any SHA mechanisms.

>   Security Payload), or both are applied to the entire OSPFv3 payload

That does not say either that cryptographic authentication is a panacea
or that cryptographic authentication is perfect.  So the quote does not
support your original claim (from the top of Section 5 of my note).

The text you quote above simply says that it provides "the same level of
security" ... "by using the same cryptographic authentication".   The
text you quote from that I-D does not even claim that the existing
cryptographic authentication is a sufficient level of security.  Its
claims are really quite narrow and quite mild.

> clearly.

I quoted the base OSPF RFC to this list earlier today, where that RFC
indicated that the cryptographic authentication was focused on
"passive attack" prevention and showed that that RFC did not claim the
cryptographic authentication to be perfect or to be a panacea.  So the
OSPF RFC does not support your quoted claim either.

> Because most RFC's draft seem to state something similar to
> the above.

The actual IGP authentication RFCs and I-Ds (which I did cite)
do not do so.  They are what users and implementers read when
studying IGP authentication.

Further, the "examples" you have cited so far do not support your claim
at the top of this section (Section 5 of my email).

Thank you for the speedy reply.

Yours,

Ran Atkinson
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 21:37:07 -0500

On  16 Dec 2008, at 20:59, Vishwas Manral wrote:
> discussion...

(Having now scanned the above thread.)

One possible fix would be to deploy AH instead of ESP with NULL
encryption.  Many firewalls already know how to parse past the AH
option and look into the payload.  Since AH cannot ever encrypt data,
all middleboxes always know that the packet hasn't been encrypted
by AH.  AH actually provides stronger protections than ESP NULL,
as it covers many of the header and IP option fields (which ESP
NULL does not do).

AH is widely available in shipping router releases today,
so using AH is not hard for many router platforms.  Most desktop
OSs also support AH today, so again it is widely available
now and ready for use.

In any event, most firewalls today simply drop all IPsec ESP packets.

If the ESP packet is tunnel-mode, then the receive-side IPsec
implementation is required by the IPsec RFCs to perform various
sanity checks before accepting the packet (and potentially forwarding
the packet), which checks (properly implemented) should prevent
address forgery attacks.

If the packet is using transport-mode, then again the IPsec
receive-side processing requires various sanity checks that
should prevent address forgery attacks.

So it seems that if one encounters a buggy IPsec implementation,
then one might have buggy results, but that if one does not encounter
a buggy IPsec implementation, then there ought not be any issues
with forged IGP packets making it inside the administrative domain
via IPsec ESP.  Of course, with any protocol, if one encounters
a buggy implementation, results are not likely to be as desired.

Cheers,

Ran
[email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 16 Dec 2008 18:46:13 -0800

Hi Ran,

Thanks that clarifies the first draft atleast in my mind. :)

The second draft is about defining the set of algorithms for IGP just
like RFC4835 does for IPsec. This is to provide minimal set of
cryptographic algorithms to be supported for basic interoperability.

With the additional support of new crypto algorithms into IGP's there
are now multiple crypto algorithms defined for the same IGP. Also as
we move forward and security vulnerabilities are found in
cryptographic algorithms, the algorithm support for Routing Protocols
can be changed without change of the base protocol RFC's.

The issue was seen in IPsec case where we had to move from DES to
3-DES to AES-CCM. Based on the reccomendations of the IETF on various
crypto algorithms, we have recommended cryptographic algorithms as
MUST- to SHOULD +  etc to also give a sense of direction.

Thanks,
Vishwas

On Tue, Dec 16, 2008 at 6:19 PM, R Atkinson <[email-masked]> wrote:
> I do not have such any private emails; they must have been lost in transit.
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 16 Dec 2008 18:51:59 -0800

Hi Ran,

This is a good point. I brought differences between ESP and AH up in
2005 (check the link below) when the ESP and AH were still not the new
RFC's. Note IPsec RFC4301 states AH as a MAY support while ESP is a
MUST support.

http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html

The idea is that we are trying to move away from AH and ESP support to
only ESP support as most of the functionality of AH is sort of already
there in ESP, except for the points I mention. I understand it is a
noble cause too. Also note that AH is a MAY support for OSPFv3 while
ESP is a MUST (just like it is for IPsec).

I think the final aim for us needs to be to support one protocol and
try to get all the functionality from the same. This is the reason we
are trying to make changes to ESP rather than using AH.

This discussion however would be better part of the IPsec mailing list
then here in my view.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 10:21:31 -0500

On  16 Dec 2008, at 21:51, Vishwas Manral wrote:
> there in ESP, except for the points I mention.

Hmm. AH provides more comprehensive protections than ESP,
in a fundamental way.

> Also note that AH is a MAY support for OSPFv3 while

Most routers already ship with AH, so it is trivial to use AH.

> are trying to make changes to ESP rather than using AH.

At least some customers have a hard requirement for AH,
rather than ESP.  It is possible that not all implementers
care about those customers.

> This discussion however would be better part of the IPsec mailing list

You seem to have missed the main point of my note,
which was an Operational Security matter, so I will restate:

    There is no ESP attack vector that enables an interior
    node to inject forged IGP packets into a different
    target domain to subvert the target's IGP routing,
    provided the user has configured their systems
    appropriately (e.g. packet filtering at the edges),
    modulo bugs in their deployed implementations.

    In the case of implementation bugs, all bets are off
    anyway, no matter how one configures one's systems
    or designs one's network.

The detailed analysis of why this is NOT actually a problem,
even if ESP is in use, was provided in my previous note.

Cheers,

Ran
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 11:08:24 -0500

> cryptographic algorithms to be supported for basic interoperability.

There isn't an actual problem here to be solved.

You have reported 2 in-progress implementations of HMAC-SHA
for IGP authentication, with 2 being a lot smaller than the
set of router families in the world.

By contrast, support for Keyed-MD5/HMAC-MD5 is either
very widespread or universal.

> can be changed without change of the base protocol RFC's.

The existing specs would not need to be changed -- whether or not
such a document existed.  Your assumption that they would
need to be changed is not correct.  This is a "Red Herring".

> 3-DES to AES-CCM.

IGP authentication is not IPsec; they don't have the same
issues.

And this is not the OSPF WG or the IS-IS WG, which would be
the WGs chartered to make such implementation recommendations
for their respective IGPs.

> Based on the reccomendations of the IETF on various
> crypto algorithms,

The IETF has no IETF-wide policy on cryptographic algorithms.
According to IETF practice, such decisions are up to each
individual WG.

> we have recommended cryptographic algorithms as

I've cited here several specific scientific papers noting that
SHA is just as vulnerable as MD5, which you then agreed
was correct.  (URLs provided in email from me yesterday)

NIST has noted publicly that "serious attacks" have been
published against SHA. (URLs were provided yesterday
to the NIST web site to support this statement.)

I noted earlier that neither Keyed-Hash nor HMAC-Hash
have known vulnerabilities, which you also agreed
was correct. (OPsec list archives)

So one can see that it does not make scientific sense
for this WG to recommend anything beyond "some form of
cryptographic protection" -- because there is no scientific
reason to believe that either approach is better or
stronger than the other.

Recommending SHA as a "future direction" is particularly
silly -- because NIST is in the process of deprecating
and replacing the entire current SHA algorithm family
due to concerns about its strength.  (See the NIST URLs
I provided to the WG yesterday)

(By the way, the NIST announcement that it would replace
SHA was made in 2007.  The closing date for proposals to
NIST for a new algorithm was October 31st 2008.  The new
hash algorithm will have different maths, although it might
[confusingly, IMHO] be called SHA-3.)

If some WG were going to suggest a "future direction"
for IGP cryptographic authentication, then an entirely
different approach (e.g. some form of AES CBC MAC,
such as Rogaway has published) is likely the sensible
scientific approach to take, given what is known now.

So far as I am aware there is no work in progress on
specifying such a thing for any IGP.  (Maybe that is
an opportunity for someone.)

There might be individual users who choose to undergo the
pain of migration later from existing approaches (e.g. MD5)
to something else (SHA or whatever) for local policy reasons,
but that local policy choice is not an IETF matter,
and that direction isn't supported by science available
to this WG right now.

Yours,

Ran
[email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Dec 2008 08:14:23 -0800

Hi Ran,

> Hmm. AH provides more comprehensive protections than ESP,
Are you stating something other than what is in the link I provided.

> Most routers already ship with AH, so it is trivial to use AH.
Yes, but the aim is to move away from AH. AH has been downgraded to a
MAY support in IPsec RFC4301. It is the same for the OSPFv3 RFC too.

> care about those customers.
Ok.

> which was an Operational Security matter, so I will restate:
Thanks for restating it. I am sorry if I missed the point.

>   modulo bugs in their deployed implementations.
Ran, the point we were talking is about the packet actually not being
able to be filtered by the edge node/ device because the packet is
encapsulated in the ESP header. Is there something amiss here - when
you say such a packet can be filtered?

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 11:21:00 -0500

> you say such a packet can be filtered?

Please go re-read my note to OPsec from yesterday
for the full analysis.

Cheers,

Ran

---

From: "Glen Kent" <[email-masked]>
Date: Thu, 18 Dec 2008 06:44:22 +0530

>> Is it discussed at the same level of detail as other mechanisms ?

Please stop harping about 2154. Its experimental and you may want to
read the Tao of IETF to understand what that means.

> the claim more precisely.

I think the context here was IPSec since ESP packets cannot be filtered.

>> If so, which users ? which RFPs ?

Providers may not be open in accepting this for various policy,
political reasons.

> Are they shipping now or in progress now ?

Vendors may not be always willing to share this information.

Glen

---

From: "Glen Kent" <[email-masked]>
Date: Thu, 18 Dec 2008 06:46:17 +0530

> same however (though I would feel it may not exactly fit the draft).

You dont need to - its not required.

The draft is about the issues existing in the well known and widely
used flavors of authentication as used in the current IGPs.

Glen

---

From: "Glen Kent" <[email-masked]>
Date: Thu, 18 Dec 2008 06:47:53 +0530

> available that implementation might be.

Is there anyone in this list who is aware of 2154 being deployed. Is
there any interest in this WG to include 2154? If none, then this can
be safely ignored.

Glen

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 20:58:18 -0500

On  17 Dec 2008, at 20:17, Glen Kent wrote:
> Is there anyone in this list who is aware of 2154 being deployed.

Yes, within the US Government.

> Is there any interest in this WG to include 2154?

Yes.

Good questions.

Yours,

Ran Atkinson
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 20:59:55 -0500

> You dont need to - its not required.

You are formally declaring WG consensus ?
Curious.

Or were you expressing your opinion ?

> used flavors of authentication as used in the current IGPs.

If the draft is a WG document, then the WG as a whole
needs to decide that question -- while following IETF
processes.

Yours,

Ran Atkinson
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 21:02:54 -0500

> I think the context here was IPSec since ESP packets cannot be  

My note yesterday tried to explain why if IPsec is
implemented according to the RFCs, then there isn't
actually an IGP vulnerability to forged IGP packets
from outside the routing domain due to IPsec ESP.

If you think my analysis posted yesterday was incorrect,
which is always possible, kindly educate me. :-)

Cheers,

Ran
[email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Dec 2008 19:19:26 -0800

Hi Ran,

As you have sent so many mails with so much text would it be possible
for you to point out which mail I should read.

I am unable to understand how you can say ESP packets can be filtered
at the edge based on the content. That is a problem IPsecme is trying
to solve.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Dec 2008 19:34:36 -0800

Hi Ran,

> There isn't an actual problem here to be solved.
There are multiple crypto algorithms that have been defined, there is
a need to define a minimal set to support to achieve minimal
interoperability. As all IGP's and possibly other protocols like BGP
have similar requirements from their cryptographic algorithms, we have
made a generic document which can talk about the crypto requirements
of all routing protocols.

If you do not see the need for it, please do not claim there is no
problem. Please state you are unable to see the problem.

> very widespread or universal.
Can you let me know any OSPF implementation which support HMAC-MD5 please?

> need to be changed is not correct.  This is a "Red Herring".
You did not understand what I meant, but let me restate. If there are
multiple algorithms to support interoperability if some algorithms are
made a MUST/ SHOULD support in the protocol itself it may require
changes. We have worked and fixed the same issue in IPsec. We do not
want to go through and have the same issues again before we change
things in IGP's.

I cannot take an argument of waiting to see things fail before taking
action, which is exactly what you seem to suggest in all your mails.
We have had the issue in IPsec nad have solved it, we are learning
from that and improving things in other places too.

> for their respective IGPs.
Yes, this has been discussed with the Routing AD's and the chair of
the OSPF WG (and probably the IS-IS WG too). If you have issues about
the location please raise it in the right forum.

> According to IETF practice, such decisions are up to each
Yes and the Routing AD's have based on the current state decided to
bring the work to OPSEC.

> was correct.  (URLs provided in email from me yesterday)
As I have said I prefer focussed mails. I have said atleast 4 times
now that if you have issues with defining SHA algorithm for protocols
please raise it in the right forum. I have told you multiple times
which forum the discussion is relevent for.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Wed, 17 Dec 2008 23:33:46 -0500

> Can you let me know any OSPF implementation which support HMAC-MD5  

Which part of "Keyed-MD5/HMAC-MD5" was confusing ?

> You did not understand what I meant, but let me restate.

I understand what you are saying.
You believe there is a problem.

After considering your explanations,
I disagree that there is an actual problem here.

> which forum the discussion is relevent for.

Somehow I must not have been clear, despite repeated
attempts; I'm terribly sorry.

**The issue is NOT -- and NEVER has been -- whether any
particular algorithm (e.g. SHA) is defined for use with
any particular IGP.**

(Please drop that mis-conception.)

BACKGROUND:
- There is agreement, including from you yesterday to the OPsec
   list, that there are now serious concerns with the SHA algorithm.
   [1][2]

- There is agreement, including from you yesterday to the OPsec
   list, that there are serious concerns with the MD5 algorithm.
   [Dobbertin1996]

- There is agreement, including from you yesterday to the OPsec
   list, that there are no known attacks on any of the IGP
   cryptographic authentication approaches (Keyed-Hash or HMAC-Hash).

- NIST announced "serious attacks" on SHA in November 2007.[2]
   NIST has also announced that they are working actively
   to develop replacements for the current SHA algorithms
   because of those attacks.

KEY POINT:
The WG has no scientific basis right now to recommend SHA
as a future direction over MD5.  Note also that the WG doesn't
have a scientific basis to suggest that the MD5 approaches
are cryptographically better than the SHA approaches.
Right now, the published peer-reviewed literature indicates
that *both* SHA and MD5 have serious issues with their
compression functions.

SECONDARY POINT:
Some other cryptographic hash algorithm might be a better
choice than either SHA and MD5.  For example, Phil Rogaway
has published papers on an AES-based CBC MAC algorithm.
[http://www.cs.ucdavis.edu/~rogaway/papers/xcbc.pdf]

(CAVEAT:  I don't know if that particular algorithm
is a good choice or not.  It is simply an *example*
of an algorithm that is different than either MD5 or SHA.
One imagines that a range of alternative algorithms exist.
I think Rogaway's algorithm is the basis for RFC-3566.)

OTHER:
The facts available to us now are *different* than the facts
of several years ago.  We know things now that we could not
have known BEFORE the widespread publication of attacks on SHA
AND could not have known BEFORE NIST's public statement last
November that NIST is working actively to develop a replacement
for the current SHA algorithm.

If someone can find a peer-reviewed publication performing
a scientific analysis comparing the SHA and MD5 algorithms
**with the cryptographic modes used in IGP authentication**,
then the WG might have a scientific basis to recommend one
or more approaches over other approaches.  Either a full
bibliographic citation or a URL to such a peer-reviewed paper
would be most helpful, because the WG could then read that paper,
and (if appropriate) cite that paper as the basis for
whatever WG recommendation(s) might arise from that paper.

Right now, there simply isn't enough scientific data to
recommend any one approach over another -- among the
set of extant IGP cryptographic authentication approaches.

Any recommendation(s) made by an IETF WG should be made
on a scientific basis, IMHO.

Yours,

Ran
[email-masked]

URLs repeated from yesterday for convenience:
[1] <http://scholar.google.com/scholar?q=SHA+attack&hl=en&lr=&btnG=Search 
[2] <http://csrc.nist.gov/groups/ST/hash/index.html>
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Glen Kent" <[email-masked]>
Date: Thu, 18 Dec 2008 21:27:03 +0530

> You are formally declaring WG consensus ?

No, merely my opinion.

Glen.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 18 Dec 2008 11:51:55 -0800

> Hi Ran,
> 
> As you have sent so many mails with so much text would it be 
> possible for you to point out which mail I should read.
> 
> I am unable to understand how you can say ESP packets can be 
> filtered at the edge based on the content. That is a problem 
> IPsecme is trying to solve.
> 

Vishwas,

I think you can in theory filter all packets at the edge based on their
destination.  Why would you allow anyone to send ESP packets to your
infrastructure addresses?

I believe this is the point Ran is trying to make.  Infrastructure
hiding/filtering is orthogonal to encryption between infrastructure
routers.

-Darrel