Subject: Re: [ipsec] Nested SAs in 2401bis

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 2004 16:21:11 -0400

At 7:32 PM +0100 8/4/04, Michael Roe wrote:
>Steve, Karen,
>
>I've been trying to understand how nested SAs work in 2401bis,
>now that it doesn't have SA bundles. I think it would make the
>document easier to understand if there was a worked example of
>an SPD with nested SAs.

thanks for constructing an example. we'll incorporate it, with some
minor changes, into an appendix.

>Here's how I *think* it's suppsoed to work. Suppose we have a
>transport mode SA from A to C, which is carried over a tunnel
>mode SA from A to B. (e.g. A is a laptop on the public internet,
>B is a firewall that protects a corporate network, C is a server
>on the corporate network that demands end-to-end authentication
>of A; alternatively, A is a MIPV6 mobile node and B is a home
>agent)
>
>
>+---+     +---+  +---+
>| A |=====| B |  | C |
>|   |------------|   |
>|   |=====|   |  |   |
>+---+     +---+  +---+
>
>Then A's SPD looks like this:
>
>    local remote protocol action
>1  C     A      *        BYPASS

I would change this entry to make the protocol field = ESP, to keep it
tightly constrained, and to make it clear that what we want is to loop back
packets that have already had ESP applied.

>2  A     C      ICMP,ESP,IKE PROTECT(ESP, tunnel, A to B, auth+conf)
>3  A     C      *        PROTECT(ESP, transport, auth)
>4  A     B      ICMP,IKE BYPASS
>
>A's unprotected-side forwarding table is set so that outbound packets destined
>for C are looped back to the protected side. A's protected side 
>forwarding table
>is set so that inbound ESP packets are looped back to the unprotected side.
>
>An outbound TCP packet from A to C would match rule 3 and have a 
>transport-mode
>header prepended to it. The unprotected-side forwarding table would then loop
>back the packet. The packet is compared against SPD-I (see fig. 2 in 2401bis),
>matches rule 1, and so is allowed back in.

as noted above, if the goal is to bypass ONLY the packets from C that 
are being protected via this nesting, I'd construct a more 
restrictive SPD entry for #1, one that requires the packet to have 
ESP as the declared protocol.

>The packet is compared against the
>SPD for a third time, and this time it matches rule 2, so that it gets a
>tunnel mode header appended to it. This time the forwarding table doesn't
>loop back the packet, because the outer source address is B, so the packet
>goes out onto the wire.
>
>An inbound TCP packet from C to A, wrapped in two ESP headers, would first
>match 2 and have the tunnel mode header removed. The protected-side forwarding
>function would then send it back to the unprotected side.

Need to say why the protected side forwarding table loops it back,
e.g., because the protocol is ESP, indicative of nesting.

>It is compared against
>SPD-O (see fig. 3 in 2401bis) and found to match rule 1, so it is allowed back
>out. The packet is compared against the SPD for the third time. This time it
>matches rule 3 and has the transport-mode ESP header removed. The forwarding
>fucntion passes it up to the next layer, because it isn't an ESP packet.
>
>Is this right?

yes. as I said, I'd make a minor change to the first SPD entry, and I'd
add in a description of forwarding table entries on each side to make it
as clear as possible, but this is a good example and I agree that it will
help explain how to achieve nesting.

>
>Thanks,
>Mike
>
>PS. It would appear that in a high-assurance implementation, the 
>forwarding function
>on the unprotected side is part of the trusted computing base. It is 
>trusted to loop
>back packets destined for C; if it doesn't, they won't get the 
>second layer of crypto
>applied to them and will be visible to an eavesdropper on the link 
>between A and B.

agreed.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 7 Aug 2004 10:21:32 -0700

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-oscp-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

---

From: "William Dixon" <[email-masked]>
Date: Sat, 7 Aug 2004 13:30:35 -0700

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Michael Myers
> Sent: Saturday, August 07, 2004 10:22 AM
> To: [email-masked]
> 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.
> 
> 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 
> cross-posted due to intersecting interests but please post 
> comments to the IPSEC list only.
> 
> Michael Myers
> 
> 
>

---

From: "William Dixon" <[email-masked]>
Date: Sat, 7 Aug 2004 15:45:54 -0700

To clarify after discussing with Michael about this. My comments were based
on two concerns for the authors:

1. does adding OCSP inband w/in IKEv2 create a weakness in the IKE
authentication properties when certificate status is decided out of band
(with OCSP, to avoid the CRL vs. OCSP points) My comments below were focused
particularly on usage in peer-to-peer scenarios. Which I now realize also
apply to CRLs inband. 

Rereading the draft again, it's pretty clear. The OCSP response is sent at
the same time the responders CERT payload is provided. But I'm wondering why
there is a "MUST not ignore the OCSP response payload" statement in the
draft. I don't think an error message MUST be sent. Generally IKEv2-14
authentication errors or other failures do not require error notifications
to the peer:
   "An endpoint MUST conclude that the other endpoint has failed only when
   repeated attempts to contact it have gone unanswered for a timeout
   period or when a cryptographically protected INITIAL_CONTACT
   notification is received on a different IKE_SA to the same
   authenticated identity."

2. what use cases (scenarios) are compelling for the WG to take up this work
? Specifically what are the IKEv2 peer-to-peer scenarios ?

After talking with Michael about this, it was apparent that any time the
OCSP responder is not directly reachable by one of the peers and is
reachable through the peer, OCSP inband within IKEv2 would be necessary. We
came up with a few corporate client-server scenarios easily. The use of PKI
for peer-to-peer authentication & consequent authorization is more the
question, and is not specifically related to using OCSP or CRLs inband. I
would imagine then there is a 1:1 mapping with scenarios where CRLs have to
be passed inband. So the answer to #2 may be irrelevant, it's more the issue
that the IKEv2 standard should provide equal inband support for standard
PKIX WG certificate revocation/status checking mechanisms. I don't know why
this was omitted from IKEv2 earlier or if it was just lack of a proposal.
Perhaps the authors familiar with OCSP deployment can identify unique OCSP
inband scenarios - clearly whenever CRLs get large would be one, and
potentially the must-have scenario, as there is not yet a proposal for IKE
MTU detection & fragmentation avoidance.

So #2 becomes a political or process question - do we adopt OCSP support in
IKEv2 at this point, advance this draft as an addendum, or maybe incorporate
it into the PKI4IPsec work.

Hope this helps.
Cheers,
Wm

> On Behalf Of William Dixon
> Sent: Saturday, August 07, 2004 1:31 PM
> To: 'Michael Myers'
> Cc: [email-masked]
> 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.
> 
> - 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
>    -- 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
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Michael Myers
> > 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.
> > 
> Responder Hash 
> > participant's certificate.  That is, an IKEv2 participant 
> sends both 
> > its cert and that cert's status in separate CERT payloads.
> >

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 9 Aug 2004 16:31:53 -0700

All

BTW, the ADs have agreed this I-D will be placed onto the Standards
Track, subject to resolution of comments.  I am sure there are folks out
there with an opinion.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Michael Myers
Sent: Saturday, August 07, 2004 10:22 AM
To: [email-masked]
Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com
Subject: [Ipsec] OCSP in IKEv2

All,

Michael Myers

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 10 Aug 2004 09:45:30 -0700

William,

I have no issue with reducing the normative strength of this clause (1)
so long as we directly address the case.  The question is what does a
IKEv2 responder send back should it be unable to comply with an
initiator's request for in-band OCSP?

To your second point (2), it has been established that IKEv2 is too far
along in its consensus formation for the degree of reset direct
inclusion of this proposal would cause.  Russ' direction is equally
unambiguous regarding PKI4IPSEC:  OCSP for IKEv2 will be an individual
submission I-D gated onto the Standards Track, subject to comments.

Which brings us back to the first point:  improving the I-D based on
comments.  These days making PKI work translates in part to knob
reduction.  I interpret this into a reduction of optional protocol
elements and crisp SHALL/SHALL NOT requirements instead of SHOULD or
MAY.

That said, it is useful in some instances to be accommodative.  I am not
yet convinced this is such an instance.  Failing to include an OCSP
Response is not an all-out failure as you cite from IKEv2.  The
responder may simply be unable to provide the requested service.  That
does not mean it has failed in some fundamental way.

But neither am I expert in IPSEC's current state of deployment.  I
remain open to debate on this point but as I see it today, a responder
unable to satisfy an initiator's request for in-band OCSP should say so,
if only in an error message.  The initiator can then retry with a
reduced level of assurance if it so chooses.

Mike

-----Original Message-----
From: William Dixon
Sent: Saturday, August 07, 2004 3:46 PM

(1) . . . I'm wondering why there is a "MUST not ignore the OCSP
response payload" statement in the draft. I don't think an error message
MUST be sent [because IKEv2 says] "An endpoint MUST conclude that the
other endpoint has failed only when repeated attempts to contact it have
gone unanswered for a timeout period or when a cryptographically
protected INITIAL_CONTACT notification is received on a different IKE_SA
to the same authenticated identity."

(2) . . . do we adopt OCSP support in IKEv2 at this point, advance this
draft as an addendum, or maybe incorporate it into the PKI4IPsec work

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 10 Aug 2004 18:41:45 -0700

At 4:31 PM -0700 8/9/04, Michael Myers wrote:
>Track, subject to resolution of comments.

Such a statement seems wildly premature for a -00 document.

To date, there has been nearly zero interest from anyone in the IPsec 
vendor community for in-band OCSP. Further, I am unaware of any deman 
from the VPN user community for this. Having a standards-track 
document will lead some to think that vendors are supposed to support 
this. Given that there is no actual need for handling OCSP in IPsec, 
the document should not move on to standards track; Experimental 
status is fine.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 11 Aug 2004 16:49:53 -0400

Experimental doesn't seem to fit; it seems to me more of a
*limited-applicability* standards track document..

I can see two obvious use cases for tunneling OCSP through IKE:

 1) the "PKI infrastructure servers inside the security perimeter"
    case discussed at some length within the pki4ipsec working group.

 2) when transport mode ipsec is used and you need to talk to the OCSP
    server itself.

Both of these break a possible chicken-and-egg dependancy cycle (need
IPsec to speak OCSP; need OCSP to establish IPsec SA).

							- Bill

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Aug 2004 15:16:31 -0700

>*limited-applicability* standards track document..

That might be considered hair-splitting for the NEWTRK Working Group.

>I can see two obvious use cases for tunneling OCSP through IKE:

Um, the proposal has nothing to do with tunneling OCSP through IKE: 
it covers how to pass OCSP responses from one peer to another. Thus, 
in order for this proposal to be useful, the replying party has to 
have a fresh OSCP response about itself to hand to the querying party.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 02:17:28 -0500

Your I-D actually cleared up some confusion in the KRB WG over the
meaning of "OCSP tunnelling" and led to achievement of consensus on how
to add support for OCSP to PKINIT.  Thank you.

Nico
-- 

On Sat, Aug 07, 2004 at 10:21:32AM -0700, Michael Myers wrote:
> pki4ipsec mailing list
> [email-masked]
> http://honor.icsalabs.com/mailman/listinfo/pki4ipsec

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 02:25:01 -0500

> the document should not move on to standards track; Experimental 

Let me confirm that there is interest in this general use of OCSP: that
each peer that can sends OCSP response(s) for *its* certificate.

Michael's I-D helped clear up some confusion about "OCSP tunnelling" in
the KRB WG; "OCSP tunnelling" is not a good way to describe this as
there's no exchange of OCSP _requests_ and responses, just responses.

Think of this as a way of sending a CRL in-band but not in the cert,
with the benefit that the overall size of an OCSP response for one cert
is, practically speaking, constant, as opposed to the practically
unbounded size of CRLs.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 02:30:43 -0500

> >I can see two obvious use cases for tunneling OCSP through IKE:

"tunnelling" is confusing here as only OCSP responses would be
exchanged, not requests.

> have a fresh OSCP response about itself to hand to the querying party.

Bingo.  And that is where the payoff is as this proposal maximizes the
use of cached OCSP requests because the user of a cert, not its peers,
is the one that gets the OCSP responses for its cert.

Cheers,

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 2004 11:35:20 -0400

>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

>do that if I have several certs from issuers/roots that would identify my

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