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

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

Hi Ran,

Thanks a lot for the effort and the comments. As you said, you have
not been reading the archives or any of the documents,  the following
link will give you the archive
http://www1.ietf.org/mail-archive/web/isis-wg/current/index.html and
the document you are referring to is located at
http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-01.txt.
We intend to move the document to RPsec, based on comments from a lot
of people regarding the same.

> 1) MD5 is NOT compromised as currently used with IS-IS
You are right and this has been clearly discussed earlier. Please have
a look at http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01703.html.

> There is at least one proposal on the table that uses mathematics provided by NIST
> for the purpose of IGP authentication.
Ran, we have discussed this multiple times offline. We have given you
pointers from what cryptologist's have regarding the same. Can you
please explain what difference it makes to having an Apad value of
some constant random, and not a constant value of 0?

Thanks,
Vishwas

RJ Atkinson wrote:
> Background:
>     I'm not actually a subscriber to the IS-IS list,
> nor particularly a member of this WG, but someone recently
> made the point that I ought to be reading the list archives
> and participating.  So I just scanned the first page of
> archives rapidly -- and this is an effort at participating.
>
>
> Hi,
>
> I think there might be some confusion about why it would be
> useful to have an open specification (not necessarily
> a standard) for how one would use HMAC SHS with IS-IS.
>
> 1) MD5 is NOT compromised as currently used with IS-IS
>
>     There is no known practical attack on MD5 as it
> is specified in RFC-3567.  If anyone knows of such an
> attack, a full citation (or preferably PDF) of a paper
> describing the attack would be appropriate to share here.
> So HMAC SHS isn't solving any *current* issue with MD5
> as used with IS-IS.
>     There are some credible papers (e.g. Dobbertin)
> suggesting that the compression function in MD5 is not
> as strong as previously believed.  There is a big difference
> between the claims made by those papers and an actual
> cryptographic vulnerability in MD5 as used in RFC-3567.
>
> 2) Cryptographic Authentication is not a panacea.
>
>     Cryptographic authentication was added to
> various IGP routing protocols (by me and various co-authors)
> to solve a single problem -- vulnerability to passive
> attack (i.e. sniffing) of cleartext passwords on the wire.
>     Any form of cryptographic protection, even a
> mechanism that could be cryptanalytically attacked,
> provides protection against passive attack on IS-IS
> clear-text passwords, which is the root problem that
> RFC-3567 is trying to address.
>     Further, none of those mechanisms (and none of
> the current proposals that I'm aware of [1,2]) prevent
> certain non-cryptographic active attacks on IS-IS.  If some
> bad party has access to a link where IS-IS packets are being
> transmitted/received, then there are various active attacks
> that can be undertaken that don't require any cryptanalysis
> and that none of the current specifications/proposals can
> prevent.  (I'm deliberately omitting details since I haven't
> seen the details of the attack vector published openly,
> but if one thinks about this, one can probably come up
> with some within a day or so.[1])
>     Attackers aren't stupid.  They generally are
> both reasonably smart and also lazy.  So they will
> undertake the attack that requires the LEAST effort
> from them.  So most attackers of IS-IS will use the
> non-cryptographic attack vector(s), rather than trying
> to cryptanalyse either RFC-3567 or any other proposal.
>
> 3) There is a customer/business issue.
>
>     Many governments (e.g. US, UK, AU, SG) want to purchase
> products that only use approved cryptographic algorithms and
> modes.  Many countries (not including France) are using the
> US NIST FIPS 140-2 approval/certification process as their
> purchasing metric.  Many multi-national insurance, banking,
> and financial firms (e.g. HSBC) are also looking to use
> products that have a FIPS 140-2 approval because it provides
> higher assurance than not using that sort of formal evaluation.
>     MD5 is not permitted under FIPS 140-2.  NIST SHS,
> in certain modes and usages that NIST likes, is permitted.
>     Implementers that want their implementation to be
> used by those certain governments and pass a FIPS 140-2
> evaluation need to have a way to implement something using
> NIST SHS (in lieu of MD5 as per RFC-3567) that would make
> NIST happy.  Given this context, following guidance from
> NIST seems to be important.  There is at least one proposal
> on the table that uses mathematics provided by NIST for the
> purpose of IGP authentication.[2]
>
>
> Yours,
>
> Ran Atkinson
> [e-mail]
>
> DISCLAIMER: I'm in research, not in product development.  Also,
> I am never authorised to speak for my employer.  This note is
> NOT necessarily my employer's views on anything.
>
> [1] I have never and will never be the first to publish openly
> any potential attack.  If I could reference someone else's
> published attack defintion, I would have done so above.  :-)
> So asking me for details is a waste of everyone's time.
>
> [2] I am WAY WAY behind on many fronts, including but not limited
> to IS-IS, so I'm NOT current on the details of the full set
> of proposals that might be on the table.
>

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