Re: [OPSEC] minutes part 2

[R Atkinson <[e-mail]>]

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