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

From: Samuel Weiler <[email-masked]>
Date: Wed, 15 Sep 2010 14:13:53 -0400 (EDT)

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

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 16 Sep 2010 11:31:40 -0700

On 9/15/10 4:36 PM, Bhatia, Manav (Manav) wrote:
> 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.

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

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

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.

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

that they are not normative language.

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

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.

> Just making sure that folks don't miss this! :)
> 
>> 
> Sure, will do.
> Cheers, Manav
> _______________________________________________ Ietf mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 16 Sep 2010 05:06:00 +0530

Hi Samuel,

Thanks for the review.
 
> 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.

> 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 

I am not sure I understand whats being meant by in-band negotiation here?

Sure, will do.

Cheers, Manav

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 19 Sep 2010 10:29:22 -0400 (EDT)

> I am not sure I understand whats being meant by in-band negotiation 

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 19 Sep 2010 23:12:01 +0530

> entirely on static configuration of each endpoint.

All the protocols covered in this document provide the Key ID that's carried in the protocol packets that's used by the receiving end to authenticate the packet. So there is no exchange of crypto algorithms, etc that's done. We can mention this in the next revision.

Cheers, Manav