Re: [OSPF] Re: Stronger Non-IPSec OSPFv2 Authentication

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

Hi Acee,

Thanks for the comments.

I agree we can get stronger authentication, but its of no use unless
we specify that in case we want security we MUST support the
algorithm. As the number of algorithms increase we need to specify a
minimal set of algorithms that need to be supported, else the
interoperability between implementations that want to support security
is not guarenteed .

Also, as has been pointed out earlier, we have seen in IPsec RFC4305
as well as RFC4305-bis (of which I am the author), as the computing
power increases and security algorithms become vulnerable to new
attacks, we do not have to change RFC's that talk about how to use the
algorithm. The only RFC that changes is the one that specifies the
support levels of various security algorithms.

Though it may sound obvious, the support for NULL algorithm states
that if we need support for Security we should not use the NULL
authentication algorithm.

These were the exact lessons learnt in the past in IPsec. I guess we
should take care not to repeat the mistakes again.

Thanks again,
Vishwas

On 3/28/07, Acee Lindem <[e-mail]> wrote:
> Speaking as a WG member (so I can state my opinion without having to be nice
> :^):
>
> I like this option the best since it allows us to get the stronger
> authentication without having to agree on the requirements text. Since it
> was presented in Paris, I've never liked the text in
> draft-bhatia-manral-crypto-req-ospf-01.txt. While footnotes
> have been added to address my concerns, it might be easier not to try and
> agree on this at all.
>
> I don't like section 3 since, until you read the footnotes, it implies NULL
> and simply authentication MUST NOT be used. Null authentication is by far
> the easiest to administer, the most efficient, and, I'd wagger, the most
> widely deployed. Simple authentication can be useful in situations where you
> simply want to run two communities of OSPF routers on the same wire. It is
> also good for places where you don't want inadvertent participation in the
> OSPF routing domain. You many "trust" the people who have access to the
> physical networks running OSPF or have sufficient motivation for them to
> behave.
>
> With respect to MD5 authentication - this is currently widely deployed and
> it will take some time to be replaced. Hence, I think the whole draft could
> be replaced by a statement to the effect that "Users desiring cryptographic
> authentication may consider using algorithms x, y, or z due to the
> vulnerabilities in MD5. ....".
>
> Thanks,
> Acee
>
>
>
>
> On Mar 28, 2007, at 8:43 AM, Acee Lindem wrote:
>
> After discussions with members of the ISIS WG, there is a third option which
> would be to accept
> draft-bhatia-manral-white-ospf-hmac-sha-03.txt but not
> draft-bhatia-manral-crypto-req-ospf-01.txt. I'd like to
> throw that out as an
> option.
>
> Thanks,
> Acee
>
>
>
> On Mar 27, 2007, at 9:16 AM, Acee Lindem wrote:
> These drafts were presented in San Diego and seem to have considerable
> support.
>
> draft-bhatia-manral-crypto-req-ospf-01.txt
> draft-bhatia-manral-white-ospf-hmac-sha-03.txt
>
> Hence, we plan to make these WG documents unless there is significant
> opposition or a compelling reason not to do so.
> Thanks,
> Acee
>
>
>
>
>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf