Subject: Fwd: [Isis-wg] Context for IS-IS HMAC SHS

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Apr 2007 18:28:17 -0400

Vishwas Manral asked:
% Can you please explain what difference it makes to having
% an Apad value of some constant random, and not a constant value of 0?

As you already know, I am not a mathematician and
I am not a cryptographer.

NIST is the originator of and standards body for Secure Hash Standard
(also called: Secure Hash Algorithm).  NIST provided specific
mathematics to use for protection of IGP information when SHS
is the algorithm in use.  I've talked with several different people
at NIST.  Each one has said to use the same mathematics.

RFC-4822 and at least the one draft use the mathematics that
NIST said to use.  Since the goal here is to make NIST happy,
which in turn makes lots of end-users happy, it was an easy
and quick decision just to follow their instructions.

The rationale for the mathematics really doesn't matter here.
If IETF is working with cryptographic algorithm X and the
standards-body for cryptographic algorithm X says to use
that algorithm in a particular way, the IETF should do it
that particular way.

For example, the KISA has standardised an algorithm called SEED,
which is also documented in RFC-4009.  RFC-4196 describes how
to use SEED in the context of IPsec.  RFC-4196 followed the KISA
instructions on how to use SEED with IPsec.  Same situation.
Same reasoning.  Same result.

Yours,

Ran

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Jack Kohn" <[email-masked]>
Date: Tue, 17 Apr 2007 05:31:19 +0530

RJ,

> at NIST.  Each one has said to use the same mathematics.

Did the possibility of them being bent towards that particular
"mathematics" cross your mind? I would not trust my life with what
people, where ever they work, suggest and advise me, unless i see a
proof ..

I guess this is what Vishwas is asking for. Quoting him from his earlier mail:

"Can you please explain what difference it makes to having an Apad value of
some constant random, and not a constant value of 0?"

> that algorithm in a particular way, the IETF should do it

Currently the standard body has NOT decreed on how X should be used.
It is, as i understand from your email, that some folks working there
believe on how X should be used.

There is a difference.

Its the case of how most of us put disclaimers saying that anything we
argue, write and speak about on the mailing lists is not neccesarily
what our employer thinks and believes in.

Feel free to correct me if i am wrong here, but this is what i
gathered from your email.

Affably,
Jack

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Apr 2007 20:28:29 -0400

> Currently the standard body has NOT decreed on how X should be used.

That is not my understanding.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Apr 2007 20:43:28 -0400

> people, where ever they work, suggest and advise me, unless i see a

In one feels that way, then one might want to invent one's own
algorithms for one's own use, since in the past some accepted
mathematical "proofs" have turned out to be wrong -- and one
might have the most confidence in one's own self.

As noted before, there are viable active attacks on IS-IS
that work fine without the attacker even worrying about
attacking the mathematics.  The only thing HMAC MD5 or NIST
SHS can do for IS-IS is prevent the really trivial "cleartext
password sniffing" types of passive attacks.

Besides, there are also other one-way hash functions
(i.e. beyond MD5 and NIST SHS) that someone might use.
If users wanted to use those additional algorithms,
then one might imagine writing up an additional document
on how to use those (e.g. RIPE-MD) with IS-IS.

Yours,

Ran

---

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 17 Apr 2007 07:48:08 +0530

Ran,
 
> at NIST.  Each one has said to use the same mathematics.

We have discussed this *several* times offline and I have forwarded you
scores of mails from different leading cryptographers who agree with us that
using Apad does not really add anything substantial to the security of the
HMAC construct. So let us not say that there are folks who claim certain
things unless there is a paper, study or proof to back that up, because
there is an equal set of folks who think that the HMAC construct used in the
WG doc is correct and flawless.

> and quick decision just to follow their instructions.

But not necessarily the right one ..

If you remember I had sent you an email while RFC 4822 was still in the
draft stage citing a possible attack that could have been thwarted if we had
used some other value for the constant Apad. An authenticated
RFC-4822-compliant RIP network is still vulnerable to a host of malicious
attacks despite using the NISTs SHA algorithms. Those could have been fixed
if we had been more circumspect and used a different value of Apad. These
attacks will get documented in the next version of
draft-manral-rpsec-existing-crypto-*. The solution would probably follow in
a subsequent draft.

> that algorithm in a particular way, the IETF should do it

I carefully read the Secure Hash Standard as described in the Federal
Information Processing Standards Publications issued by NIST after the
necessary approvals from the Secretary of Commerce and I could find no
mention of Apad there anywhere. It would be most helpful if you could point
out to the relevant text in the following link that indicates NISTs
recommendation of using the Apad. 

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.p
df

I then read NISTs FIPS PUB 198 document that details on how the HMAC should
be used in combination with an approved cryptographic hash function. There
also I could find no mention of the alleged benefits one reaps out of using
Apad. In fact the FIPS-198 does not even mention Apad and it has the same
cryptographic mathematics as described in the IS-IS WG doc.

http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf

Cheers,
Manav

___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 17 Apr 2007 08:18:37 -0400

> But not necessarily the right one ..

NIST officials have said that the mathematics in RFC-4822
are the ones to use.  It is their standard and their algorithm.
The IETF should follow their guidance on how to use it.

Which algorithm gets deployed is ultimately up to the
(ISP, enterprise, academic, home, other) network operators.
Many still use clear-text passwords today, with OSPF, IS-IS,
and RIP.

> If you remember I had sent you an email while RFC 4822 was still
> in the draft stage citing a possible attack that could have been
> thwarted if we had used some other value for the constant Apad.

I have no idea what you are talking about.

Further, AFAIK no one raised any cryptographic issues to the IESG
during the very substantial open review prior to approval and
publication of RFC-4822.  The Security Area reviewed the document
and supported the document being published as it has been.
RFC-4822 is without a doubt the most extensively reviewed document
that I've ever written.

The IESG had some discussion about whether to delay *all* new
algorithms for use with IGPs until the IETF standardised a
key management protocol suitable for use by IGPs.  Their
conclusion ultimately was not to block new algorithms with
existing IGP authentication mechanisms.

If one believed there was a flaw, one should have raised that
during the open review period so that the IESG could have
examined your claim.  That's why the IETF has the extensive
open review processes of today.

> An authenticated RFC-4822-compliant RIP network is still
> vulnerable to a host of malicious attacks despite using
> the NISTs SHA algorithms.

RIPv2, OSPFv2, and IS-IS are each vulnerable to a wide range
of non-cryptographic active attacks, regardless of which
mathematics are used.  I have said this for YEARS and said so
last week.  The ONLY thing these mechanisms are intended to do
is prevent passive eavesdropping attacks.

As a result, an attacker who focused on cryptanalysis would be
silly,  and all the evidence is that attackers are not silly.

That said, there are a set of users who want to use NIST
SHS in a way that conforms with NIST's guidance.  And that
is the only reason I know of to undertake any work with
NIST SHS in the context of IS-IS.  There are no known
cryptographic vulnerabilities in the existing use of MD5
with IS-IS.

If folks want something stronger, I'd suggest moving to full
digital signatures.  RFC-2154 describes OSPF with Digital
Signatures.  So far, I am not aware of any operational
interest in OSPF with support for RFC-2154.  Maybe someone
will decide to undertake a specificcation for IS-IS with
Digital Signatures.  (I do not plan to do so.)

I don't see much value in rehashing this further.

Yours,

Ran
[email-masked]

---

From: "Manav Bhatia" <[email-masked]>
Date: Tue, 17 Apr 2007 18:09:04 +0530

The following is a digression from what we're discussing but I'll respond to
 
> open review processes of today.

I never once said that the crypto maths was flawed. I'm saying it could have
been better. The document was an individual submission and there was no
forum (like the WG mailing lists) really to discuss the draft - or at least
none that I was aware of.

> silly,  and all the evidence is that attackers are not silly.

One doesn't need to do much to attack an RFC-4822 compliant RIP network! 

Because RFC 4822 doesn't protect the IP header, any attacks on the header
would disrupt the RIP routing in the network. Some very interesting attacks
can be made by playing with the source IP of the RIP packet. A little
insight could have prevented all of such attacks!

So whats done is done, lets focus on what we have before us .. ! :)

Cheers,
Manav

___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 17 Apr 2007 08:57:17 -0400

On  17 Apr 2007, at 08:39, Manav Bhatia wrote:
> forum (like the WG mailing lists) really to discuss the draft - or  
> at least none that I was aware of.

For the future:

The IESG announce a public Last-Call for any standards-track individual
submissions on the IETF Announce list.  In that last call, it usually
says that discussions can be put onto the general IETF discuss list.
Occasionally, the note specifies a specific different list.  Further,
the IESG's own mailbox ([email-masked]) is well known and one can
send mail directly to them.

> would disrupt the RIP routing in the network. Some very interesting  
> attacks can be made by playing with the source IP of the RIP packet.
> A little insight could have prevented all of such attacks!

IPsec AH can also provide such protection for RIP and OSPF.
In fact, had AH been a choice back in the day, that's probably
what the IETF would have been chosen.  I applaud the work on
back-porting AH to protect OSPFv2.   Because IS-IS runs directly
on the link layer, AH is not applicable to IS-IS.

RFC-4822 solves the one narrow problem it addressed -- preventing
passive attacks -- and it did so in a way that made the users who
requested that capability happy.

There are actually even easier attacks on RIP than those you outline
(i.e. packet modification attacks).   The Security Considerations
section of RFC-4822 outlines a number of them.  :-)

Cheers,

Ran