Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft

From: sujay <[email-masked]>
Date: Wed, 23 Aug 2006 14:36:27 +0530

Yes,

If an authentication fails it could mean the algo's used are different.

And if one implementation supports MD5 alone( "which I believe is commonly
used !" ), the others

support otherwise, It could be a problem, there is no explicit way we are
converying which algo is being used.

The Au Type = 2 is overloaded.

Now a "MUST" clause is for the WG to decide.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229
<http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=
h&hl=en> &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! 

  _____  

From: Manav Bhatia [mailto:[email-masked]] 
Sent: 2006年8月23日 13:04
To: 'sujay'
Cc: 'Mailing List'
Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft

Sujay, 

> 
>Can we have a default algo. concept?? 
> 

What do you mean by the default algo? Is it one authentication algorithm
that all implementations MUST support? 

Manav 

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

---

From: Dave Katz <[email-masked]>
Date: Wed, 23 Aug 2006 09:11:45 -0600

Sigh.  C'mon, folks, there is no problem.

View the algorithm as simply part of the shared secret.  All  
authentication is done between consenting adults and there has to be  
out-of-band and a priori agreement on the parameters or the  
authentication fails.  Nobody is going to be guessing the algorithm  
in use on a particular session any more than they would be guessing  
the secret.  And if you want to switch algorithms (which is  
essentially just switching secrets) the key ID mechanism is present.

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.  For that matter, I don't think that even the  
existing algorithm ID is necessary, since the entire thing has to be  
agreed upon a priori anyhow.

For what it's worth, type 2 fits the bill just fine, defined the way  
that it is.  If one box does only MD5 and the other box only does  
SHA, they cannot talk.  If they share an algorithm, it is up to the  
user to configure the two boxes compatibly, like a thousand other  
parameters.  While having a separate code point for SHA would have  
marginal debugging utility ("wrong algorithm, dummy!") it's no harder  
to make sure that this matches on both sides than it is to make sure  
the shared secret matches.

--Dave

On Aug 23, 2006, at 3:06 AM, sujay wrote:

> And if one implementation supports MD5 alone( "which I believe is  
> commonly used !" ), the others
>
> support otherwise, It could be a problem, there is no explicit way  
> we are converying which algo is being used.
>
> 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!
>
>
> What do you mean by the default algo? Is it one authentication  
> algorithm that all implementations MUST support?
>
> Manav
>

---

From: Paul Jakma <[email-masked]>
Date: Thu, 24 Aug 2006 05:08:55 +0100 (IST)

> 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 
> 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-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
We promise according to our hopes, and perform according to our fears.

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 24 Aug 2006 10:23:35 +0530

Paul,

> OSPF but can be made to interoperate unless authentication is left
We have drafts to meet the following exact requirements:
http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.txt
 and
http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.txt

for OSPF and IS-IS respectively.

Thanks,
Vishwas

---

From: sujay <[email-masked]>
Date: Thu, 24 Aug 2006 11:06:49 +0530

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

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Thursday, August 24, 2006 10:24 AM
To: [email-masked]
Cc: [email-masked]; 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

Thanks,
Vishwas

On 8/24/06, Paul Jakma <[email-masked]> wrote:
> 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.
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 28 Aug 2006 15:48:56 +0530

Sujay,

I agree we can include that in the draft. The reason as well as the
links to the draft.

Thanks,
Vishwas

---

From: Erblichs <[email-masked]>
Date: Mon, 28 Aug 2006 13:12:36 -0700

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.

	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
	----------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 29 Aug 2006 13:21:11 +0530

Erblichs,

If you read RFC4305, the implementation requirements have and must be changed.

   The implementation requirements are compared below:

   Old   Old         New
   Req.  RFC(s)      Requirement  Algorithm (notes)
   ---   ------      -----------  ---------
   MUST  2406        SHOULD NOT   DES-CBC [RFC2405] (1)
   MUST  2402 2406   MAY          HMAC-MD5-96 [RFC2403]
   MUST  2402 2406   MUST         HMAC-SHA1-96 [RFC2404]

We expect the same for all protocols utilizing the crypto algorithms.

Thanks,
Vishwas

---

From: "Tom Sanders" <[email-masked]>
Date: Tue, 29 Aug 2006 21:28:51 +0530

Erblichs,

I am not sure if Vishwas addressed your concern. If he did, then i am
at fault in understanding your concern. However, let me give it a
shot.

-- 
Toms.

---

From: "Tom Sanders" <[email-masked]>
Date: Tue, 29 Aug 2006 21:37:55 +0530

Sorry .. I sent an incomplete mail .. ;)

> >        this will NO longer be the case if we overload

I assume you are at this point referring to
draft-bhatia-manral-white-ospf-hmac-sha-02.txt. Lets not rehash the
same discussion regarding overloading Auth 2 here.

> >          at this time, will not guarantee interoperability.

Which is where the draft-bhatia-manral-crypto-req-ospf-00.txt helps.
The authors can correct me if i am wrong in my understanding here.

> >          specified as the MUST algor?

MD5 is MUST- while HMAC-SHA-1 is SHOULD+.

I think the definitions in the beginning of the draft would help.
Reading those again tells me that we may at some later point deprecate
MD5 and mandate support for hmac-sha-1 for all the implementations.

hmac-sha-1 would then be a MUST and the other higher variants of
hmac-sha SHOULD+.

Toms.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 29 Aug 2006 13:42:25 -0400

Hi Mitchell,

> 	this will NO longer be the case if we overload
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