[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] OCSP in IKEv2
hi william,
thanks for your response.
the term peer-to-peer is a bit overloaded and you understood it as a way to
run ikev2 between two arbitrary end hosts in the internet. there is indeed a
problem independently of oscp (as we know from various working groups; e.g.,
mobile ip).
in the draft we discussed the corporate network access authentication (which
includes the eap case; section 1.1.3 of <draft-ietf-ipsec-ikev2>). in this
scenario the initiator (road warrior) requests an ocsp response from the
responder. as a more generic use case where both nodes use ocsp section 5.1
of <draft-myers-ipsec-ikev2-oscp-00.txt> was introduced. it, however, does
not say that the two peers need to be arbitrary end hosts.
it could be useful to spend a few words on the raised issue in our draft.
maybe they are also reflected in sufficient detail in your ikev2 security
considerations draft (since they issue has broader scope).
ciao
hannes
> -----Original Message-----
> From: William Dixon [mailto:ietf-wd@v6security.com]
> Sent: Saturday, August 07, 2004 10:31 PM
> To: 'Michael Myers'
> Cc: ipsec@lists.tislabs.com
> Subject: RE: [Ipsec] OCSP in IKEv2
>
> 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
>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec