Subject: [OPSEC] Fwd: secdir review of draft-ietf-opsec-igp-crypto-requirements

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2010 18:14:12 -0400

Hi all,

This is happening on the general and secdir lists -- apologies it has  
taken me a few days to notice, I was over-filtering...

W

Begin forwarded message:

> From: Samuel Weiler <[email-masked]>
> Date: September 15, 2010 2:13:53 PM EDT
> To: [email-masked], [email-masked], [email-masked]
> Subject: secdir review of draft-ietf-opsec-igp-crypto-requirements
>
> I have reviewed this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Document editors and WG chairs should  
> treat these comments just like any other last call comments.
>
> This is an informational document that appearently recaps  
> requirement levels for implementation and use of crypto algorithms  
> for hop-by-hop authentication of routing data.  Assuming that no  
> requirements are being changed, I have no objections to the security  
> considerations analysis, but I do have editorial comments.
>
> I got lost as to the purpose of this doc.  Please reword the  
> abstract and intro to make it clear that you're merely recapping  
> requirements, not setting them (if that is indeed true).
>
> Is there a way to present this information more compactly?  I  
> suggest a table with routing protocol on one axis, crypto suite on  
> another, and requirement status in the elements (perhaps with a cite  
> to the doc that sets the requirement).  You might separely say  
> "MANDATORY to implement, OPTIONAL to use, NOT SUGGESTED for use".
>
> You could also put suggestions and speculation about the future in  
> the same table, though you may need to define some terms.  And it  
> needs to be clear when this doc diverges from past ones or makes a  
> new statement.  I have not gone back through the previous docs to  
> confirm that this doc isn't changing anything.
>
> I see a whole bunch of lower case "may" and "should", and I'm  
> wondering what to make of them.
>
> In describing each routing protocol's authentication options, it  
> would be helpful to say whether there's any in-band negotiation  
> available. If so, more needs to be said about that in the security  
> considerations.  If not, it should be documented here.
>
> I don't need to hear three or four separate times that cleartext  
> passwords are bad.
>
> Minor: remove citations from the abstract (per rfc editor policy).
>
> -- Sam
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--
There were such things as dwarf gods. Dwarfs were not a naturally  
religious species, but in a world where pit props could crack without  
warning and pockets of fire damp could suddenly explode they'd seen  
the need for gods as the sort of supernatural equivalent of a hard  
hat. Besides, when you hit your thumb with an eight-pound hammer it's  
nice to be able to blaspheme. It takes a very special and straong- 
minded kind of atheist to jump up and down with their hand clasped  
under their other armpit and shout, "Oh, random-fluctuations-in-the- 
space-time-continuum!" or "Aaargh, primitive-and-outmoded-concept on a  
crutch!"
   -- Terry Pratchett

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2010 18:14:20 -0400

Begin forwarded message:

> From: "Bhatia, Manav (Manav)" <[email-masked]>
> Date: September 15, 2010 7:36:00 PM EDT
> To: Samuel Weiler <[email-masked]>, "[email-masked]"  
> <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked] 
> " <[email-masked]>
> Subject: RE: secdir review of draft-ietf-opsec-igp-crypto-requirements
>
> Hi Samuel,
>
> Thanks for the review.
>
>> Is there a way to present this information more compactly?  I suggest
>> a table with routing protocol on one axis, crypto suite on another,
>> and requirement status in the elements (perhaps with a cite
>> to the doc
>> that sets the requirement).  You might separely say "MANDATORY to
>> implement, OPTIONAL to use, NOT SUGGESTED for use".
>
> This is precisely what we were doing till the OPSEC WG members asked  
> us to change the format to the current one.
>
>>
>> You could also put suggestions and speculation about the
>> future in the
>> same table, though you may need to define some terms.  And it
>
> We were using extended 2119 terms like SHOULD+, MUST- and MAY+  
> originally and these were again removed because of the strong  
> consensus in the WG in favor of the current text.
>
>> needs to
>> be clear when this doc diverges from past ones or makes a new
>> statement.  I have not gone back through the previous docs to confirm
>> that this doc isn't changing anything.
>>
>> In describing each routing protocol's authentication options,
>> it would
>> be helpful to say whether there's any in-band negotiation available.
>
> I am not sure I understand whats being meant by in-band negotiation  
> here?
>
>> If so, more needs to be said about that in the security
> Just making sure that folks don't miss this! :)
>
>>
> Sure, will do.
> Cheers, Manav

-- 
"Does Emacs have the Buddha nature? Why not? It has bloody well  
everything else!"

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2010 18:14:27 -0400

Begin forwarded message:

> From: Joel Jaeggli <[email-masked]>
> Date: September 16, 2010 2:31:40 PM EDT
> To: "Bhatia, Manav (Manav)" <[email-masked]>
> Cc: Samuel Weiler <[email-masked]>, "[email-masked]"  
> Subject: Re: secdir review of draft-ietf-opsec-igp-crypto-requirements
>
> On 9/15/10 4:36 PM, Bhatia, Manav (Manav) wrote:
>> Hi Samuel,
>>
>> Thanks for the review.
>>
>>> another, and requirement status in the elements (perhaps with a
>>> cite to the doc that sets the requirement).  You might separely say
> And the current method is still the right way to do it imho. the doc  
> is
> not intended to impose the requirement on protocol authors, rather to
> point out how requirements would shift in the case of prference for
> another algorithm...
>
>>>
> They were confusing, and detracted from the recomendations.
>
> to cite a particular section that I think underscores this:
>
>   IS-IS implementations SHOULD provide support for the generic
>   cryptographic authentication scheme [RFC5310] and it is our
>   understanding that interoperability considerations will require
>   change to a MUST as operators migrate to this authentication scheme.
>
> which I interpret as:
>
> RFC 5310 states that is-is implementations should implement support  
> for
> the generic cryptographic authentication scheme. If at some future  
> date
> recommendations were to support a key method other than HMAC-MD5  
> then it
> would follow that support for the generic cryptographic authentication
> scheme would become a requirement.
>
> SHOULD- MUST+ makes interpreting that a WTF moment.
>
> that they are not normative language.
>
>>> available.
> this document is focused on operational considerations of exist
> protocols so for example a karp supplied kmp is probably out of scope
> for the document in it's present form.
>
>> _______________________________________________ Ietf mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>>
>

--
"Being the Fun-Police in the global Internet is a thankless - and  
probably futile - task."
  --  R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt")

---

From: Warren Kumari <[email-masked]>
Date: Sun, 19 Sep 2010 13:07:03 -0400

For those following along at home...

W

Begin forwarded message:

> Date: September 19, 2010 10:29:22 AM EDT
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> On Thu, 16 Sep 2010, Bhatia, Manav (Manav) wrote:
> 
>>> In describing each routing protocol's authentication options, it would be helpful to say whether there's any in-band negotiation available.
>> 
>> I am not sure I understand whats being meant by in-band negotiation here?
> 
> Many protocols negotiate which crypto algorithm (or even more generic security mechanism) to use.  Those negotiations, if done poorly, can be subject to downgrade attacks.
> 
> Given how common security negotiation is, it's worthwhile to point out whether or not each of these protocols do it or whether they depend entirely on static configuration of each endpoint.
> 
> -- Sam