Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 2 Dec 2008 07:32:49 +0530

Hi,

We have posted a revised version of the "Cryptographic Authentication
Algorithm Implementation Best Practices for Routing Protocols". 

This has been updated based on the feedback from the list and the IETF
meet where it was suggested that we should (i) do away with the
additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii)
Change the tone of the draft so that its more like best practices rather
than a diktat for protocol developers.

Additionally, we have also included a small section on RIPng and OSPFv3
in this draft.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi
rements-03.txt
 
Would appreciate comments and feedback on the version!

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joel Jaeggli
> Sent: Saturday, October 11, 2008 2.40 AM
> To: opsec wg mailing list
> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00
> 
> We have at least some supporting opinion that this work should not be
> pursued in opsec if it defines requirements. With a recommendations or
> best practices focus it would be an appropriate addition. We should be
> willing to entertain alternative views but I think that's the 
> current sense.
> 
> joelja
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Glen Kent" <[email-masked]>
Date: Wed, 3 Dec 2008 22:20:15 +0530

Hi,

Overall, the draft looks in good shape and i support it.

One small comment though - I think their concern regarding the lack of
security offered by MD5 for the routing protocols is misplaced. I am
referring to the Introduction in that above draft. I agree that while
it might be possible to spoof an acceptable MD5 digest, it is near
impossible to spoof what might be an acceptable routing protocol
packet with an acceptable spoofed digest.So, the authors might want to
tone down their concern in that section!

Glen

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 04 Dec 2008 22:54:58 -0800

> tone down their concern in that section!

The general problem of being able to produce collisions with md5 digests
does kind of make one inclined to deprecate their use when possible even
when there are a limited set of circumstances  under which it can be
exploited. MD5 is used in lots of places and it will take a very long
time to remove it from many of them... The law of unintended
consequences says if I leave the MD5 library in my toolchain someone
will eventually use it for some purpose for which it is totally unsuitable.

I think description of the deprecation of md5 limitations in paragraph 3
of the introduction could use some help.

one document that similarly addressed this subject I saw recently was:

http://tools.ietf.org/html/draft-ietf-dnsext-tsig-md5-deprecated-01

the security considerations second of which describes to motivation
fairly well.

One concern I would express in the context of how this is done today is
the persistence of the shared secret used to protect these sessions is
measured in years notwithstanding the issues around storing things that
persist that long an attacker with access to the packet stream can avail
themselves of the opportunity to try to perform tradition brute force
activities to generate the secret used to hash the data and generate the
digest the salt in these protocols (eg tcpmd5) is sufficiently large to
render rainbow tables infeasible...

That's not really for this draft but it is worth thinking about longer term.

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 5 Dec 2008 07:27:08 -0500

(initially sent with wrong src-addr, apologies)

On Fri, Dec 5, 2008 at 7:25 AM, Christopher Morrow
<[email-masked]> wrote:
> On Fri, Dec 5, 2008 at 1:54 AM, Joel Jaeggli <[email-masked]> wrote:
>> Glen Kent wrote:
>>> Hi,
>>>
> to be able to make a collision with content worthwhile to the problem
> space seems very limited, knowing the key and spitting out a packet on
> the wire which is signed would be far simpler.
>
> I agree that longer term migrating away so it's not re-used in a bad
> place/way is fine... I think people often stop with: "Md5 has
> collisions so we shouldn't use it" before asking if making a collision
> in their circumstances is relevant or possible in a timely fashion.
>
> the secrets stay the same because someone though adding md5 auth to
> routing protocols was a good thing (which is probably is in some/many
> cases) but stopped there. There was never any thought put into the
> operations of the system, just the 'security'... Key rollover/change
> is significantly painful that pretty much no one actually does it.
>
> -Chris
>

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Fri, 5 Dec 2008 20:29:32 +0530

Hi Glen,

Thanks for the comments.

> packet with an acceptable spoofed digest.

I agree and we do mention this in the draft! :-)

> So, the authors might want to

We have the following text in the Introduction.

"It should however be noted that these attacks may not necessarily
result in direct vulnerabilities in Keyed-MD5 as used in the routing
protocols for authentication purposes, because the colliding message may
not necessarily be a syntactically correct protocol packet. However,
there is a need felt to move away from MD5 towards more complex and
difficult to break hash algorithms."

Is there something specific that you are looking for?

Cheers, Manav

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 05 Dec 2008 19:26:50 -0800

> is significantly painful that pretty much no one actually does it.

solving this problem is safely outside the scope of our working group. ;)

That said one could imagine adding some additional element to the shared
secret that could be derived at startup of the protocol session
(wouldn't work for broadcast) like current time at transmission of the
first packet, that would make the actual shared secret on the wire only
relevant for the duration of a single session, (it would require clocks
have a certain minimum amount of syncronization) without further
negotiation.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Glen Kent" <[email-masked]>
Date: Wed, 10 Dec 2008 04:24:56 +0530

Hi,

> difficult to break hash algorithms."

Sorry, i missed this.

> Is there something specific that you are looking for?

No, not really.

Glen.