Subject: Re: [OPSEC] minutes part 2

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 11:04:31 -0500

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

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.

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.

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

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.

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.

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

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

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.

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

% 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
[email-masked]

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 16 Dec 2008 09:27:19 -0800

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

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

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

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

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

> is why they are sensible to protect against.
Agree partially. It is a goal but not the only goal of cryptographic mechanisms.

> actually makes sense for their operational environments.
Comments given above.

> of a digital signature approach.
IPsec with Manual Keying still states there can be no Replay protection.

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

> know of any that are even "in progress".)
We know of a few including a big router vendor. :))

> collision attacks on SHA.
Agree.

> <http://csrc.nist.gov/news_events/news_archive/news_archive_2007.html#nov20>
>
The urge is to get into HMAC-SHA1 not SHA1.

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

Thanks,
Vishwas

> in this might want to put together a "requirements" draft as a first step.
>
> % modifying it but to track the minimum requirements for interoperability
>

---

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 13:40:05 -0500

(NB: All of my references to "SHA" include "SHA1 and "SHA2" also.)

On  16 Dec 2008, at 12:27, Vishwas Manral wrote:
> of the contents inside the ESP packet).

Your claim above is not obvious.
Please explain when/why you believe the claim above is true.

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

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

> "First, let me observe that IGP attacks are all insider attacks."

Not at all.  This looks like an English language issue to me:

- All IGP attacks would have to be insider attacks,
   because external packets are normally filtered anyway.
- 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.

> in all Security groups even though attacks themselves have not occured

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.

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

> Agree partially. It is a goal but not the only goal of cryptographic  

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

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

>> actually makes sense for their operational environments.

None of which comments above address the text which you have quoted.

> IPsec with Manual Keying still states there can be no Replay  

RFC-2154 does not use IPsec.  So a comment about IPsec
is orthogonal to the discussion.  Please go read RFC-2154.

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

>> SHA authentication for any IETF-specified IGP.
>> (I don't know of any that are even "in progress".)

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.

>> collision attacks on SHA.

Given that you agree the concerns are the same,
then why does your draft push SHA over MD5 ?

> 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. :-]

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.

Yours,

Ran
[email-masked]

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

---

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 13:40:05 -0500

Yours,

Ran
[email-masked]

---

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

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.

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

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

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

> Not at all.  This looks like an English language issue to me:
May be I misunderstood what you stated.

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

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

> can choose to use -- and there seem to be no reports of any IGP attack
Please note my basic comment mentioned above.

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

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

> implementations have already shipped and which might be
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.

> If some new discovery has happened, I'm personally quite keen
I agree so am I and the rest of the world.

>  be to draft an "IGP KM Requirements" document for the other WGs
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

---

From: R Atkinson <[email-masked]>
Date: Tue, 16 Dec 2008 18:40:10 -0500

On  16 Dec 2008, at 14:18, Vishwas Manral wrote:
>  Let me again state that
> 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

I can't parse the above, terribly sorry.

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

> issues that might occur with the security mechanisms themselves into

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.

> No it isnt.

Generally, they have been, for example in the references above.

> Can you please map the RFC2328 security section with the

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.

> is an old discussion please go through the IPsec archives and you will

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.

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

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

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

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

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

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

> 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
[email-masked]

---

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

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

> 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

---

From: "Glen Kent" <[email-masked]>
Date: Wed, 17 Dec 2008 05:50:33 +0530

I don't understand your concern. When I read the
draft-ietf-opsec-routing-protocols-crypto-issues  for the first time
what it told me was that Yes, using cryptographic authentication is
all fine but there can still be some attacks despite using such
schemes. What you're saying is that the attackers need not go that far
and that there are simpler ways to launch DoS attacks against the
routers. Agreed, so what? This doesn't make the existing issues with
crypto protection any less criminal? This also doesn't preclude the
need to document the issues that can exist with the current
authentication mechanisms. I could have understood your dissent if a
WG were proposing solutions to the problems cited in the issues draft
on the grounds that those are not needed, however, a draft such as
this needs to be present so that the community knows that
cryptographic protection as offered by IGPs is not a panacea to all
security problems - ISSUES still exist!

OPSEC must only document such issues. Its up to the other WGs to
decide whether they want to act on it or not.

Glen

---

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

On  16 Dec 2008, at 19:20, Glen Kent wrote:
> I don't understand your concern.

I have no concern with the WG documenting any issues, provided:
- they really are technical issues rather than opinion,
- the analysis really is comprehensive, including a threat model,
- the analysis also discusses existing mitigations,
and
- the analysis covers all such authentication mechanism,
   including for example RFC-2154, not just some of them.

(For an individual submission rather than a WG document, of course,
none of the above caveats would apply, as individuals can say
whatever they wish, true or not, in a personal informational RFC. :-)

As my notes have tried (and perhaps failed, sigh) to make
clear, the focus of my concerns are:

1) An apparent proposal, according to the WG minutes, to have
    the OPsec WG recommend that users migrate to using SHA-based
    mechanisms.  There are not solid technical grounds to
    recommend/prefer SHA approaches over MD5 approaches
    (or the reverse: it isn't obvious that MD5 is better either).

2) Erroneous claims in the meeting minutes that SHA-based approaches
    are better than the existing MD5-based mechanisms.  The approaches
    are very slightly different, but as the URLs I provided much earlier
    today make clear, SHA has issues in the published literature just
    as MD5 does, AND NIST is actively moving to deprecate SHA/SHA-1/ 
SHA-2.

Yours,

Ran
[email-masked]

---

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

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

Actually, as the Subject line and my quotes from my very first note
made clear, all of my notes have solely been responses to the
*OPsec meeting minutes*.

I object to the assertions in those minutes that:
	- the SHA approaches are better/stronger than MD5 approaches.
           [We have agreed that the evidence does NOT support such a
           claim -- which claim appears to be in the meeting minutes.]

	- the WG should recommend/encourage/promote SHA approaches
           over MD5 approaches. [which claim again appears to be
           in the meeting minutes]

> better than the other for the IGP cases.

I can't parse that, so I don't know what you mean.
Please re-phrase.

> Please raise the issues in the correct forum.

I have been all along.  Please discontinue incorrect assertions
that this is not an appropriate forum for discussing items in
the OPsec WG meeting minutes.  All day I've been raising operational
security issues within the OPsec WG.

> sorry I am not as well versed in English. :))

Fair.  Each of us do our best.  :-)
I am a polyglot [RFC-2130], but I also don't know any
south Asian languages, terribly sorry.

---

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

This does not address the point that i had raised.

> - they really are technical issues rather than opinion,

So, you dont think the issues mentioned in the drafts are technical?
OK, how would you categorize those issues?

>  including for example RFC-2154, not just some of them.

Its experimental. Lets leave it out of the discussion.

>   the OPsec WG recommend that users migrate to using SHA-based

Can you stop being vague and mention the precise proposal you are
arguing against?

>   (or the reverse: it isn't obvious that MD5 is better either).

So, you dont think there is any value in moving over to SHA based
mechanisms, is it?

>   today make clear, SHA has issues in the published literature just

You probably did not notice, but IESG has added a note, in the very
RFC (4822) where YOU have added support for SHA for RIP

"In the interests of encouraging rapid migration away from Keyed-MD5
and its known weakness, the IESG has approved this document even
though it does not meet the guidelines in BCP 107 (RFC 4107)."

Glen

---

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

>          over MD5 approaches. [which claim again appears to be

So you're asserting that Md5 is as strong as SHA. Can you please confirm this?

Glen

---

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

> So you're asserting that Md5 is as strong as SHA. Can you please  

No.  I'm asserting that:

   At present, there is no data indicating that MD5
   (as used for IGP authentication) is either stronger
   or weaker than SHA (as used for IGP authentication).

There was a time (now past) where there were published
concerns about the compression function of MD5
[Dobbertin1996] but there were not equivalent concerns
about SHA.  I cited specific published papers that now
indicate strong concerns with the compression function
of SHA.  I also cited a NIST formal statement indicating
that there were "serious attacks" on the compression
function of SHA.  (In both cases, I provided specific
URLs yesterday in email to the OPsec list.)

Yours,

Ran Atkinson
[email-masked]

---

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

Hi Ran/ Glen,

Let me get back on this to you on this one.

Thanks,
Vishwas

---

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

> OK, how would you categorize those issues?

Let me repeat:
	My comments here have been focused on the
	comments reported *meeting minutes*.

I have made no assertions about any drafts.

> Its experimental. Lets leave it out of the discussion.

It is real and it is (IMHO) a whole lot better than anything
else we have -- and I understand at least one implementation
exists.  So we should include it in the discussion.

> Can you stop being vague and mention the precise proposal you are

Kindly see the meeting minutes, which is what ALL of my comments
have been reacting to.

> So, you dont think there is any value in moving over to SHA based

At present, there is no known scientific data indicating
that SHA-based approaches are either stronger or weaker
than MD5-based approaches **as used in the current
IGP authentication specifications**.

If you know of a published paper that explains that either
one is stronger **as used for IGP authentication**, for
example when used in the same cryptographic modes as for
IGP authentication, then please share the document (or
a URL/formal citation to it) so everyone can read it.

> though it does not meet the guidelines in BCP 107 (RFC 4107)."

I'm aware of that.  Look at the date on RFC-4822:
	February 2007

AFTER that IESG statement, in *November 2007*, NIST posted its
formal notice (URL provided previously) that SHA now has
"serious attacks" and that NIST was soliciting a replacement
algorithm -- so that NIST can replace/deprecate the current
SHA algorithm.

BOTTOM LINE:

The prior confidence in SHA's compression function doesn't
exist NOW due to publication of papers describing "serious
attacks" (quote from NIST) on SHA's compression function.

Yours,

Ran
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 18 Dec 2008 10:10:17 +0530

Hi Ran,

I was away and could not respond earlier.

> on customer-facing interfaces or other exterior interfaces.

You btw cannot do this if IPSec is deployed. Look at the discussions in IPSECME for more details.

> attack (e.g. DoS on the router CPU) exists.

Would you like to elaborate on what constitutes a simpler/easier attack? Most of the vendors now provide protection against the simple/easy attacks that you are probably alluding to.

> seen over the past ~20 years).

I agree. However, you might understand that operators may not go out of their way to make this public.

Irrespective of the above, the OPSEC WG doc draft-ietf-opsec-routing-protocols-crypto-issues-00 makes no such claims. It just lists down the possible holes that exist despite using cryptographic authentication mechanisms in the IGPs.

This is not the first time such a discussion (spoofing in routing) has been brought about. It has been discussed several times in the RPSEC WG, individual routing WGs, KMART BOF, etc. and its for the first time that I am hearing somebody assert that security is not an issue in routing protocols.

> is why they are sensible to protect against.

Again, would you mind expounding on this?

> are not really widely deployed operationally.  Many enterprise

Really? We have several customers who use cryptographic authentication mechanisms. If you doubt this you could post a survey on nanog.

> of a digital signature approach.

I have not yet read the entire thread but you seem to offer 2154 as a panacea to all security issues, which imo is without any basis and foundation.

A quick glance through 2154 reveals some issues and I am sure there are a LOT of other issues that could be present. Mutable fields are not covered by the digital signatures and can thus be exploited. 2154 mandates globally synchornized clocks between all trusted entities, something that is definitely not easy to achive given that clock synchronization could itself be exploited.

Then you must also appreciate that there hasn't been any effort employed to study weakness in 2154 as this isnt deployed. So, lets leave this out of draft-ietf-opsec-routing-protocols-crypto-issues-00.

> significantly increase a router's vulnerability to DOS attacks,

I think this is a very irresponsible statement to make since your comments seem to be based on specific router implementations. A good implementation can do this without exposing the CPU for DOS attacks.

> know of any that are even "in progress".)

I know of atleast two vendors who are working on this. Contact me offline if you want me to connect you to the people in charge of this work.

>   domain is not a silly approach.

Nobody is contesting this. However, this has some obvious issues, and we should see if we can solve this.

>   security of anything.  It can make it slightly simpler

You probably misunderstood the advantages incurred by using a Key ID. 

>   received packet, however the most widely deployed

I repeat, you are again, referring to the implementation that you are aware of. I would urge you not to make such sweeping statements about routing implementations.

>   try all configured and valid SAs on the router.

See above. BTW, one gain of a Key ID is to avoid the very behavior that you have described above.

> See comment up top with reference to RFC-2154.

See comment on top.

> some form of risk reduction.

We don't even recommend adding sequence number to IS-IS. However, it is just brought to the reader's notice.

If there was any intent of doing so then we would have added this in draft-ietf-isis-hmac-sha-07.txt

> If MD5 authentication is enabled, packets can't be forged.

Yes, but that doesn't preclude the possibility of an attack. I remember sending you an email about this some time back.

Please read section 6 of draft-ietf-opsec-routing-protocols-crypto-issues-00.txt

> for their operational domain.

Again, a very wrong assertion.

> here as that would be significant news.

I agree. However, this doesn't mean that we should not highlight the issues that exist in the current crypto protection mechanisms. 

Please look at RFC 4593. Do you think all the threats mentioned there have actually been seen in the wild?

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 18 Dec 2008 18:30:53 +0530

Hi Ran,
 
> Please explain when/why you believe the claim above is true.

It is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them because of the way ESP is defined. This poses problems for the firewalls since such packets (OSPFv3) cannot be filtered and identified. 

You could read either of the drafts for more details:

draft-ietf-ipsecme-traffic-visibility
draft-bhatia-ipsecme-esp-null-00.txt
 
> >> seen over the past ~20 years).

If the intention is to only provide protection against passive attacks then you don't need cryptographic authentication - You can very well do with clear text passwords.

> > in all Security groups even though attacks themselves have 

I agree. You don't need to wait for attacks to happen before you start exploring other options.

> can choose to use -- and there seem to be no reports of any IGP attack

Then you don't need cryptographic authentication for IGPs. Cleartext should be good enough.

> > Agree partially. It is a goal but not the only goal of 
> cryptographic  
> > mechanisms.
> 

I find it strange that you find computing SHA computationally expensive (you stated this multiple times here on this list), while having no qualms on the overhead incurred when computing full digital signatures. Public Key Cryptography is *very* expensive and it drastically slows down the performance of the router. Then you have this problem of key distribution and somehow certifying the public key, etc.  

> limitations are widely understood in the community.  For example,

.. which is why we're documenting them in draft-ietf-opsec-routing-protocols-crypto-issues-00.txt.

> quite clear in my comments during that BOF that the current mechanisms

Then why do you mind listing them out?

> any other current mechanisms.  (This is all a rehash of comments

.. at an additional cost that you seem to conveniently forget. Also note from my previous email on the list that there are still some holes in the digital signature scheme.

> developed; for OSPF, RFC-2154 already exists.

See my previous points.

Lets not talk about 2154 and concentrate on the two drafts in question:

draft-ietf-opsec-routing-protocols-crypto-issues-00.txt 
draft-bhatia-manral-igp-crypto-requirements-03.txt 

I know you are responding to the minutes posted on the list. However, since those are related to these drafts, I would urge you to read the above drafts and then comment specifically on the drafts. This imo would be more productive for the WG.

> is orthogonal to the discussion.  Please go read RFC-2154.

[ .. ]

> impacted (because SHA1 is more computationally expensive

As I have already mentioned in my earlier mail, this assertion is without any foundation and is perhaps based on router implementations that you are aware of.

[ .. ]

> DOS attack on IGP packets if any form of SHA is used.[2]

Same as above.

Cheers, Manav

---

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

> exists.  So we should include it in the discussion.

Is there any deployment of the same? Is the WG interested in this?

Glen

---

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

> It is impossible for firewalls and intermediate routers to 
> differentiate between encrypted ESP and ESP NULL packets by 
> simply examining them because of the way ESP is defined. This 
> poses problems for the firewalls since such packets (OSPFv3) 
> cannot be filtered and identified. 
> 

If this discussion is specific to ISPs needing to prevent customers from
attacking their IGP, then you are (I think) mistaken in specifying the
need for PE routers who implement infrastructure access control to
examine the data inside the packets.  There is no reason (aside from
lack of filtering features/performance on the PE) that a service
provider should let customer originated ESP packets be forwarded toward
its infrastructure.

If this is a more general discussion about network filtering of
ospfv3/ESP packets and intra-enterprise firewalling, then yes, I guess
it could be problematic.

-Darrel

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 19 Dec 2008 04:42:36 +0530

Hi Darrel,

> ospfv3/ESP packets and intra-enterprise firewalling, then yes, I guess

Yes, it is this case. Firewalling OSPFv3 is a pain with ESP.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 19 Dec 2008 09:33:55 +0530

Hi Glen,

There was an implementation of RFC 2154 based on Gated but there are no known deployments of the same. I had a brief exchange with Sandy (SIDR chair and author of this RFC) and she too isn't aware of any deployments. 

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Glen Kent
> Sent: Thursday, December 18, 2008 9.32 PM
> To: R Atkinson
> Cc: [email-masked]
> Subject: Re: [OPSEC] minutes part 2
>

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 20 Dec 2008 11:34:14 -0800

>           over MD5 approaches. [which claim again appears to be

Just as a point of order, I looked at the minutes and audio and I think
their existence in the dialogue as stated in the minutes is accurate, if
not work for word.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Dec 2008 15:41:47 -0500

On  18 Dec 2008, at 23:03, Bhatia, Manav (Manav) wrote:
> There was an implementation of RFC 2154 based on Gated but there are  
> no known deployments of the same. I had a brief exchange with Sandy  
> (SIDR chair and author of this RFC) and she too isn't aware of any  
> deployments.
>
> Cheers, Manav

I am aware of deployment of RFC-2154 within the USG,
as noted before on this list.

Foundry Networks' online data sheet also claims
that they implement RFC-2154.  (I have not tried
to check all vendors' data sheets.)

Ran

<http://www.foundrynet.com/products/enterprise/adv-conv-edge/fi-edge-xe.html

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Dec 2008 15:49:08 -0500

> their existence in the dialogue as stated in the minutes is  

Joel,

I have never doubted that the minutes were accurate.
My disagreement is with parts of someone's comments
that were made during the meeting.

My apologies if I have not been clear on this (or
other matters).

Yours,

Ran

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 22 Dec 2008 21:13:18 -0800

Hi Joel/ Ran,

> their existence in the dialogue as stated in the minutes is accurate, if
I find the following link for the approved algorithms for secure hashing:
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html , they
include SHS algorithms but not MD5 ones. Though there is a line which
states that:

"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs).
Regardless of use, NIST encourages application and protocol designers
to use the SHA-2 family of hash functions for all new applications and
protocols."

MD5 is not amoung the approved algorithms for the same.

Ran, I would like to hear your views on the same.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Tue, 23 Dec 2008 10:44:36 -0500

Folks,

Of course, NIST's approved algorithms list only contains
NIST algorithms  This ought not be surprising.

Of course, non-NIST algorithms aren't on NIST's lists.
That is a tautology.

There is no news here.

It is all entirely consistent with my prior statements.  There
are some organisations that *for policy reasons* prefer to use
certain algorithms or algorithm families.

A choice made to comply with (local or national) organisational
policy is quite different from a claim that scientific
evidence exists that one algorithm is better than some
other algorithm (when evaluated in the context of a
particular cryptographic mode -- comparing apples to apples).

As the IETF is an international, global organisation,
the IETF has so far declined to use *local or national
policy* as the basis to endorse or reject any particular
algorithm.  This seems only proper as the IETF ought not
prefer US policy over another country's policy in its
decision making.  This principle of using global scope for
the IETF standards processes lies behind [RFC-1984].

Given the relatively recent information indicating "serious
attacks" on SHA (the quote is from NIST [1]), including an
acknowledged attack on SHA-1 [2], previous beliefs that SHA
might be stronger are no longer supported by the science at hand.
MD5 is also subject to "serious attacks" that have been published.
So the data available says that both SHA and MD5 have cause
for serious concern.

Now, maybe someone has recently published some scientific,
peer-reviewed, paper that compares MD5 and SHA (in the mode
used by the IGPs for authentication).  If such exists, a pointer
to that paper would be helpful to everyone in the OPsec WG.
Absent such a paper, the only *scientific* conclusion is that
(1) there is cause for concern about both SHA and MD5 and
(2) there is not enough data at the present time to prefer
either of those algorithms over the other algorithm.

A practical step might be for some folks (not including me !)
to add some additional MAC algorithms to the set available
for IGP authentication, to provide more choices to implementers.
Apparently specifications for an AES-CBC MAC and a "Counter
with CBC-MAC" have been created in recent years. [RFC-3566]
[RFC-3610]  (NOTE WELL:  I haven't done a literature search
on either of those, so I'm not recommending either one; instead,
I am only noting that the universe is not limited to SHA or MD5,
and providing some examples of other options by way of an
existence proof.)

Cheers,

Ran
[email-masked]

PS:  The set of "First Round Candidates" to replace
the existing SHA standards are listed at reference [3] below.

[1]<http://csrc.nist.gov/groups/ST/hash/index.html>
[2]<http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf 
[3]<http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html

---

From: "Glen Kent" <[email-masked]>
Date: Tue, 23 Dec 2008 22:48:27 +0530

> So the data available says that both SHA and MD5 have cause

OSPF WG charter (http://www.ietf.org/html.charters/ospf-charter.html)
says "Nov 2008	Develop stronger authentication mechanisms for OSPFv2
and submit to IESG as a Proposed Standard". It is against this charter
item that they're probably working on the
draft-ietf-ospf-hmac-sha-03.txt. You might want to let them know that
its not good enough, as SHA has same problems, if not any worse, than
MD5.

You also might want to look at
http://www.ietf.org/proceedings/07mar/slides/ospf-3/sld2.htm which
tells you why this particular draft was adopted as a WG doc.

And isnt it ironic that you are also the author of RIP for SHA support
(RFC 4822) and IS-IS extensions for SHA
(draft-ietf-isis-hmac-sha-07.txt)? If there is no need for these,
except for one customer that you tout, then you should have probably
called these RFCs and drafts as RIP-SHA for <customer name> and
ISIS-SHA for <customer name>. Why an RFC if they offer no benefit to
the community? I am surprised, really I am, as to why you have still
not drafted an OSPF SHA extension for your_favorite_customer?

Glen

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 23 Dec 2008 10:06:54 -0800

Hi Ran,

> Of course, non-NIST algorithms aren't on NIST's lists.
I am not trying to disseminate news here. The aim was to show that the
link which has been updated 2 months back states the uses of SHA-2,
etc is safe for hashing purposes.

I wanted to know if you thought that information was not correct.

Thanks,
Vishwas

> [2]<http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf>
> [3]<http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 23 Dec 2008 10:21:17 -0800

Hi Ran,

One more interesting thing I noticed was that we are reccomending
HMAC-SHA-1 over Keyed-MD5 for OSPF and RIP do you agree to this part?

Thanks,
Vishwas
=====================================================

   For OSPF implementations to interoperate, they must support one or
   more authentication algorithms in common that can be used in the
   cryptographic scheme of authentication.

   This section details the authentication algorithm requirements for
   standards conformant OSPF implementations.

   Old   Old         New
   Req.  RFC         Requirement  Authentication Algorithm
   ---   ------      -----------  ------------------------
   MUST  2328        MUST-        Keyed MD5
    -     -          SHOULD+      HMAC-SHA-1 [OSPF-HMAC]
    -     -          MAY+         HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 23 Dec 2008 11:22:03 -0800

> Is there any deployment of the same? Is the WG interested in this?

Just to be clear here... since the context disappeared some messages back...

RFC 2154 is what is being referred to here?

Do we have deployments or operational experience to draw on?

I note one of the original author's is a routine contributor to this list.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 23 Dec 2008 11:27:42 -0800

> that were made during the meeting.

Understood. I was just confirming that we we all clear that what was
said in the meeting was reflected in the minutes.

> My apologies if I have not been clear on this (or

none required

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Dec 2008 17:35:15 -0500

On  23 Dec 2008, at 12:43, Glen Kent wrote:
>> And isnt it ironic that you are also the author
>> of RIP for SHA support (RFC 4822) and IS-IS extensions for SHA
>> (draft-ietf-isis-hmac-sha-07.txt)?

No irony.
The specifications solve a policy problem for the US DoD.
I have said all along that policy was a legitimate reason
for one user to make a choice preferring one algorithm
or another.

I've also said that IETF ought to be making its decisions
on science, not based on local policy or national policy.

My position is completely consistent.

Maybe you've forgotten, but I used to work for the US DoD,
as is very widely known in the IETF (check Google or past RFCs
on that also).  Folks I used to work with asked me to put
together some drafts on IGP authentication to address their
policy issue.  I did so as a favour.  No surprises there.

As I'm not a mathematician, I took their advice and asked folks
at NIST for help with the math.  Matt Fanto was at NIST at the
time (Google should help with that also) and provided the maths.
One will further note that Matt acknowledged several NIST folks
in RFC-4822.

Now note that RFC-4822 was published several months *before*
NIST's announcement of "serious attacks" on SHA.  That document
was in the usual queuing at RFC-Editor for some time before
its publication.

>> If there is no need for these,
>> ISIS-SHA for <customer name>.

One could.  I'm pretty indifferent about names.

>> Why an RFC if they offer no benefit to
> Ho ho! I just googled and learnt that you have also written
> a draft on extending OSPF for SHA ! Now, isnt that surprising? :-)

I have had drafts for all 3 IGPs -- using the same mathematics --
for several years now.  It isn't a secret.  I've been saying
all along that one user's policy compliance desires has driven
the work in this area.

> Wonder why you wrote this draft when you know that SHA is no better
> than MD5.

(See at top: using SHA solves a policy problem for US DoD.)

Separately, I did not know the SHA attacks at the time.  In fact,
I'm well *behind the curve* as I did not learn about the SHA
attacks until fairly recently.

> Also any particular reason why this isnt the one adopted by
> the WG as the WG doc? Both the drafts look similar to me.

In Minneapolis, the OSPF WG decided to adopt the
same mathematics used for RIP and IS-IS for use with OSPF.
One might want to look at those slides also.

Cheers,

Ran
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Tue, 23 Dec 2008 17:45:31 -0500

> etc is safe for hashing purposes.

NIST's Policy on Hash Functions
<http://csrc.nist.gov/groups/ST/hash/policy.html>

This says precisely that:

"The SHA-2 family of hash functions may be used by Federal agencies
for all applications using secure hash algorithms."

This is a statement of policy, granting permission to Federal
agencies.  It does not say that they are "safe", just that they
"may be used by Federal agencies".

It then follows with another policy statement urging non-use
of SHA-1:

"Federal agencies should stop using SHA-1 for digital signatures,
digital time stamping, and other applications that require
collision resistance as soon as practical..."

Note that neither the NIST policy (URL above), nor the other
NIST statements (2 URLs next) say that SHA-2 is "safe".
In fact, the word "safe" doesn't appear at any of those URLs,
as near as my web browser can tell.

>> [2]<http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf 

These 2 URLs above say that SHA has "serious attacks" and also
that NIST is actively working to replace the current SHA algorithms.

Earlier today, I provided a URL to NIST's list of candidates
to replace SHA, which shows that work to be well underway.

So far, the NIST documents you are citing support my statements.
There are several URLs above.  I'd encourage list members
to go read them for themselves. :-)

Cheers,

Ran

---

From: R Atkinson <[email-masked]>
Date: Tue, 23 Dec 2008 17:48:24 -0500

> HMAC-SHA-1 over Keyed-MD5 for OSPF and RIP do you agree to this part?

I don't think the current knowledge to hand supports the
policy in the text you've quoted above.

In the past, BEFORE the understanding that SHA has "serious
attacks", then encouraging the use of SHA might have been
widely deemed reasonable, but given the current data
I don't see how one can draw that same conclusion now.

Cheers,

Ran
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Tue, 23 Dec 2008 17:54:00 -0500

Joel,

I am told there is limited use of RFC-2154 within US DoD.

I gather (from the URL provided earlier) that at least one
commercial router vendor supports it.

Note that I have not and do not propose that this WG recommend
RFC-2154 for general use at this time.  It would be unusual
to recommend an experimental status RFC for widespread use.
I suspect many folks would agree with that.

I have proposed, and continue to believe, that a document talking
about issues with IGP authentication mechanisms (and there are
lots of potential issues with IGP authentication at present)
ought also include analysis and discussion of RFC-2154.  If
RFC-2154 has issues, those would be useful to know in detail,
and such a document would be an appropriate place for such
information.

Cheers,

Ran

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 23 Dec 2008 15:41:32 -0800

R Atkinson wrote:
> RFC-2154 for general use at this time.

I agree...

>  It would be unusual

As a foil for a thought experiment it's  fine.

We continue to demonstrate that the problem space has not been fully
exhausted.

> ought also include analysis and discussion of RFC-2154.

noted

>  If

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 23 Dec 2008 15:56:49 -0800

Hi Ran,

Thanks for your replies. Snipping to relevent information, This is the
portion I was referring to which you have conveniently skipped:

"Regardless of use, NIST encourages application and protocol designers
to use the SHA-2 family of hash functions for all new applications and
protocols."

> collision resistance as soon as practical..."
I am sorry to use the term safe. My intent was to state that SHA-1 has
been mandated to be not used for particular applications, while .SHA-2
family is encouraged for use by protocol designers.

Are we on the same page regarding this or not?

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 23 Dec 2008 16:00:52 -0800

Hi Ran,

Again snipping to the right information.

> I don't see how one can draw that same conclusion now.
So are you stating that the current known vulnerabilities affect the
HMAC constructs too?

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 23 Dec 2008 16:42:02 -0800

Hi Ran,

Just some more information from the earlier link I sent you over:

"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs). "

So it seems in NIST view atleast SHA-1 with HMAC constructs is not
affected to warrant a reccomendation to stop its use like for the
other case.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 12:58:45 -0500

> to use the SHA-2 family of hash functions for all new applications and

That is a policy statement, not a claim that it is safe to use.

NIST are required by US law to recommend *something* for
US agencies to use, and SHA-2 has the largest raw key size
of NIST's (currently quite limited) choices.

However, NIST ARE working to deprecate SHA -- visible via
the process described on their web site.  That process
is entirely analogue to the process NIST used to replace
DES with AES -- public submission period, public review
period, and so forth.

> Are we on the same page regarding this or not?

I don't know what your view is.

NIST says that there are "serious attacks" on the
SHA family and NIST is actively working to deprecate
the SHA family (replacing it with something else).

So there is NOT scientific reason to believe that the
SHA family is stronger *as used in IGP authentication*
than some other algorithm -- nor is there reason to
believe some other algorithm is stronger than SHA given
what we know right now.

What would help here is a scientific paper comparing
A and B formally and reaching some conclusion(s),
a refereed openly published paper that everyone here
can read.

Cheers,

Ran
[email-masked]

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 13:02:49 -0500

> So are you stating that the current known vulnerabilities affect the

I'm claiming there is no clear scientific evidence that
any one approach is stronger than another.  There is data
causing anxiety about each of the underlying algorithms.

So far as I can tell from a literature survey, there are no
published attacks on Keyed-MD5 or on HMAC-MD5 or on HMAC-SHA
-- but that absence of published attacks does not provide
any scientific reason to prefer any one of those over any
other of those.

If someone has a refereed openly published paper evaluating
these scientifically, please share the paper (or a pointer
to the paper) here so everyone can read it.

Absent such a paper, the data collectively gives cause for concern,
but does not obviously support one choice over another *on
scientific grounds*.

Cheers,

Ran

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 13:08:31 -0500

> affected to warrant a reccomendation to stop its use like for the

Again, NIST by law is required to recommend something.
NIST only recommends NIST algorithms, which is why
they've kicked off the process to deprecate SHA and
select something else for their secure hashing.

The above quote is statement of policy, about what Federal
agencies may use in which situations.  It is not a claim
that any of those are "safe to use".  Separately that
quote does not support any claim that SHA is stronger
(or weaker) than some other algorithm in any particular
mode of operation.

Again, if you have an actual scientific referred openly
published paper comparing A and B, then please share it.

Until such a paper appears, we don't have the data to
make a scientific evaluation of which of several options
might be better or worse.

In any event, the IETF is global and is supposed to operate
based on science, not on the national policy of one country.

Cheers,

Ran

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 29 Dec 2008 13:16:39 -0800

Hi Ran,

Great to hear you back. Hope you had a good holiday.

I will reply to your earlier questions about the SHA algorithm as well
as the other mails you have replied to. I have worked over the
questions you raised as well as talked to cryptographers as well as
the AD's for the same.

> of NIST's (currently quite limited) choices.
That is good. So we agree that NIST atleast encourages the protocol
designers to use the algorithms. :) We probably also agree that there
is cutomer request for the use of the SHA algorithms as has been
brought out by others too.

I have been following the NIST development of the new protocol and it
is very well known inside the community  that any new algorithm to
replace SHA will be deployable only 10 years or so later. So I agree
its a good aim to have to use the algorithms that come out of the
selection process, the process itself may take a few years to get
through.

Regarding the talk of SHA algorithm having issues are correct however
after talking to cryptographers who have evaluated the current attacks
- it seems clear to them that MD5 strength is considerably lesser than
the SHA algorithm strengths. I will send you the details in another
mail. I have already shared the same with the WG chair.

It also seems clear from talks with the AD's that MD5 is not
recommended in any form for any cryptographic use - it is however
still not the case for SHA algorithm.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 16:54:44 -0500

On  29 Dec 2008, at 16:16, Vishwas Manral wrote:
> designers to use the algorithms. :)

Well, your words above are not what I said.

NIST prefers SHA-2 over other shorter forms of SHA,
probably because NIST (for now) can only recommend SHA
(as it is the only NIST hashing algorithm), NIST have
to recommend *something*, and SHA-2 has the longest
key size.

> We probably also agree that there

I'm the one who started the whole effort on SHA for IGPs,
just as I'm the one who started the whole effort to add
cryptographic authentication to IGPs last decade.
Having SHA as an option is sensible because it solves
a *policy* problem for some US Government users, including
some parts of DoD.  This was all covered in my past IETF
presentations.

> replace SHA will be deployable only 10 years or so later.

I disagree with your 10 year assessment.  AES deployed MUCH
MUCH more rapidly, after following a similar process for
public submission, public review, etc.  The IPsec magic
number for AES was allocated by IANA shortly after the AES
selection was announced by NIST, and there were interoperable
implementations of AES-CBC for IPsec ESP shortly after that
(even before the I-D appeared, as I recall).

> mail. I have already shared the same with the WG chair.

I've consistently asked for a peer reviewed paper.
I like Hugo, but an email containing another person's
opinion is not a peer-reviewed paper.

Mind, such paper ought to be about the algorithms *in the modes
used for IGPs* since the matter at hand is IGPs.

If someone has done some formal maths and published it,
in some peer reviewed forum, please provide a citation
(or URL or something) to that paper so everyone can read it.

Hugo publishes from time to time, if he has published on
this, it would be helpful if he'd provide the full
citation (a URL to the paper would also be nice).

> still not the case for SHA algorithm.

Thanks, but I'll wait for whichever ADs you mean above
to speak directly for themselves.

(Aside: MD5 was never a NIST algorithm; it isn't a surprise
to me that NIST hasn't recommended a non-NIST algorithm
for any uses.)

Cheers,

Ran
[email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 29 Dec 2008 14:00:50 -0800

Hi Ran,

I will deal with the two topics in seperate mails.
>From the NIST site and has been shared earlier with you (I am just
quoting what NIST states on its web site which has been updated 2
months back):

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 29 Dec 2008 14:08:53 -0800

Hi Ran,

It was really nice to have the discussion with you!!! It helped me
really look at and delve deeper based on the recent attacks on SHA-1
which I had anyway taken for granted would not make SHA-1 as weak as
MD5.

> I disagree with your 10 year assessment.
It is not my assesment. That is what William Burr from NIST has stated:

"SHA-3 is not going to be available, realistically, for another
decade, if you look how long it is going to take us to pick it and how
long it will take to make its way into products, well, we have been
telling people not to wait on SHA-3"

I agree AES took about 9 years to be mandated in say the IPsec RFC (so
a bit lesser than 10 years).

Thanks,
Vishwas

> AES deployed MUCH

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 29 Dec 2008 14:15:20 -0800

Hi Ran,

> opinion is not a peer-reviewed paper.
I agree you have asked for a peer reviewed paper for the exact use of
SHA for IGP's.

> citation (a URL to the paper would also be nice).
It seems you are hinting at a bigger issue here, that the IETF AD's
may need to change the policy regarding MD5 vs SHA-1 (for use in any
cryptographic function), because even though cryptographers may state
that MD5 is stronger than SHA-1 even for secure hashing purposes, it
may not necessarily be true.

Thanks,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 17:28:23 -0500

> to use the SHA-2 family of hash functions for all new applications and

Really, folks can (and likely have) read the whole URL by now.

Your quote above continues to be presented out of context.

The context of the quote is that SHA-0 and SHA-1 ought not be used,
so NIST considers SHA-2 preferable to SHA-0 and SHA-1.  As I've
*repeatedly* said, this is not surprising.  NIST only recommends
NIST algorithms.  NIST's only hash algorithm at present is SHA.
SHA-2 is the form of SHA with the longest key size.  NIST has
to recommend some NIST algorithm.  So the outcome is not a surprise.

In the interest of WG list bandwidth, and at the suggestion of
private email from some on this list, I will probably start
ignoring your notes about this narrow topic -- until you can
provide a refereed paper or two.

I can't tell if there is a language issue here or something else
is going on, but repetition isn't helping the WG make headway.

I've also asked Hugo if he might be kind enough to send
some citations to relevant refereed papers directly to this list.
Then folks here can read and review collectively whatever
appears from whomever finds any such papers.

> I agree AES took about 9 years to be mandated in
> say the IPsec RFC (so a bit lesser than 10 years).

You must have misread my note.  AES-CBC for IPsec shipped
in about 12 months, not 9 years.  AES-CBC for ESP shipped
well before the RFC was published, as I recall.

Oh, and NIST selecting AES took about 4 years (URL below
says 1997 to 2000/2001).

NIST's web page also says they expect to announce a new
hash function in 2012 (URL below).  Four years is somewhat
less than half of "10 years" from now.

Yours,

Ran

NIST Hash Timeline (includes AES timeline also):
	<http://csrc.nist.gov/groups/ST/hash/timeline.html>

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 29 Dec 2008 14:40:02 -0800

Hi Ran,

I am sorry if you are finding issues with my language.

> less than half of "10 years" from now.
This is great. Yes announcing an algorithm and actually seeing it in
the field is different. I have given you a quote from folks in NIST
itself (which does not talk about announcement of the chosen algorithm
but about actually finding the algorithms in the field). May be there
was some gap in the language again.

I have not imagined/ concoted the time lines myself. It however is
again based on a particular opinion and may not necessarily be
correct.

Regarding the cryptographic algorithms, I think we need to look at the
issue at a bigger level than just this list. Thanks for raising the
issues.

Thanks again,
Vishwas

---

From: R Atkinson <[email-masked]>
Date: Mon, 29 Dec 2008 17:45:39 -0500

On  29 Dec 2008, at 17:15, Vishwas Manral wrote:
> It seems you are hinting at a bigger issue here,

Please do not twist my words.

(Repetition of my prior comments for the Nth time
omitted here to conserve bandwidth. :-)

Yours,

Ran
[email-masked]