Re: [OPSEC] minutes part 2

["Vishwas Manral" <[e-mail]>]

Hi Ran,

Thanks that clarifies the first draft atleast in my mind. :)

The second draft is about defining the set of algorithms for IGP just
like RFC4835 does for IPsec. This is to provide minimal set of
cryptographic algorithms to be supported for basic interoperability.

With the additional support of new crypto algorithms into IGP's there
are now multiple crypto algorithms defined for the same IGP. Also as
we move forward and security vulnerabilities are found in
cryptographic algorithms, the algorithm support for Routing Protocols
can be changed without change of the base protocol RFC's.

The issue was seen in IPsec case where we had to move from DES to
3-DES to AES-CCM. Based on the reccomendations of the IETF on various
crypto algorithms, we have recommended cryptographic algorithms as
MUST- to SHOULD +  etc to also give a sense of direction.

Thanks,
Vishwas

On Tue, Dec 16, 2008 at 6:19 PM, R Atkinson <[e-mail]> wrote:
>
> On  16 Dec 2008, at 20:59, Vishwas Manral wrote:
>>
>> No, it is not discussed in the document. The RFC you mention is an
>> Experimental RFC. The draft talks about "Issues with Existing
>> Cryptographic Mechanisms with Routing Protocols". We can discuss the
>> same however (though I would feel it may not exactly fit the draft).
>
> It would be helpful to discuss also, as that is an IGP authentication
> mechanism that we have today and that could be used.  I'm told that
> there is at least one implementation, although I'm unclear on how
> available that implementation might be.
>
>> http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a
>> link to the first page of the discussion. The discussion is a long
>> discussion
>
> Thank you for the URLs.
>
>> We have customers who have asked for the crypto algorithms.
>
> Other than US DoD ?    Very Interesting.
> Are they Enterprise users ?  Service Providers ? other ?
>
> Is this for policy reasons or does a particular threat model
> drive them in that direction ?
>
>> We are implementing this and so is Cisco (this has been brought to
>> your notice in private mails earlier but you still bring the issue).
>
> I do not have such any private emails; they must have been lost in transit.
>
> Thanks for the clarity.  So at least 2 implementations are reported
> to be in progress, and none are available now.  That is useful to
> understand.
>
>> It sounds interesting that you want to know vendors implementing some
>> solutions because we are writing an issues document with already
>> existing mechanisms.
>
> Your assumption is incorrect.
>
> I want to know because the OPsec meeting minutes seemed to suggest
> that someone proposed this WG should recommend SHA mechanisms over
> MD5 mechanisms, and I was not aware of any active work to implement
> any SHA mechanisms.
>
>>> 5:  Claims made by existing IGP authentication documents
>>>>>
>>>>> However if you see most drafts "security considerations" section,
>>>>> they state that using cryptographic authentication is a panicia for all
>>>>> evils.
>>>
>>> I can't find even one RFC or I-D that says anything similar
>>> to "using cryptographic authentication is a panacea for all evils".
>>>
>>> I checked a bunch of documents, which I enumerated in an earlier
>>> email; none contained any such language.
>>>
>>> Which specific document does this ?  and on which page ?
>>
>> Please check the drafts in this page
>> http://www.ietf.org/html.charters/ospf-charter.html .
>> As an example see the first draft in the list it states
>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt
>>
>> Security Considerations
>>
>>  The described technique provides the same level of security as OSPFv2
>>  protocol by allowing LLS data to be authenticated using the same
>>  cryptographic authentication that OSPFv2 uses (see Section 2.5 for
>>  more details).
>>
>>  OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH].
>>  With IPsec, the AH (Authentication Header), ESP (Encapsulating
>>  Security Payload), or both are applied to the entire OSPFv3 payload
>>  including the LLS block.
>
> That does not say either that cryptographic authentication is a panacea
> or that cryptographic authentication is perfect.  So the quote does not
> support your original claim (from the top of Section 5 of my note).
>
> The text you quote above simply says that it provides "the same level of
> security" ... "by using the same cryptographic authentication".   The
> text you quote from that I-D does not even claim that the existing
> cryptographic authentication is a sufficient level of security.  Its
> claims are really quite narrow and quite mild.
>
>> Our aim is to bring forward the issues with the cryptographic
>> mechanisms. The issues with the cryptographic mechanisms are not
>> stated in the base RFC either and I have mentioned this to you
>> clearly.
>
> I quoted the base OSPF RFC to this list earlier today, where that RFC
> indicated that the cryptographic authentication was focused on
> "passive attack" prevention and showed that that RFC did not claim the
> cryptographic authentication to be perfect or to be a panacea.  So the
> OSPF RFC does not support your quoted claim either.
>
>> Because most RFC's draft seem to state something similar to
>> the above.
>
> The actual IGP authentication RFCs and I-Ds (which I did cite)
> do not do so.  They are what users and implementers read when
> studying IGP authentication.
>
> Further, the "examples" you have cited so far do not support your claim
> at the top of this section (Section 5 of my email).
>
> Thank you for the speedy reply.
>
> Yours,
>
> Ran Atkinson
> [e-mail]
>
>
>
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec