Hi Mitchell,
Erblichs wrote:
Group,
Sometimes a minor opinion..
First. Up to this point, IMO, 99%+ nbr misconfigs
could be debuged at 1 local router with review of
incoming pkts. With this "work-in-progress",
this will NO longer be the case if we overload
type 2.
I believe Dave Katz already made this point. However, let me apply it to
your statement. Previously, you could have a key mismatch. With the
new draft you can have a key/algorithm mismatch - I don't see that
this is that big a change.
Thanks,
Acee
What is a 'Must' clause going to achieve?
By default ALL implementations support MD5, simple/clear,
and NULL auth. The only high probability of a nbr
formation is to use one of these three. Yes, MD5 was
the defacto standand auth 2 algor.
Thus, any algor that super-ceeds one of these auths,
at this time, will not guarantee interoperability.
However, as pointed out in the draft, the highest
common auth is not highly secure, but could be used
as a fall back. Yes, the admin would see either before
or after a nbr formation attempt that a mismatch
exists, and reconfigs the routers to use the fallback.
Thus, to support backward compatibility and to secure
against SOME attacks, IMO all configs SHOULD/MUST support
MD5.
If this is the case, would the clause only improve the
chance that "MD5" is not removed as newer algors are
supported?
Or is their a thought for a algor other than MD5 to
specified as the MUST algor?
Mitchell Erblich
----------------
Vishwas Manral wrote:
Sujay,
I agree we can include that in the draft. The reason as well as the
links to the draft.
Thanks,
Vishwas
On 8/24/06, sujay <[EMAIL PROTECTED]> wrote:
Agree,
While a failed authentication could be basically due to configuration issues
or
Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported
algo'
may need an Image upgrade. It's my guess image upgrade may not be
thoroughly welcome.
We do need a 'Must' support algo. clause.
Vishwas ; would it be a nice idea to add a section in the current draft,
talking about this issue
and with cross reference to the below mentioned drafts??
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h
&hl=en
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: Vishwas Manral [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 24, 2006 10:24 AM
To: [EMAIL PROTECTED]
Cc: [email protected]; Mailing List
Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft
Paul,
There is though value in defining "MUST support" algos, otherwise poor
users could be faced with having routers which all implement OSPF but
can be made to interoperate unless authentication is left
unconfigured.
We have drafts to meet the following exact requirements:
http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t
xt
and
http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t
xt
for OSPF and IS-IS respectively.
Thanks,
Vishwas
On 8/24/06, Paul Jakma <[EMAIL PROTECTED]> wrote:
On Wed, 23 Aug 2006, Dave Katz wrote:
Sigh. C'mon, folks, there is no problem.
At the end of the day it doesn't matter if the value of 2 or 3 or
42 is used; if there's a mismatch on the the algorithm ID, the
algorithm, or the key, the authentication will fail, and if it all
matches, it will work.
Strongly concur.
There is though value in defining "MUST support" algos, otherwise poor
users could be faced with having routers which all implement OSPF but
can be made to interoperate unless authentication is left
unconfigured.
MD5 at least should be defined as a MUST support.
(Despite the pre-image weaknesses, it's still not yet completely
insecure in MAC mode)
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
