RE: [Ipsec] OCSP in IKEv2

["William Dixon" <ietf-wd@v6security.com>]

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

The risk is to the initiator of a malicious responder when forced to use
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.

Cheers,
Wm
William Dixon, Founder, Principal Consultant
V6 Security, Inc.

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] 
> On Behalf Of Michael Myers
> Sent: Saturday, August 07, 2004 10:22 AM
> To: ipsec@ietf.org
> Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com
> Subject: [Ipsec] OCSP in IKEv2
> 
> All,
> 
> The intersection of IPSEC with PKI is of recent interest.  
> Towards that dialog, Hannes Tschofenig and I have proposed 
> how OCSP could be used to deliver certificate status in-band 
> to IKEv2.  We were driven first to consider the important use 
> case of EAP (i.e. the Road Warrior) but also considered the 
> Peer-to-Peer case in order to develop a general solution.
> 
> This individual submission I-D can be found at:
> http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os
cp-00.txt
> 
> Two new certificate encoding types are proposed:  OCSP 
> Responder Hash and OCSP Response.  An OCSP Responder Hash is 
> sent in a CERTREQ, computed as trust anchor hashes are 
> computed but sent in a separate CERTREQ.  A corresponding 
> OCSP Response is sent back in its own CERT payload and in the 
> context of the CERT payload carrying the participant's 
> certificate.  That is, an IKEv2 participant sends both its 
> cert and that cert's status in separate CERT payloads.
> 
> Hannes and I look forward to your comments and debate.  I've 
> cross-posted due to intersecting interests but please post 
> comments to the IPSEC list only.
> 
> Michael Myers
> 
> 
> 
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 


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