Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

[Erblichs <[e-mail]>]

Wow,

> This specification does not mandate specific encryption and
> authentication algorithms because the recommendation for encryption
> and authentication algorithms changes with time as the algorithms
> are broken and more secure algorithms are invented.
> 

	Sorry, I am lost with this. The devil in me says that
	this means to DELAY" this RFC until a SECURE algorithm
	that will NEVER need to be changed is identified.

	OSPF has specified features and is documented and is changed
	in the future with later RFCs.

	What is wrong with guaranteeing that at least one algoritm
	is specified for interoperability?

	Then as better algorithms are identified, then they are
	specified in later docs and superseed earlier algorithms.
	Then only the first algorithm is a MUST support and later
	algorithms need  be a SHOULD supported for later 
	compatibility.
	Right..
	Yes, the full set could be supported, but is probably not
	a must, since the first is guaranteed...

	Thus, isn't at least one specified so so algorithm better than
	guaranteeing  NULL for encryption, etc?

	Mitchell Erblich
	----------------

Vishwas Manral wrote:
> 
> Hi Mukesh,
> 
> I am ok with the text.
> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: Mailing List [mailto:[e-mail]] On Behalf Of
> Mukesh Gupta
> Sent: Monday, January 10, 2005 12:09 PM
> To: [e-mail]
> Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
> 
> Acee,
> 
> Vishwas is right.  I don't think we can mandate a specific algorithm
> in the draft and not have to update it in future.
> 
> What about we say something like..
> 
> ====
> This specification does not mandate specific encryption and
> authentication algorithms because the recommendation for encryption
> and authentication algorithms changes with time as the algorithms
> are broken and more secure algorithms are invented.
> 
> In order to interoperate with each other, the implementations have
> to have at least one common algorithm that the user can choose to
> use for OSPFv3 security.
> 
> The implementation MUST allow the user to choose all the encryption
> and authentication algorithm that are MUST in IPsec mandatory to
> implement algorithms.
> 
> The implementation SHOULD allow the user to choose all the encryption
> and authentication algorithm that are SHOULD in IPsec mandatory to
> implement algorithms.
> ====
> 
> Regards
> Mukesh
> 
> > -----Original Message-----
> > From: Mailing List [mailto:[e-mail]]On Behalf Of ext
> > Vishwas Manral
> > Sent: Sunday, January 09, 2005 8:17 PM
> > To: [e-mail]
> > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
> >
> >
> > Hi Acee,
> >
> > I agree totally with your views.
> >
> > However examples where algorithms "support has been changed" are: -
> >
> > "
> >    Old   Old         New
> >    Req.  RFC(s)      Requirement  Algorithm (notes)
> >    ---   ------      -----------  ---------
> >    MUST  2406        SHOULD NOT   DES-CBC [RFC 2405] (1)
> >    MUST  2402 2406   MAY          HMAC-MD5-96 [RFC 2403]
> >    MUST  2402 2406   MUST         HMAC-SHA1-96 [RFC 2404]
> > "
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Mailing List [mailto:[e-mail]] On
> > Behalf Of Acee
> > Lindem
> > Sent: Monday, January 10, 2005 12:49 AM
> > To: [e-mail]
> > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
> >
> > Mukesh, Vishwas,
> >
> > Here is my take. The document should be written in such
> > a way that  it doesn't need to be updated every time the
> > IPSec algorithm
> > de jour changes.
> >
> > However, I also think the document should specify algorithms with the
> > caveat that they may be updated. IMHO, once an
> > authentication/encrpytion
> > algorithm is deployed, it is unlikely to be withdrawn from support.
> > Hence,
> > if someone develops a stronger algorithm with lower computational
> > requirements
> > and it becomes the recommended alogorithm, then implementations will
> > need
> > to support it in ADDITION to what they are currently supporting.
> >
> > Is this possible? Any other opinions?
> >
> > Thanks,
> > Acee
> >
> >
> > Mukesh Gupta wrote:
> >
> > >Vishwas,
> > >
> > >Comments inline..
> > >
> > >
> > >
> > >>VM> I do not think you talk about encryption at all when you
> > >>talk about
> > >>AH. If you check the documents I have pointed to carefully,
> > >>you will see
> > >>NULL Encryption is a special case of encryption when
> > encryption is not
> > >>used.
> > >>
> > >>
> > >
> > >Would it make more sense if we change the text "NULL encryption"
> > >to "NULL encryption (for ESP) or no encryption (for AH)" ?
> > >
> > >
> > >
> > >>Suresh> We are not a fan of DES either for obvious reasons.
> >  But as we
> > >>wanted to start with the weakest algorithm, we started with DES.  We
> > >>wouldn't have to mention DES at all, had IETF/NIST
> > >>suggested DES as "MUST NOT".
> > >>VM> I still don't see a reason why we should talk about DES at all.
> > >>
> > >>
> > >
> > >I still don't understand why we can't use DES as an example of a weak
> > >encryption algorithm.
> > >
> > >I would like to hear others' opnion about this ?  Acee?
> > >
> > >
> > >
> > >>Suresh> Mukesh and I discussed this again and we agree that
> > >>referring to
> > >>the IPsec algorithm draft should be the better way to go.
> > >>VM> Also not for the authentication you have given the key
> > length and
> > >>for Encryption you have not(so there is anyway a case of
> > >>inconsistency).
> > >>
> > >>
> > >
> > >Yeah but this will be fixed too if we didn't mention any algorithm
> > >and just pointed to the madatory to implement algos.  Right ?
> > >
> > >
> > >
> > >>Suresh> What about the following:
> > >>"Replaying these type of packets can make the router spend some
> > >>resources.  Also when the OSPF adjacency is not FULL, replaying
> > >>database description packets can cause disruption in forming the
> > >>adjacency."
> > >>VM> Its not just forming the adjacency Suresh but the link becoming
> > >>unusable for transit traffic (DoS). In my view you should
> > >>just refer to
> > >>the vulnerabilities draft and probably put a sentence like
> > the above.
> > >>
> > >>
> > >
> > >We do refer to the vulnerabilities draft after the brief discussion
> > >of the replay vulnerabilities..  So are you ok with putting the
> > >text proposed above and then referring to the vulerabilities draft ?
> > >
> > >
> > >
> > >>VM> You are right. However I think the aim of the draft is
> > to specify
> > >>how we should use IPSec (guidelines) as well as specify the default
> > >>behavior(Maybe for all optional parameters we should specify this).
> > >>
> > >>
> > >
> > >You are right.  The aim of this draft is to specify how OSPFv3 should
> > >use IPsec but I still fail to understand why we need to
> > specify things
> > >that are not related or exposed to OSPF :(
> > >
> > >What exactly do you want to specify about ESN?  Do we want to say
> > >that there is no impact of the usage of ESN by the underlying IPsec
> > >implementation on OSPFv3 security because sequence numbers
> > are ignored
> > >while manual keys are used ?
> > >
> > >Regards
> > >Mukesh
> > >
> > >
> > >
> >