RE: [Ipsec] OCSP in IKEv2

[Stephen Kent <kent@bbn.com>]

At 1:30 PM -0700 8/7/04, William Dixon wrote:
>Hi Mike, please correct my understanding here if I'm making a mistake. You
>mentioned peer-to-peer applicability which prompted my investigation. The
>summary is that your draft should be more clear about the risks of using
>OCSP inband with IKEv2 in peer-to-peer scenarios, such as not recommend it.
>
>I think using OCSP inband in IKEv2 for peer-to-peer would not be recommended
>- as it is limited by the classic problem of how an IKE initiator knows
>which credential or trust anchor to expect from the responder. There are
>deployment scenarios where this situation is solvable - such as IKE
>negotiation to my own corporate gateway, or generally, any case where I can
>configure an IPsec policy to use a particular CA or root for a given
>destination address/range/etc. But in the open Internet or in general
>peer-to-peer scenarios, I won't know which cert or trust anchor to expect
>from a given destination. I'm not aware of an actual recommendation for
>peer-to-peer IKEv1/2 authentication. We might get a chance to address this
>in the IKEv2 security considerations draft (early stages w/Scott Kelly).

there comments are true in the worst case, but probably not in most cases.

	- The CA that issued the cert to an IPsec device will have to 
be recognized by a peer if the peer will ever be able to validate 
that EE cert. so, an OCSP{ response issued under the auspices of that 
CA will always be something that the peer will be able to evaluate at 
some point in the process.

	- Also, in other than opportunistic communication contexts, 
there is some reason to assume that peers know something about one 
another's PKIs a priori, since there was a need to create appropriate 
SPD entries to identify and authorize one another. so, in that case 
it seems reasonable to expect that useful OCSP responses can selected 
and sent to a peer.

>The risk is to the initiator of a malicious responder when forced to use
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	I have a hard time parsing the text above

>that responder to relay/forward OCSP messages to the backend OCSP server
>(the OCSP responder). I don't see the draft really explains how the proposed
>design notes this should only be used where the IKE initiator is safe from
>IKE responder attacks. And the circumstance where the responder is able to
>take advantage of the IKE initiator's limited knowledge of what credential
>to expect.
>
>>From RFC 2560:
>    All definitive [OCSP] response messages SHALL be digitally signed. The
>key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
><snip>
>
>Clearly if I'm negotiating IKEv2 with a random Internet peer, my use of OCSP
>inband with IKEv2 can allow the initiator to accept any certificate from any
>pre-configured trust anchor. If we follow the server-auth SSL deployment
>model for client certs it could be any of 130+ root CAs, or whatever someone
>has been able to stuff into their trusted root store. If we don't depend
>upon pre-configured roots, then why would we need to use OCSP ? If you would
>suggests that we depend on PKI-enabled DNS for hints about which credential
>to expect, then please mention this in your draft. Though for peer-to-peer
>scenarios, it may be an insurmountable barrier to update any ISP's DNS that
>I'm connected to with my client PKI info. In fact I probably don't want to
>do that if I have several certs from issuers/roots that would identify my
>business relationships.

the PKI model used in SSL is an especially bad one for IPsec. that 
model is directed toward supporting a very large, arbitrary set of 
clients contacting a (large, but much smaller) set of servers and 
engaging in a one-way authentication exchange, with them. It relies 
on pre-configuration of TTP CAs by vendors, which effectively 
precludes use of important PKI features like name constraints. it 
also entrenches the TTP CAs as service providers.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec