[anonsec] SAB without connection latching

Post by Sam Hartman
The applicability statement makes the claim that BTNS protects against
on-path attacks after the connection is established. In order to do

^^
off-path, not on-path. If the applicability statement says "on-path"
then that's got to be a mistake.

And passive attacks.

To protect against more active attacks requires additional features,
such as connection latching and channel binding, or, where workable,
leap-of-faith.

Nico
--

Sam Hartman

2005-12-04 21:42:38 UTC

Nicolas> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman

Post by Sam Hartman
The applicability statement makes the claim that BTNS protects
against on-path attacks after the connection is established.
In order to do

Nicolas> ^^ off-path, not on-path. If the applicability
Nicolas> statement says "on-path" then that's got to be a mistake.

no, I'm fairly sure that protecting against on-path attacks after the
connection is established is a goal of SAB.

The entire point of my message is that in order to do that we need to
do something more complicated than the most trivial possible vision of
SAB.

Nicolas Williams

2005-12-05 00:11:08 UTC

Post by Sam Hartman
Nicolas> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman

Post by Sam Hartman
The applicability statement makes the claim that BTNS protects
against on-path attacks after the connection is established.
In order to do

Nicolas> ^^ off-path, not on-path. If the applicability
Nicolas> statement says "on-path" then that's got to be a mistake.
no, I'm fairly sure that protecting against on-path attacks after the
connection is established is a goal of SAB.
The entire point of my message is that in order to do that we need to
do something more complicated than the most trivial possible vision of
SAB.

Oh, right, "other on-path attacks after key exchange."

Yes, I don't see how that can work w/o connection latching and/or
leap-of-faith.

Nico
--

Joe Touch

2005-12-06 17:05:46 UTC

Post by Sam Hartman
The applicability statement makes the claim that BTNS protects against
on-path attacks after the connection is established. In order to do

^^
off-path, not on-path. If the applicability statement says "on-path"
then that's got to be a mistake.

It's not a mistake.

Post by Nicolas Williams
And passive attacks.
To protect against more active attacks requires additional features,
such as connection latching and channel binding, or, where workable,
leap-of-faith.
Nico

That seems true for any IPsec connection, e.g., in 2401bis when the PAD
changes during a connection. I have been presuming 'connection latching'
- - where the PAD cannot change during a connection and where BTNS would
update the PAD once the connection is established.

Leap-of-faith addresses something different - where the PAD entries
persist between a series of connections, or are shared among connections
to the same endpoint.

Joe

Sam Hartman

2005-12-06 17:15:47 UTC

Joe> presuming 'connection latching' - where the PAD cannot change
Joe> during a connection and where BTNS would update the PAD once
Joe> the connection is established.

Joe, it's not quite that simple. Please take a look at the definition
of the PAD; it is quite complicated. Also, propose a mechanism for
determining how long a connection exists.

Then propose updates to Nico's mechanism to support this once he posts
our notes.

I do believe there is a solution in there somewhere but I also believe
you are glossing over critical details necessary to make it actually
work.

Joe Touch

2005-12-06 17:24:01 UTC

Post by Sam Hartman
Joe> presuming 'connection latching' - where the PAD cannot change
Joe> during a connection and where BTNS would update the PAD once
Joe> the connection is established.
Joe, it's not quite that simple. Please take a look at the definition
of the PAD; it is quite complicated. Also, propose a mechanism for
determining how long a connection exists.
Then propose updates to Nico's mechanism to support this once he posts
our notes.
I do believe there is a solution in there somewhere but I also believe
you are glossing over critical details necessary to make it actually
work.

The details I'm glossing over are the ones I'm presuming exist for
conventional IPsec use.

Otherwise, what prevents the PAD from changing during a connection, and
the resulting authentication for an endpoint from being in flux?

If these details aren't already there, then there is certainly a large
amount of work to be done - but it is not BTNS-specific.

Joe

Sam Hartman

2005-12-06 17:30:50 UTC

Joe> Otherwise, what prevents the PAD from changing during a
Joe> connection, and the resulting authentication for an endpoint
Joe> from being in flux?

1) The PAD is assumed to be more or less static except under the
control of the admin.

2) It *can* change and the authentication can be in flux. This isn't
really a problem for traditionnal IPsec.

--Sam

Joe Touch

2005-12-06 17:48:14 UTC

Post by Sam Hartman
Joe> Otherwise, what prevents the PAD from changing during a
Joe> connection, and the resulting authentication for an endpoint
Joe> from being in flux?
1) The PAD is assumed to be more or less static except under the
control of the admin.

I didn't find any discussion of that in 2401bis. That seems like a
substantial security issue (as per below).

Post by Sam Hartman
2) It *can* change and the authentication can be in flux. This isn't
really a problem for traditionnal IPsec.

That would allow hijacking, just as with BTNS. An existing SA could
could be torn down or modified by an IKE authenticated in a different
way than the original SA. That would then permit hijacking.

Joe

Nicolas Williams

2005-12-06 17:32:04 UTC

The details I'm glossing over are the ones I'm presuming exist for
conventional IPsec use.
Otherwise, what prevents the PAD from changing during a connection, and
the resulting authentication for an endpoint from being in flux?
If these details aren't already there, then there is certainly a large
amount of work to be done - but it is not BTNS-specific.

The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

Stephen Kent

2005-12-07 14:50:06 UTC

The details I'm glossing over are the ones I'm presuming exist for
conventional IPsec use.
Otherwise, what prevents the PAD from changing during a connection, and
the resulting authentication for an endpoint from being in flux?
If these details aren't already there, then there is certainly a large
amount of work to be done - but it is not BTNS-specific.

The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

Yes, that is a valid concern relative to the current spec.

When I suggested text (a few months ago) for a simple modification to
the PAD to accommodate BTNS-style functionality, I believe I noted
the requirement that PAD entries for BTNS peers must be checked to
avoid overlap with both BTNS and non-BTNS peers. I may be able to
find that text again, if needed.

Steve

Nicolas Williams

2005-12-07 14:54:08 UTC

Post by Nicolas Williams
The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

Yes, that is a valid concern relative to the current spec.
When I suggested text (a few months ago) for a simple modification to
the PAD to accommodate BTNS-style functionality, I believe I noted
the requirement that PAD entries for BTNS peers must be checked to
avoid overlap with both BTNS and non-BTNS peers. I may be able to
find that text again, if needed.

Keep in mind Joe's point that this is a problem for IPsec even without
BTNS in the picture. A PAD entry that allows road warriors access to
dynamically allocated addresses will allow road warriors to steal each
other's traffic in the same way as we've discussed could happen with
BTNS.

Nico
--

Nicolas Williams

2005-12-07 16:37:36 UTC

Post by Nicolas Williams
The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

Yes, that is a valid concern relative to the current spec.
When I suggested text (a few months ago) for a simple modification to
the PAD to accommodate BTNS-style functionality, I believe I noted
the requirement that PAD entries for BTNS peers must be checked to
avoid overlap with both BTNS and non-BTNS peers. I may be able to
find that text again, if needed.

Also, creating {IP, ID} bindings through a dynamic PAD is a DoS
attack vector and key rollover issues, as discussed at IETF64.

Addressing the DoS problem requires cooperation from other
infrastructure (e.g., DHCP servers) or idle timeouts (as discussed at
IETF64, but also through reference counts on binding PAD entries
representing references from outstanding connection-latched packet
flows, as discussed on the list recently). Addressing the key rollover
issues requires KE extensions.

The Solaris connection latching approach seems like a trade-off by
creating such bindings only per-connection 5-tuples -- thus,
essentially, 7-tuples: {src IP, dst IP, src ID, dst ID, protocol, src
port, dst port} -- at the cost of possibly exposing applications that
use multiple connections between two peers. (Bill surely will correct
me if I'm wrong.)

Nico
--

Stephen Kent

2005-12-07 22:05:51 UTC

Post by Nicolas Williams
The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

Yes, that is a valid concern relative to the current spec.
When I suggested text (a few months ago) for a simple modification to
the PAD to accommodate BTNS-style functionality, I believe I noted
the requirement that PAD entries for BTNS peers must be checked to
avoid overlap with both BTNS and non-BTNS peers. I may be able to
find that text again, if needed.

I don't think this discussion has provided a good example to
illustrate the problem in question. I'm guessing that the concern
begins with the notion that one needs to dynamically update or create
a PAD entry to accommodate road warriors. However, there has been no
discussion in IPsec to suggest that dynamic PAD entries are needed to
support road warriors.

A PAD entry might identify the set of all road warriors for a company
by a wild card name, e.g., *@bbn.com. The authorization data for the
entry might say that these individuals have certs that can be
validated using the CA cert for BBN. The entry would also specify
that the IKE ID (not the road warrior's source address) be used for
SPD matching. The SPD entry for these folks would be tagged with the
name. Section 4.4.1.1 specifically gives the road warrior case as a
motivation for the use of names to specify SPD entries, and says how
to take the IP address of the road warrior (as the initiator) and use
it as the remote address for the SPD entry (in a sort of PFP
fashion). This should avoid the hijacking concern alluded to above.

Mike Richardson discussed how 2401 implementations (the PAD concept
was not part of the old standard) supported road warriors, in the
BTNS meeting at IETF64. Mike, how do you envision using a
PAD-equipped IPsec to accommodate road warriors? Do you see a need
for dynamic PAD entries?

Steve

Sam Hartman

2005-12-07 23:20:51 UTC

Stephen> A PAD entry might identify the set of all road warriors
Stephen> for a company by a wild card name, e.g., *@bbn.com. The
Stephen> authorization data for the entry might say that these
Stephen> individuals have certs that can be validated using the CA
Stephen> cert for BBN. The entry would also specify that the IKE
Stephen> ID (not the road warrior's source address) be used for
Stephen> SPD matching. The SPD entry for these folks would be
Stephen> tagged with the name. Section 4.4.1.1 specifically gives
Stephen> the road warrior case as a motivation for the use of
Stephen> names to specify SPD entries, and says how to take the IP
Stephen> address of the road warrior (as the initiator) and use it
Stephen> as the remote address for the SPD entry (in a sort of PFP
Stephen> fashion). This should avoid the hijacking concern alluded
Stephen> to above.

It's exactly this situation that gives rise to the concern.

Think about what happens when two peers both identified by the same
PAD entry and both using the same name to select SPD entries (name
matching not IP matching) claim the same IP address. What happens
when just as an SA expires a different peer claims the same remote IP
address?

Stephen Kent

2005-12-08 16:22:52 UTC

Post by Sam Hartman
Stephen> A PAD entry might identify the set of all road warriors
Stephen> authorization data for the entry might say that these
Stephen> individuals have certs that can be validated using the CA
Stephen> cert for BBN. The entry would also specify that the IKE
Stephen> ID (not the road warrior's source address) be used for
Stephen> SPD matching. The SPD entry for these folks would be
Stephen> tagged with the name. Section 4.4.1.1 specifically gives
Stephen> the road warrior case as a motivation for the use of
Stephen> names to specify SPD entries, and says how to take the IP
Stephen> address of the road warrior (as the initiator) and use it
Stephen> as the remote address for the SPD entry (in a sort of PFP
Stephen> fashion). This should avoid the hijacking concern alluded
Stephen> to above.
It's exactly this situation that gives rise to the concern.
Think about what happens when two peers both identified by the same
PAD entry and both using the same name to select SPD entries (name
matching not IP matching) claim the same IP address. What happens
when just as an SA expires a different peer claims the same remote IP
address?

Sam,

You ask what happens if an SA (for a road warrior) expires and
different peer claims the same remote IP address. It is not clear
that there is any point in the re-key process that makes this a
problem, per se. I think the real question is whether we check to
ensure that we don't create two SAs with different peers but the same
selector sets, when a child SA is created, in general. (Assume that
the SAs in question have the remote ID address asserted by a road
warrior, but the local IP address, protocol, and port fields are all
ANY, a not-unreasonable SPD entry for such users.)

If we allowed such parallel, identical SAs (from a selector
perspective) we have a serious problem in general, at least for
SG/BITW implementations. This is because outbound traffic to either
remote user from any host at the enterprise net would not be able to
be mapped unambiguously to the right SA. So, I assume that a second
user cannot have caused a new SA to be created with the same remote
address as the first user, so long as an SA exists for the first
remote user who asserted the address in question.

Note that 4301 (section 4.1) mandates support for multiple SAs with
the same selectors between the SAME pair of IKE peers. The motivation
for allowing multiple SAs between the same set of IKE peers is to
allow use of different SAs for QoS, without making QoS an explicit
selector value. This requirement was added because implementations
often did not allow duplicate SAs to be created under any
circumstances, and this was an explicit exception. So I think it is
reasonable to assume that an IPsec implementation will not, in
general, allow a second SA to be created with he same selector
values, if the peer for the second SA is different from that of the
extant SA.

To the best of my recollection, nobody ever raised the issue of
allowing multiple SAs with the same set of selector values but
terminating at different peers. One might imagine this would be a way
to support load sharing or fast fail-over between one SG at one site
and two of more SGs at a different site. If each peer is individually
identified in the PAD, and thus presumed to be authorized for the
same address space, then this would seem to be safe. However, if we
create a PAD entry for a class of users, as in my road warrior
example, and we don't want them to be able to assert overlapping
ownership for the same address space (for obvious reasons), then we
would want to prohibit creation of concurrent SAs with identical
selector values, terminating at different peers. I think this
behavior has been the default in most implementations, based on the
discussions that led to the text in 4.1 (re support of multiple SAs
for QoS support), although I admit that it is not clearly noted in
the RFC.

Steve

Nicolas Williams

2005-12-08 17:48:20 UTC

Post by Stephen Kent
You ask what happens if an SA (for a road warrior) expires and
different peer claims the same remote IP address. It is not clear
that there is any point in the re-key process that makes this a
problem, per se. I think the real question is whether we check to
ensure that we don't create two SAs with different peers but the same
selector sets, when a child SA is created, in general. (Assume that
the SAs in question have the remote ID address asserted by a road
warrior, but the local IP address, protocol, and port fields are all
ANY, a not-unreasonable SPD entry for such users.)

Now the real question is what happens at SA expiration time.

The same mechanism that you describe for protecting road warriors
can be used to protect BTNS nodes...

...but like BTNS the issue that comes up is: can an attacker sneak in by
preventing SA re-keying and then establishing a new SA with the attacker
instead of the victim as one end-point and with the same selectors as
the previous SAs. If so, then IPsec has a problem.

Solutions based on persisting an {IP, ID} binding post-SA expiration
create problems of their own, as discussed at Vancouver and on the list
(how to know when to remove such a binding, dynamic address pool
exhaustion DoS attacks, key rollover in the BTNS case).

Solutions based on persisting a "7-tuple" (5-tuple + IDs) binding for
open connections (incuding BSD socket UDP "connections") create problems
for applications that use multiple connections between two peers.

Nico
--

Stephen Kent

2005-12-08 18:24:25 UTC

If re-keying makes use of the IKE SA from which the child was
created, then I don't think anyone else can "sneak in." if the IKE SA
has been deleted, then we have an ambiguous case, because 4301, like
2401, does not say how to locate an IKE peer when an outbound SA
needs to be created.

Post by Nicolas Williams
Solutions based on persisting an {IP, ID} binding post-SA expiration
create problems of their own, as discussed at Vancouver and on the list
(how to know when to remove such a binding, dynamic address pool
exhaustion DoS attacks, key rollover in the BTNS case).

I'd rather if we not transform "persist" into a transitive verb :-).

Post by Nicolas Williams
Solutions based on persisting a "7-tuple" (5-tuple + IDs) binding for
open connections (incuding BSD socket UDP "connections") create problems
for applications that use multiple connections between two peers.

Note that if the pair of peers (gee, that has a nice ring to it) is
the same, multiple SAs are OK, and MUST be supported as per 4301, so
this case ought not be a problem.

Steve

Nicolas Williams

2005-12-08 20:08:30 UTC

Post by Nicolas Williams
Now the real question is what happens at SA expiration time.
The same mechanism that you describe for protecting road warriors
can be used to protect BTNS nodes...
...but like BTNS the issue that comes up is: can an attacker sneak in by
preventing SA re-keying and then establishing a new SA with the attacker
instead of the victim as one end-point and with the same selectors as
the previous SAs. If so, then IPsec has a problem.

This does not address DoS attacks aimed at preventing re-keying.

I'd rather if we not transform "persist" into a transitive verb :-).

Sigh.

Nico
--

Sam Hartman

2005-12-08 22:48:17 UTC

Stephen> The rest of the paragraph just said that we don't specify
Stephen> how to locate an IKE peer when creating an IKE SA in
Stephen> general. It seems hard to characterize the DoS
Stephen> vulnerability of an unspecified mechanism.

I don't think outbound SAs are where we should be focusing our
thoughts. If I'm going to try and attack this mechanism I'm going to
try and cause dead peer detection to delete the SA or prevent rekey of
the IKE SA. Then I'm going to try and initiate an IKE SA of my own
and create child SAs that are interesting. I don't see how the
outbound peer selection matters. Once child SAs are created, IKE is
no longer involved.

Stephen Kent

2005-12-08 23:28:55 UTC

Post by Sam Hartman
Stephen> The rest of the paragraph just said that we don't specify
Stephen> how to locate an IKE peer when creating an IKE SA in
Stephen> general. It seems hard to characterize the DoS
Stephen> vulnerability of an unspecified mechanism.
I don't think outbound SAs are where we should be focusing our
thoughts. If I'm going to try and attack this mechanism I'm going to
try and cause dead peer detection to delete the SA or prevent rekey of
the IKE SA. Then I'm going to try and initiate an IKE SA of my own
and create child SAs that are interesting. I don't see how the
outbound peer selection matters. Once child SAs are created, IKE is
no longer involved.

I noted outbound SA creation because the SG might be the peer that
would try to initiate the re-key, if the timer or traffic volume
triggers fire there first.

If the re-key trigger occurs at the road warrior, it can use the
(parent) IKE SA for re-key and we are just as secure as what I noted.

it is not true that the IKE SA is not relevant after a child SA is
created. Additional CREATE_CHILD_SA payloads are sent over the IKE
SA, and thus that SA can be used for re-key, without the overhead of
a a new IKE SA being created.

Steve

Sam Hartman

2005-12-09 02:37:46 UTC

Post by Sam Hartman
I don't think outbound SAs are where we should be focusing our
thoughts. If I'm going to try and attack this mechanism I'm
going to try and cause dead peer detection to delete the SA or
prevent rekey of the IKE SA. Then I'm going to try and
initiate an IKE SA of my own and create child SAs that are
interesting. I don't see how the outbound peer selection
matters. Once child SAs are created, IKE is no longer
involved.

Stephen> I noted outbound SA creation because the SG might be the
Stephen> peer that would try to initiate the re-key, if the timer
Stephen> or traffic volume triggers fire there first.

Stephen> If the re-key trigger occurs at the road warrior, it can
Stephen> use the (parent) IKE SA for re-key and we are just as
Stephen> secure as what I noted.

Again, we are talking about rekey of the IKE SA, not rekey of the
child SAs. I agree with you that if the IKE SA is still alive that
there is an obvious secure behavior to implement: do not let child SAs
from one peer replace child SAs from another peer.

Stephen> it is not true that the IKE SA is not relevant after a

Sorry, what I meant hear is that IKE and thus the peer selection
algorithm are not important for the lifetime of a particular child SA
once that child SA is created. The IKE process is only invoked to
create new SAs; traffic will flow over existing SAs without
involvement of IKE. If an attacker can create a situation where only
the attackers' child SAs exist, then for the life of those SAs,
traffic selected by the SPD will flow over those SAs.

--Sam

Stephen Kent

2005-12-09 14:39:41 UTC

Post by Sam Hartman
...
Again, we are talking about rekey of the IKE SA, not rekey of the
child SAs. I agree with you that if the IKE SA is still alive that
there is an obvious secure behavior to implement: do not let child SAs
from one peer replace child SAs from another peer.

Agreed.

Post by Sam Hartman
Stephen> it is not true that the IKE SA is not relevant after a
Sorry, what I meant hear is that IKE and thus the peer selection
algorithm are not important for the lifetime of a particular child SA
once that child SA is created. The IKE process is only invoked to
create new SAs; traffic will flow over existing SAs without
involvement of IKE. If an attacker can create a situation where only
the attackers' child SAs exist, then for the life of those SAs,
traffic selected by the SPD will flow over those SAs.

Agreed, but in order for the attacker to cause his SA to replace the
SA in question, the attacker has to go through the SA creation
process. I was just exploring both sides of that process, for
completeness.

I also was noting that, in practice, there are a number of parameters
in the system that have to align just right to allow peer-B to create
an SA that replaces the SA of peer-A, in the example context we are
discussing.

Note that this problem could, in principle, arise in other cases, not
just for road warriors. Thne heart of the vulnerability is that we
allow wild card PAD and SPD entries, an essential feature to make
access control manageable. If two (or more) peers identified in the
PAD have child SA constraints that overlap in name spaces or address
space, then it is always possible for different peers to establish
SAs that, at least serially in time, employ the same selector sets. A
vendor could offer a PAD/SPD checker utility to alert admins to this
potential problem, to help avoid configuration errors that create
this situation unintentionally (as opposed to as a side effect of
what the admin considers to be a reasonable way to configure the
databases).

The inclusion of the peer ID in the SPD-S would prevent the hijacking
concern in the case of a re-key when the corresponding IKE SA is not
available, but it would not address the time serial problem noted
above, since in that case the old SA might have been deleted. In that
case we are again left with the possibility, noted by Nico, that the
user's connection timeout is long enough to allow the connection to
persist beyond the SA lifetime. In a native host implementation this
problem might be more addressed in other ways, but for an SG or BITW
implementation ...

Steve

Nicolas Williams

2005-12-09 16:05:44 UTC

Post by Stephen Kent
The inclusion of the peer ID in the SPD-S would prevent the hijacking
concern in the case of a re-key when the corresponding IKE SA is not
available, but it would not address the time serial problem noted
above, since in that case the old SA might have been deleted. In that
case we are again left with the possibility, noted by Nico, that the
user's connection timeout is long enough to allow the connection to
persist beyond the SA lifetime. In a native host implementation this
problem might be more addressed in other ways, but for an SG or BITW
implementation ...

Yes, it's difficult to see a solution for SGs or BITW -- they're too far
removed from the actual applications to know whethere packet flows are
outstanding. Of course, they could watch TCP (and SCTP) traffic and
apply the kinds of heuristics that NAT boxes do, with the same degree of
satisfaction, no doubt.

Native mode can do much better -- by cooperating with the ULPs (which in
turn cooperate with the applications), native IPsec can know exactly
when said flows are active or gone. Connection latching takes advantage
of this.

Nico
--

Stephen Kent

2005-12-08 20:59:08 UTC

This does not address DoS attacks aimed at preventing re-keying.

To what part of the paragraph you cited does this observation apply?

It would seem that use of an existing IKE SA for re-key is as
resistant to a DoS attack as any IKE SA after it is established.

The rest of the paragraph just said that we don't specify how to
locate an IKE peer when creating an IKE SA in general. It seems hard
to characterize the DoS vulnerability of an unspecified mechanism.

Steve

Nicolas Williams

2005-12-08 22:50:24 UTC

Post by Stephen Kent
If re-keying makes use of the IKE SA from which the child was
created, then I don't think anyone else can "sneak in." if the IKE SA
has been deleted, then we have an ambiguous case, because 4301, like
2401, does not say how to locate an IKE peer when an outbound SA
needs to be created.

This does not address DoS attacks aimed at preventing re-keying.

To what part of the paragraph you cited does this observation apply?

The first sentence.

Post by Stephen Kent
It would seem that use of an existing IKE SA for re-key is as
resistant to a DoS attack as any IKE SA after it is established.

But if IKE traffic can't get through the SA will eventually expire...

Post by Stephen Kent
The rest of the paragraph just said that we don't specify how to
locate an IKE peer when creating an IKE SA in general. It seems hard
to characterize the DoS vulnerability of an unspecified mechanism.

Right, I was referring to the first part. I thought that would be clear.

Nico
--

Stephen Kent

2005-12-08 23:40:18 UTC

This does not address DoS attacks aimed at preventing re-keying.

To what part of the paragraph you cited does this observation apply?

The first sentence.

Post by Stephen Kent
It would seem that use of an existing IKE SA for re-key is as
resistant to a DoS attack as any IKE SA after it is established.

But if IKE traffic can't get through the SA will eventually expire...

Right, I was referring to the first part. I thought that would be clear.

Thanks for the clarification, but I'm still not certain I understand
your point. Are you suggesting that an attacker will
- wait for a child SA to timeout (or come close to timeout)
- suppress traffic between the road warrior and the SG, on
the IKE SA to prevent its use for rekey
- wait for that SA to time out
- and then try to initiate a new IKE SA so that the attacker
(who has the credentials of another valid RW user) can pose as the
road warrior whose IKE SA and child SAs both timed out?

The goal of this attack is to take over connections to hosts behind
the SG, where these connections belong to the first RW (assuming that
these connections have not themselves timed out by now)?

Sorry, but I think your comment was way too brief for me to reliably
infer all of that context. I would not say that this attack can't be
carried out, but it requires enough timeouts and active wiretapping
events as to be pretty far down on the list of things to worry about,
in my opinion.

Steve

Nicolas Williams

2005-12-09 00:25:14 UTC

Post by Nicolas Williams
Right, I was referring to the first part. I thought that would be clear.

Yes.

Post by Stephen Kent
The goal of this attack is to take over connections to hosts behind
the SG, where these connections belong to the first RW (assuming that
these connections have not themselves timed out by now)?

(Not just tunnels...)

Relying on connection timeouts being significantly smaller than SA
timeouts seems unlikely to work (particularly if said timeouts have to
be enforced by nodes behind an SG that have no idea that they have to do
this).

Post by Stephen Kent
Sorry, but I think your comment was way too brief for me to reliably
infer all of that context. I would not say that this attack can't be
carried out, but it requires enough timeouts and active wiretapping
events as to be pretty far down on the list of things to worry about,
in my opinion.

I'm not so sure. I'm thinking of wifi scenarios and social engineering.

For example, suppressing traffic between a road warrior and its peers
may seem difficult, but if the attacker can get the victim to move out
of range of its AP(s) then the attacker has effectively suppressed
traffic between the victim and its peers. No active wire tapping is
needed in such a scenario. Come on, get with the program: it's all
about wireless nowadays, especially for road warriors! :)

In any case, something concrete does result from this discussion: if we
can specify BTNS such that BTNS nodes get the same level of protection
that road warriors get in 4301 then we can declare concerns about
attacks like the above out of scope for the base BTNS spec.

Nico
--

Nicolas Williams

2005-12-09 04:35:36 UTC

Post by Nicolas Williams
In any case, something concrete does result from this discussion: if we
can specify BTNS such that BTNS nodes get the same level of protection
that road warriors get in 4301 then we can declare concerns about
attacks like the above out of scope for the base BTNS spec.

Or maybe not. The threat models for road warriors talking to SGs and
for BTNS nodes doing end-to-end IPsec need not be the same.

Stephen Kent

2005-12-09 14:40:12 UTC

Or maybe not. The threat models for road warriors talking to SGs and
for BTNS nodes doing end-to-end IPsec need not be the same.

Agreed.

Steve

Nicolas Williams

2005-12-09 15:49:55 UTC

Or maybe not. The threat models for road warriors talking to SGs and
for BTNS nodes doing end-to-end IPsec need not be the same.

Agreed.

In particular, I suspect that road warriors doing VPN aren't too
concerned about their peer road warriors for in all likelihood the
network behing the SG is not very secure to begin with and it would be
easier for an authorized user to go to a physical office, jack in to the
LAN and attack from there.

I think this attack is much more worrisome on end-to-end situations,
where IPsec may be the only session protection available to some
applications. What saves 4301 in this case may simply be [speculation
ahead] that noone uses end-to-end IPsec in very dynamic environments.

BTNS is not intended (by most of us here, I think) to be used for
talking to SGs, but for end-to-end IPsec -- BITS and native modes.

The same attack that may not bother road warriors talking to SGs seems
definitely more worrisome to me for BTNS.

So perhaps we do have a duty to address the problem.

Nico
--

Stephen Kent

2005-12-09 16:39:08 UTC

Or maybe not. The threat models for road warriors talking to SGs and
for BTNS nodes doing end-to-end IPsec need not be the same.

Agreed.

In particular, I suspect that road warriors doing VPN aren't too
concerned about their peer road warriors for in all likelihood the
network behing the SG is not very secure to begin with and it would be
easier for an authorized user to go to a physical office, jack in to the
LAN and attack from there.
I think this attack is much more worrisome on end-to-end situations,
where IPsec may be the only session protection available to some
applications. What saves 4301 in this case may simply be [speculation
ahead] that noone uses end-to-end IPsec in very dynamic environments.
BTNS is not intended (by most of us here, I think) to be used for
talking to SGs, but for end-to-end IPsec -- BITS and native modes.
The same attack that may not bother road warriors talking to SGs seems
definitely more worrisome to me for BTNS.
So perhaps we do have a duty to address the problem.
Nico
--

Nico,

I agree that IPsec probably is not used very often for end-to-end
security, because most enterprise nets don't like to allow
network-layer encrypted traffic through firewalls. (This problem will
not go away because of BTNS.)

For end systems it makes sense to see if there are was to take
advantage of the additional connection state knowledge available to
help address these concerns.

Steve

Nicolas Williams

2005-12-09 19:49:43 UTC

Post by Stephen Kent
I agree that IPsec probably is not used very often for end-to-end
security, because most enterprise nets don't like to allow
network-layer encrypted traffic through firewalls. (This problem will
not go away because of BTNS.)

But even inside intranets I suspect end-to-end use of IPsec is not
widespread. I think the problem we've been discussing is more serious
for end-to-end uses of IPsec than for VPN uses of it, and that since
BTNS is intended to be used in end-to-end fashion this problem is more
serious for BTNS specifically than for VPN.

Post by Stephen Kent
For end systems it makes sense to see if there are was to take
advantage of the additional connection state knowledge available to
help address these concerns.

Right. Connection latching does exactly that.

We need to think about how to describe connection latching in RFC4301
terms and what extensions RFC4301 might need for connection latching.

Similarly for leap-of-faith, if anyone still thinks we need it.

Stephen Kent

2005-12-09 20:04:33 UTC

Yes, it's probably fair to say that the configuration management
required for access control and for authentication deter intra-net
use of IPsec.

Post by Stephen Kent
For end systems it makes sense to see if there are was to take
advantage of the additional connection state knowledge available to
help address these concerns.

Right. Connection latching does exactly that.
We need to think about how to describe connection latching in RFC4301
terms and what extensions RFC4301 might need for connection latching.
Similarly for leap-of-faith, if anyone still thinks we need it.

OK.

Steve

Nicolas Williams

2005-12-09 20:08:58 UTC

Post by Nicolas Williams
But even inside intranets I suspect end-to-end use of IPsec is not
widespread. I think the problem we've been discussing is more serious
for end-to-end uses of IPsec than for VPN uses of it, and that since
BTNS is intended to be used in end-to-end fashion this problem is more
serious for BTNS specifically than for VPN.

Yes, it's probably fair to say that the configuration management
required for access control and for authentication deter intra-net
use of IPsec.

On the other hand, adding features such as connection latching that
provide protection against hijacking would make configuration of
end-to-end IPsec simpler by allowing the safe use of PAD entries with
wildcards for ID matching and large IP address ranges for selector
constraints.

Nico
--

Stephen Kent

2005-12-09 20:59:49 UTC

Post by Nicolas Williams
...

Post by Stephen Kent
Yes, it's probably fair to say that the configuration management
required for access control and for authentication deter intra-net
use of IPsec.

maybe. it really depending on how one is using IPsec, the user
population (RWs vs. satellite offices vs. inter-enterprise VPNs,
...), etc.

your actual configuration savings may vary ...

Steve

Stephen Kent

2005-12-09 14:17:11 UTC

Nico,

I too think this has been a useful discussion, although it would be
easier (at least for me) if we had articulated the precise
description of the potential problem from the beginning :-).

I agree that we ought not rely on the relative timeout durations for
user connections vs. SAs. However, I do believe that the former are
generally much shorter than the latter. From a crypto perspective, at
typical RW access speeds, it would take many hours to send enough
traffic to warrant a re-key of a child SA, even using 32-bit sequence
numbers. Now that we have mandated support for 64-bit sequence
numbers for these SAs, basic crypto concerns are not likely to ever
trigger a re-key. The peer node is likely to crash before it triggers
a re-key based on traffic volume. Thus we have to ask what
time-based re-key interval is appropriate, for other than crypto
reasons. The same question applies to IKE SAs. They carry so little
traffic that basic crypto concerns are also not likely to ever
trigger a re-key. Since retaining these SAs offers great benefits
with regard to creating new child SAs, and for SA maintenance in
general, I would guess the primary reason to delete them is if an
implementation runs out of space for the SA state.

Your wireless access example is a valid one, although I would argue
that the list of attacker actions that needs to be exercised to
execute the attack is getting pretty long ;-).

Your closing comment seems a little bit ambiguous. We have identified
residual vulnerabilities for RW use of (vanilla) IPsec, given a
specific set of assumptions about how one choose to define PAD and
SPD entries. There are other options for PAD and SPD configuration
ton accommodate RWs, which would be more secure but more onerous from
a management perspective. It seems fair to say that if BTNS is used
in a context where RWs are supported as I described, then it need not
be more secure than vanilla IPsec, to meet the criterion established
by Sam when the WG was chartered. But, an IPsec context that does not
support RWs, or that uses a different PAD & SPD configuration
approach to accommodate them ought not be made more vulnerable by
BTNS use, right?

Steve

Nicolas Williams

2005-12-09 16:00:07 UTC

Post by Stephen Kent
I too think this has been a useful discussion, although it would be
easier (at least for me) if we had articulated the precise
description of the potential problem from the beginning :-).

There you go again :)

Post by Stephen Kent
I agree that we ought not rely on the relative timeout durations for
user connections vs. SAs. However, I do believe that the former are
generally much shorter than the latter. From a crypto perspective, at
typical RW access speeds, it would take many hours to send enough
traffic to warrant a re-key of a child SA, even using 32-bit sequence
numbers. Now that we have mandated support for 64-bit sequence
numbers for these SAs, basic crypto concerns are not likely to ever
trigger a re-key.

Well, it's not just the 64-bit sequence numbers, but the use of 128-bit
block ciphers.

At any rate, why should mobile nodes negotiate very long-lived SAs? Or,
more importantly, why should their peers allow them to negotiate very
long-lived SAs? (And how can a node, not an SG, know that a peer is
mobile?)

Post by Stephen Kent
Your wireless access example is a valid one, although I would argue
that the list of attacker actions that needs to be exercised to
execute the attack is getting pretty long ;-).

Nah, just get the victim out of range with some good excuse and keep
them out for as long as it takes for the victim's SAs to expire, then
take over the victim's IP address and slide in. The attacker has to
have credentials that match the same PAD entry or a similar one to that
matched by the victim on the target SG -- a pretty strong requirement,
but one that is easy to meet if the victim was a BTNS node!

Post by Stephen Kent
Your closing comment seems a little bit ambiguous. We have identified
residual vulnerabilities for RW use of (vanilla) IPsec, given a
specific set of assumptions about how one choose to define PAD and
SPD entries. There are other options for PAD and SPD configuration
ton accommodate RWs, which would be more secure but more onerous from
a management perspective. It seems fair to say that if BTNS is used
in a context where RWs are supported as I described, then it need not
be more secure than vanilla IPsec, to meet the criterion established
by Sam when the WG was chartered. But, an IPsec context that does not
support RWs, or that uses a different PAD & SPD configuration
approach to accommodate them ought not be made more vulnerable by
BTNS use, right?

Right, I corrected myself subsequently -- the same attack can be of
different value in different contexts because we'll have different
threat models. OTOH, a solution to this attack should be general, even
if specifically needed by BTNS.

But note that the RW issue is not just for RWs -- RW may be the primary
example for the use of wildcards in 4301, but certainly I could see
folks using those in contexts other than RWs talking to SGs.

Nico
--

Stephen Kent

2005-12-09 16:50:52 UTC

Post by Nicolas Williams
...
Well, it's not just the 64-bit sequence numbers, but the use of 128-bit
block ciphers.

128-bit block ciphers are good for VERY large traffic volumes, about
2**64 blocks, and 16 bytes per block) is a lot of data. It was use of
DES, a 64-bit block cipher, that made this more of a concern, but
even then most SAs were not in place long enough for this to be an
issue.

Post by Nicolas Williams
At any rate, why should mobile nodes negotiate very long-lived SAs? Or,
more importantly, why should their peers allow them to negotiate very
long-lived SAs? (And how can a node, not an SG, know that a peer is
mobile?)

Two answers:
- first, this is not so much a mobile vs. stationary user
matter. with AES-128 and 64-bit sequence numbers, it should be very
rare for an SA to persist long enough to need to be re-keyed for
crypto reasons.
- second, why negotiate a short lived SA, and incur the cost
and complexity of re-keying if you don't have to?

For the last few days we were having a discussion about whether BTNS
might create new security problems as we modified the PAD to
accommodate BTNS functionality, or whether we already had serious
security problems in the vanilla IPsec context. Your example
illustrates how support for BTNS might cause what was a low risk
residual vulnerability in vanilla IPsec into a more serious concerns
in a BTNS context.

Post by Nicolas Williams
...
Right, I corrected myself subsequently -- the same attack can be of
different value in different contexts because we'll have different
threat models. OTOH, a solution to this attack should be general, even
if specifically needed by BTNS.
But note that the RW issue is not just for RWs -- RW may be the primary
example for the use of wildcards in 4301, but certainly I could see
folks using those in contexts other than RWs talking to SGs.

Yes, wild cards are not restricted to RW scenarios.

Steve

Nicolas Williams

2005-12-09 19:32:36 UTC

Post by Nicolas Williams
...
Well, it's not just the 64-bit sequence numbers, but the use of 128-bit
block ciphers.

That's what I said -- you say that because of 64-bit sequence numbers
SA expiration is not driven by traffic volume, and I added that 128-bit
cipher block sizes are necessary also for traffic volume to be a
non-issue.

Nico
--

Stephen Kent

2005-12-09 19:59:10 UTC

Post by Nicolas Williams
...
Well, it's not just the 64-bit sequence numbers, but the use of 128-bit
block ciphers.

Sorry, I misunderstood your comment.

Steve

Nicolas Williams

2005-12-09 19:35:19 UTC

- first, this is not so much a mobile vs. stationary user
matter. with AES-128 and 64-bit sequence numbers, it should be very
rare for an SA to persist long enough to need to be re-keyed for
crypto reasons.
- second, why negotiate a short lived SA, and incur the cost
and complexity of re-keying if you don't have to?

But then you have to do dead peer detection when IP addresses are
re-assigned.

Look, a road warrior with a 30 minute DHCP lease ought not be
negotiating SAs that live longer than the DHCP lease. Else the next
road warrior to take that address (and talk to the same peers as the
first) will be unhappy.

Stephen Kent

2005-12-09 20:02:30 UTC

But then you have to do dead peer detection when IP addresses are
re-assigned.

yes, but DPD is a function that most vendors consider important, for
a variety of reasons.

Post by Nicolas Williams
Look, a road warrior with a 30 minute DHCP lease ought not be
negotiating SAs that live longer than the DHCP lease. Else the next
road warrior to take that address (and talk to the same peers as the
first) will be unhappy.

I see your point. I was thinking about tunnel mode, since that is
what one uses to contact an SG, and it the change in the outer IP
address need not affect the SA, as the MOBIKE folks have described in
detail in their documents. Maybe that's (another) good reason to use
tunnel mode in contexts like this.

Steve

Nicolas Williams

2005-12-09 20:13:10 UTC

Post by Nicolas Williams
But then you have to do dead peer detection when IP addresses are
re-assigned.

yes, but DPD is a function that most vendors consider important, for
a variety of reasons.

You once again misunderstood my point, which was not to cast aspertions
on DPD. See below.

The point is that relying on SA expiration to add protection against the
highjacking problem doesn't help if DPD is used and, OTOH, if DPD is not
used then long SA expiration can lead to dynamic address exhaustion (a
DoS).

Nico
--

Stephen Kent

2005-12-09 20:49:57 UTC

Post by Nicolas Williams
But then you have to do dead peer detection when IP addresses are
re-assigned.

yes, but DPD is a function that most vendors consider important, for
a variety of reasons.

You once again misunderstood my point, which was not to cast aspertions
on DPD. See below.

When I misread your comment on 128-bit block ciphers the error was
all mine. I read the sentence too quickly. However, the text above is
not as clear as it could be.

You refer to "relying on SA expiration" without indicating whether
you are referring to long duration SAs or short duration SAs. Do you
mean that we can have shorter duration SAs and re-key them safely IF
we keep around the IKE SAs, via which we perform DPD?

Yes, longer duration SAs, without DPD, create a DoS potential, but
this seems to be mostly a BTNS issue, since otherwise the ability to
create an SA is strictly limited to (pre-) authorized peers.

Steve

Steve

Pekka Nikander

2005-12-15 10:15:58 UTC

Steve,

FWIW, I think there is a deeper architectural issue lurking in here.

Using tunnel mode (especially with rfc 1918 addresses) implements a
kind of identifier/locator split. The inner addresses are no more
used as locators (at least in the Internet) but more as identifier
proxies, to tie security semantics to something that exists at the IP
layer. The outer addresses act as locators, at least at the Internet
side.

Of course, the distinction is not clear, as the inner addresses are
likely to be used as both identifier proxies and locators in the
intranet side.

From this point of view, I fully agree with you: using tunnel mode
have good reasons here. However, I also think that in the long run
we should go forward, and try to get rid of tunnel mode overhead by
implementing the required id/loc split directly at the host level.

Given the direction BTNS seems to be taking, i.e., using public keys
a identifiers, this mostly becomes an API issue. That is, how do we
represent the public keys to the applications. Do we use inner IP
addresses as proxies for them, as we do today? If so, should we
perhaps recommend use CGA or KHI addresses and only IPv6 API, to
provide some intrinsic security to the binding between the inner
addresses and the identifiers? Or should we have a completely new
API, allowing applications to learn the IP addresses the public key
through the new API? Finally, if we use this kind of id/loc-split-
like tunnel mode in end-to-end BTNS, should we perhaps go for tunnel
overhead reduction? (I think MOBIKE is considering doing that.)

[KHIs are defined in draft-laganier-ipv6-khi-00.txt]

From my very personal point of view, I would like to see the whole
stack architecture to evolve to a direction where we use KHI
addresses as "inner addresses" or identifiers, tunnel them to outer
addresses or locators locally at the end-node, and reduce the
tunnelling overhead to minimum. The problem with this approach, of
course, is the initial resolution from KHI addresses to the locators.

From my point of view, that would provide fairly good backwards
compatibility with applications using IPv6 addresses. The transport
efficiency (header overhead) would be minimal. And it would provide
applications with IP addresses that have security semantics similar
to what IPsec expects today but independent of the usage, lifetime,
and selection of the outer addresses.

--Pekka

Stephen Kent

2005-12-15 14:47:14 UTC

Pekka,

Gee, are we getting cross talk from the HIP WG list :-)?

Seriously, the inner/outer header address processing differences in
tunnel mode are not motivated by the features you described. The
inner address is used as the locator and ID by both the sender and
the (ultimate) receiver. The outer header is applied to direct the
packet to a specific SG, to address problems that could arise if
there are multiple SGs, if fragmentation occurs, etc. By convention
we require use of tunnel mode for both SAs in a pair,to make life
simpler.

Post by Pekka Nikander
Given the direction BTNS seems to be taking, i.e., using public keys
a identifiers, this mostly becomes an API issue. That is, how do
we represent the public keys to the applications. Do we use inner
IP addresses as proxies for them, as we do today? If so, should we
perhaps recommend use CGA or KHI addresses and only IPv6 API, to
provide some intrinsic security to the binding between the inner
addresses and the identifiers? Or should we have a completely new
API, allowing applications to learn the IP addresses the public key
through the new API? Finally, if we use this kind of
id/loc-split-like tunnel mode in end-to-end BTNS, should we perhaps
go for tunnel overhead reduction? (I think MOBIKE is considering
doing that.)

This argument seems to be very host-implementation centric. IPsec is
used in host, BITW and SG contexts. Maybe BTNS needs to decide
explicitly whether it is targeted only at hosts, or also at BITW and
SG contexts, before we consider arguments that are host-centric.

Steve

Pekka Nikander

2005-12-16 05:59:42 UTC

Steve,

Post by Stephen Kent
Gee, are we getting cross talk from the HIP WG list :-)?

You know, from the very beginning one of the reasons why I agreed to
co-chair this WG was due to my personal believe that BTNS would be a
step to the "right" direction. Whether HIP is the right direction or
not, not even the jury is out yet but we are still collecting
evidence. However, personally, I believe that there are multiple
reasons why we will need a new layer of indirection in the stack.
Given that, I've been quite convinced for a number of years now that
the "right" place to add such indirection is at the boundary between
the end-to-end and hop-by-hop functions at the IP layer. IPsec
happens to be just there, for good reasons.

Post by Stephen Kent
Seriously, the inner/outer header address processing differences in
tunnel mode are not motivated by the features you described. The
inner address is used as the locator and ID by both the sender and
the (ultimate) receiver. The outer header is applied to direct the
packet to a specific SG, to address problems that could arise if
there are multiple SGs, if fragmentation occurs, etc. By convention
we require use of tunnel mode for both SAs in a pair,to make life
simpler.

I am not arguing about the conventional use of tunnelling. Like you
are (rightly) labelling my argumentation as host centric, I'd be
tempted to label your argumentation as VPN centric. FWIW, I find it
still quite sad that the IPsec WG took the VPN oriented direction for
so many years and almost ignored host-centric possibilities. But I
think I do understand many of the reasons for that, though not
necessarily all.

Given that, I'd allude that you are above, intentionally or not,
ignoring the sore reality that SGs are often (but not always) placed
at the boundary between RFC 1918 addressed and publicly addressed
network segments. When used in such a way, SGs and tunnelling as
used for what some people call "IP virtualisation". I don't know if
you have followed the recent discussions at the INT area and
architecture-discuss mailing lists, but I've been questioning there
whether such "IP virtualisation" is a sound long-term practise or
more an indication of something missing from the networking service
that we provide. (As a shorter-term practice IP virtualisation or
VPNs are a fine too, no problem with that.)

Hence, while you are certainly right stating that when the tunnel
processing model was designed people did not necessarily consider the
processing differences in terms of id/loc split, I still find it
interesting that there are so many parallels between the current
operational reality and the requirements that are leading to me to
believe that there is a need of a new indirection layer.

Post by Pekka Nikander
Given the direction BTNS seems to be taking, i.e., using public
keys a identifiers, this mostly becomes an API issue. That is,
how do we represent the public keys to the applications. Do we
use inner IP addresses as proxies for them, as we do today? If
so, should we perhaps recommend use CGA or KHI addresses and only
IPv6 API, to provide some intrinsic security to the binding
between the inner addresses and the identifiers? Or should we
have a completely new API, allowing applications to learn the IP
addresses the public key through the new API? Finally, if we use
this kind of id/loc-split-like tunnel mode in end-to-end BTNS,
should we perhaps go for tunnel overhead reduction? (I think
MOBIKE is considering doing that.)

This argument seems to be very host-implementation centric.

Indeed.

Post by Stephen Kent
IPsec is used in host, BITW and SG contexts. Maybe BTNS needs to
decide explicitly whether it is targeted only at hosts, or also at
BITW and SG contexts, before we consider arguments that are host-
centric.

Personally, I don't believe that all solutions BTNS produces must
work equally in the host, BITW and SG contexts. That is, I'm fine if
the use of BTNS is more limited if used in BITW and/or SG contexts
than when used in a pure host-to-host implementation context. But
that is up to the WG to decide.

But there seems to be a quite few issues here:

- Quite a lot of the current discussion (connection latching, SPD/SA
hijacking etc) seems to be intrinsically related to the underlying
provisioning model. Indeed, the main difference between BTNS and
"traditional" IPsec is in the provisioning models. In traditional
IPsec, explicit configuration is a cornerstone for security while
BTNS aims for a weaker security model where little or no
configuration and no explicit credentials provisioning are needed.

- The harder part in any tunnelling (IPsec or not) is provisioning or
configuration.

- From an end-point / stack architecture point of view, the
difference between tunnelling and address-preserving double address
translation is a very fine one. Almost non-existing. Tunnelling
changes the IP addresses the network sees by wrapping an existing
packet within a new header. As a packet emerges from the tunnel, it
has the same IP addresses as before entering. Double address
translation changes the IP addresses the network sees by replacing
the IP addresses in the packet. After the "unwrapping" translation
at the receiver end, the packet has the same IP addresses as before
getting translated. The biggest practical or provisional difference
is that double translation requires that there is one-to-one mapping
between <inner-src, inner-dst> and <outer-src, outer-dst, spi> pairs
while tunnelling doesn't.

So, trying to put the argumentation above together, my tentative
conclusions are the following:

1. I see there definitive architectural value in solutions that
advance the stack architecture into a direction where we implement a
new layer of indirection (roughly) at the same place where IPsec is.

2. We need to be very careful when we think about the BTNS
provisioning model and its consequences to security.

3. One potential way to solve/avoid problems related to connection
latching and leap-of-faith is to make changes at the API level. One
possible way to change the API is to provide applications with
identifiers that fulfil their current semantic assumptions but that
are not used as locators in the network. Such usage is, the
provisioning model disregarding, fairly close to some current uses of
IPsec tunnelling.

I admit that this is a complex issue and requires, at least for me,
some mind-boggling shifts in viewpoints while thinking through.

--Pekka

Joe Touch

2005-12-16 19:10:46 UTC

Post by Pekka Nikander
2. We need to be very careful when we think about the BTNS
provisioning model and its consequences to security.

I'm wondering if we can address the persistent concerns about BTNS
creating new holes by saying simply and directly:

"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

(i.e., SPD entries that the administrator would be just as comfortable
setting as BYPASS).

?? (I appreciate this may be too direct or too simplistic, but I wonder
if it helps)...

Joe

Nicolas Williams

2005-12-16 19:28:50 UTC

Post by Pekka Nikander
2. We need to be very careful when we think about the BTNS
provisioning model and its consequences to security.

I'm wondering if we can address the persistent concerns about BTNS
"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

No, because as we discussed a week or so ago the applicability statement
says that BTNS protects against on-path MITM attacks subsequent to
initial exchanges.

What you may want to propose is that we drop that requirement.

Joe Touch

2005-12-16 19:47:08 UTC

Post by Pekka Nikander
2. We need to be very careful when we think about the BTNS
provisioning model and its consequences to security.

I'm wondering if we can address the persistent concerns about BTNS
"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

No, because as we discussed a week or so ago the applicability statement
says that BTNS protects against on-path MITM attacks subsequent to
initial exchanges.
What you may want to propose is that we drop that requirement.

I'm proposing that you don't use BTNS unless you would have been
comfortable using BYPASS on that traffic; I'm not proposing that it's
identical.

Joe

Nicolas Williams

2005-12-16 19:50:35 UTC

Post by Joe Touch
I'm wondering if we can address the persistent concerns about BTNS
"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

No, because as we discussed a week or so ago the applicability statement
says that BTNS protects against on-path MITM attacks subsequent to
initial exchanges.
What you may want to propose is that we drop that requirement.

I'm proposing that you don't use BTNS unless you would have been
comfortable using BYPASS on that traffic; I'm not proposing that it's
identical.

I don't understand -- what is not identical to what?

Please address the on-path MITM issue.

Joe Touch

2005-12-16 21:14:27 UTC

Post by Joe Touch
I'm wondering if we can address the persistent concerns about BTNS
"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

No, because as we discussed a week or so ago the applicability statement
says that BTNS protects against on-path MITM attacks subsequent to
initial exchanges.
What you may want to propose is that we drop that requirement.

I'm proposing that you don't use BTNS unless you would have been
comfortable using BYPASS on that traffic; I'm not proposing that it's
identical.

I don't understand -- what is not identical to what?

BTNS != BYPASS

Post by Nicolas Williams
Please address the on-path MITM issue.

If you restrict the use of BTNS to traffic that you could have been
comfortable BYPASSing, MITM is moot.

Joe

Nicolas Williams

2005-12-16 21:47:19 UTC

Post by Nicolas Williams
Please address the on-path MITM issue.

If you restrict the use of BTNS to traffic that you could have been
comfortable BYPASSing, MITM is moot.

So are we then to understand that you do want to drop protection-
against-MITM-attacks-after-initial-key-exchange from the requirements
for BTNS?

Joe Touch

2005-12-16 22:51:11 UTC

Post by Nicolas Williams
Please address the on-path MITM issue.

If you restrict the use of BTNS to traffic that you could have been
comfortable BYPASSing, MITM is moot.

So are we then to understand that you do want to drop protection-
against-MITM-attacks-after-initial-key-exchange from the requirements
for BTNS?

No - but since you don't know who you're doing the initial key exchange
with, you shouldn't do such exchanges with any party you wouldn't
basically be willing to do BYPASS with.

Joe

Stephen Kent

2005-12-16 23:48:55 UTC

Post by Pekka Nikander
...
You know, from the very beginning one of the reasons why I agreed to
co-chair this WG was due to my personal believe that BTNS would be a
step to the "right" direction.

The charter of BTNS focuses on contexts in which not authenticating a
peer at the IP layer is a useful feature. It does not discuss the
locator/ID separation that is the gist of your previous message.

Post by Pekka Nikander
Whether HIP is the right direction or not, not even the jury is
out yet but we are still collecting evidence. However, personally,
I believe that there are multiple reasons why we will need a new
layer of indirection in the stack.
Given that, I've been quite convinced for a number of years now that
the "right" place to add such indirection is at the boundary between
the end-to-end and hop-by-hop functions at the IP layer. IPsec
happens to be just there, for good reasons.

As noted above, I think this WG is not an appropriate place to have
this discussion, given its charter.

Post by Pekka Nikander

Post by Stephen Kent
...

I disagree with your characterization. I think IPsec adopted a
perspective that encompassed host, BITW, and SG approaches to
providing the set of securty services we aim to provide.

Post by Pekka Nikander
Given that, I'd allude that you are above, intentionally or not,
ignoring the sore reality that SGs are often (but not always) placed
at the boundary between RFC 1918 addressed and publicly addressed
network segments. When used in such a way, SGs and tunnelling as
used for what some people call "IP virtualisation". I don't know if
you have followed the recent discussions at the INT area and
architecture-discuss mailing lists, but I've been questioning there
whether such "IP virtualisation" is a sound long-term practise or
more an indication of something missing from the networking service
that we provide. (As a shorter-term practice IP virtualisation or
VPNs are a fine too, no problem with that.)

I have not followed those discussions. But I don't think this WG is
an appropriate place to pursue them, given the charter.

Post by Pekka Nikander
Hence, while you are certainly right stating that when the tunnel
processing model was designed people did not necessarily consider
the processing differences in terms of id/loc split, I still find it
interesting that there are so many parallels between the current
operational reality and the requirements that are leading to me to
believe that there is a need of a new indirection layer.

You may be right, but again, I would argue that the creation of the
indirection layer option is a HIP WG matter, not a BTNS matter.

Post by Pekka Nikander

agreed.

Post by Pekka Nikander
- Quite a lot of the current discussion (connection latching, SPD/SA
hijacking etc) seems to be intrinsically related to the underlying
provisioning model. Indeed, the main difference between BTNS and
"traditional" IPsec is in the provisioning models. In traditional
IPsec, explicit configuration is a cornerstone for security while
BTNS aims for a weaker security model where little or no
configuration and no explicit credentials provisioning are needed.

I would say that BTNS is motivated by the perception that
provisioning for authentication is a burden in many contexts and that
there are situations where it makes sense to avoid this burden.

Post by Pekka Nikander
- The harder part in any tunnelling (IPsec or not) is provisioning
or configuration.

oh?

Post by Pekka Nikander
- From an end-point / stack architecture point of view, the
difference between tunnelling and address-preserving double address
translation is a very fine one. Almost non-existing. Tunnelling
changes the IP addresses the network sees by wrapping an existing
packet within a new header. As a packet emerges from the tunnel, it
has the same IP addresses as before entering. Double address
translation changes the IP addresses the network sees by replacing
the IP addresses in the packet. After the "unwrapping" translation
at the receiver end, the packet has the same IP addresses as before
getting translated. The biggest practical or provisional difference
is that double translation requires that there is one-to-one mapping
between <inner-src, inner-dst> and <outer-src, outer-dst, spi> pairs
while tunnelling doesn't.

One can perform tunneling for different reasons, some (many?) of
which are distinct from the reasons for address translation. As I
noted previously, tunneling for IPsec is motivated (in large part) by
the need to direct the traffic to a specific SG, to ensure that the
traffic arrives at a point where the SA state is present. if one
reads more into tunneling than that, one is going outside the intent
of the IPsec WG efforts.

Post by Pekka Nikander
So, trying to put the argumentation above together, my tentative
1. I see there definitive architectural value in solutions that
advance the stack architecture into a direction where we implement a
new layer of indirection (roughly) at the same place where IPsec is.

Which is what HIP is doing, right? So why should this be part of the
discussion here?

Post by Pekka Nikander
2. We need to be very careful when we think about the BTNS
provisioning model and its consequences to security.

no argument there.

Post by Pekka Nikander
3. One potential way to solve/avoid problems related to connection
latching and leap-of-faith is to make changes at the API level. One
possible way to change the API is to provide applications with
identifiers that fulfil their current semantic assumptions but that
are not used as locators in the network. Such usage is, the
provisioning model disregarding, fairly close to some current uses
of IPsec tunnelling.

Just because the two look similar, that does not mean they are
equivalent. Since BTNS focuses on creating SAs that are not
authenticated via network layer mechanisms, the notion of the IDs
used at this layer seems irrelevant to the BTNS focus.

Steve

Joe Touch

2005-12-16 19:02:34 UTC

Post by Black_David at emc.com ()
Steve,

I disagree; the outer addresses locate the decapsulating security
device, but the inner addresses still just locate the endpoint from that
point on. They're not global address/locators, but local to the SG-host
path, and they still combine name and location, as you note below.

Post by Black_David at emc.com ()
Of course, the distinction is not clear, as the inner addresses are
likely to be used as both identifier proxies and locators in the
intranet side.
From this point of view, I fully agree with you: using tunnel mode
have good reasons here.

Tunnels can be used several ways:
1- keep the SA but allow outer addresses to change
2- keep the SA but allow inner addresses to change
3- make the SA inner + outer specific

All three modes have their uses; 3 is certainly more conservative, but 1
is needed for mobility without rekeying and 2 is needed (and typically
used) for aggregation (e.g., VPN for a subnet).

There are a lot of subtle issues that evolve out of that, as you note
with respect to efficiency, but also with respect to dynamic routing,
etc. BTNS may provide an opportunity for some of this as follow-on, but
seems out of scope at this time, IMO.

Joe

Nicolas Williams

2005-12-16 20:05:23 UTC

Post by Pekka Nikander
FWIW, I think there is a deeper architectural issue lurking in here.

Yes.

Post by Pekka Nikander
Using tunnel mode (especially with rfc 1918 addresses) implements a
kind of identifier/locator split. The inner addresses are no more
used as locators (at least in the Internet) but more as identifier
proxies, to tie security semantics to something that exists at the IP
layer. The outer addresses act as locators, at least at the Internet
side.

But this deeper architectural issue is NOT specific to tunnels.

So, let's leave tunnels behind for a second and consider this
formulation of said architectural problem:

IPsec, in its current form, requires a trade-off between dynamic
addressing (the reality of today's IPv4 networks) and cryptographic
binding of authenticated IDs and packet _flows_.

A slightly longer version:

IPsec provides ID<->packet cryptographic binding and cryptographic
protection for individual packets.

IPsec does not provide cryptographic binding of IDs to packet _flows_
associated with ULPs beyond that which is embodied in the IPsec
configuration. This is so because IPsec is not integrated with the
ULPs.

To provide such cryptographic binding of IDs to packet _flows_
requires IPsec configuration to bind IDs to IP addresses, which makes
IPsec configuration unmanageable where node renumbering events are
common (as they often are, if nothing else because of DHCP/mobile
nodes).

There is a way to add such cryptographic binding of IDs<->flows, but it
requires interfaces between IPsec and ULPs to manage such bindings and
between applications and ULPs to allow applications access to channel
bindings (not only for channel binding, but also so that applications
can determine if two channels have equal bindings, for example).

Other ways to achieve some degree of cryptographic binding of
IDs<->flows involve IPsec guessing ULP state from packet inspection
(much like NATs do).

Are there still other ways to solve this problem? I can't think of any.

Nico
--

Joe Touch

2005-12-08 16:59:53 UTC

How do you know they're different peers if they claim to be the same
peer and are authenticated differently? That seems to be what allows the
new peer to pose as the old one and affect even a persistent connection
to the old one (e.g., by rekeying).

Joe

Stephen Kent

2005-12-08 22:22:20 UTC

Post by Joe Touch
...

You ask what happens if an SA (for a road warrior) expires and different
peer claims the same remote IP address. It is not clear that there is
any point in the re-key process that makes this a problem, per se. I
think the real question is whether we check to ensure that we don't
create two SAs with different peers but the same selector sets, when a
child SA is created, in general. (Assume that the SAs in question have
the remote ID address asserted by a road warrior, but the local IP
address, protocol, and port fields are all ANY, a not-unreasonable SPD
entry for such users.)

In this example the peers assert different IDs and these IDs are
verified based on use of different credentials, even though they are
authenticated under a single PAD entry. So, they are not claiming to
be the same entity at the peer authentication stage of the process.
Both the original peer and the new peer map to the same SPD entry, if
we use a wild card name there (not because of use of the wild card
name in the PAD entry). Thus the new peer is free to assert the same
remote IP address as the previous peer, based only on the SPD check.
If we retain the peer ID from the previous entity (as part of the
SPD-S cache entry), that could be used to reject attempts to assert
the same remote address by a new entity, and still allow a remote
entity to initiate a re-key while retaining an existing, remote
address. But, let's look first at why this has not been an issue to
date.

If the (parent) IKE SA is still present, then by using that SA to
protect the re-key we ensure that the peer for the re-key is
unchanged. So, persistence of that SA is a simple, secure solution to
this problem. It's also preferable from a performance perspective, as
we avoid the need to perform a new DH operation or re-authenticate
the peer.

Although Mike has not yet responded to this thread,I believe many
IPsec SG implementations assign an address to the road warrior, from
a pool reserved for road warriors, rather than allowing the RW to
assert its address. The notion is that outbound traffic to RWs has to
be routed to the SG, and thus a pool of addresses is reserved for
this purpose. This prevents a new IKE exchange from resulting in a
remote address that is already in use, although it also would pull
the address put from under a RW who was re-keying a long-lived SA,
and thus kill extant connections using the old SA.

My guess is that the problem we have been discussing is not a problem
in practice. Use of the (parent) IKE SA, if it exists, avoids the
problem. If that SA is not available, use of the DHCP-style address
assignment by an SG avoids the hijacking concern, although at the
expense of connection continuity. Given likely SA durations based on
crypto security criteria, it seems unlikely that re-keying will be
needed for most RWs. My experience as a RW is that my hotel usually
time out my DHCP lease and cause me to reconnect if I linger too long
reading e-mail.

We could add the peer IKE ID to the SPD-S cache part of the 4301
processing model in a future document if folks agree that it is
needed, and if it helps address the concerns raised by proposed BTNS
use of PAD.

Steve

Michael Richardson

2006-02-11 01:03:54 UTC

Stephen> You ask what happens if an SA (for a road warrior) expires and
Stephen> different peer claims the same remote IP address. It is not
Stephen> clear that there is any point in the re-key process that makes
Stephen> this a problem, per se. I think the real question is whether we
Stephen> check to ensure that we don't create two SAs with different

It's not about rekeys.
RW A (Stephen Kent) connects does it's thing. It leaves, probably abruptly
when it goes into hibernate mode as you close the lid and begin to board
aircraft.

RW B (Karen Sao) (not being on the same flight as you because, well, BBN and
the IETF IPsec community can't let you both die in the same
plane crash :-)

then opens her laptop, gets the same IP address that you had (from the
point of view of your gateway)
(Either because the airport departure lounge is very busy, and the DHCP
leases are ver short, or because you are all NAT'ed to a single IP anyway)

What does the gateway do?
Does it drop the tunnel to RW A (you) when RW B shows up?
Does it refuse? Which is correct?

If the gateway drops the tunnel to RW A in favour of RW B, then any entity
which the gateway trusts with a policy like this can DOS other clients, if it
can do some kind of on-path-ish attack. (Remembering that this might not be
hard on wireless networks, and a NAPT might make it happen without malicious
intent).
On the other hand, if the gateway doesn't drop the tunnel to RW A in favour
of RW B, then RW B might not be able to get online until the SA expires.

Some things mitigate this: most gateways now use DPD. If the DPD values are
short enough, then the DPD will keep the tunnel to RW A up for awhile,
hopefully long enough for a TCP above to give up. At which point, the tunnel
gets killed (probably after a few minutes).

Now, relevance to BTNS: BTNS means that *ALL* hosts on the Internet are
possibly able to make connections, not just your set of trusted road
warriors.
Last time I asked what modes were going to be used, I was told transport
mode, and that this was going to just "work" through NAT (or that NAT wasn't
important). I think that exactly how the gateway deals with NAT (and
therefore what shape it's SPD takes) is going to be relevant.
We may have to specify one solution as being better than others, or at
least explain how to write the right SPD entries for various NAT-T+transport
combinations.

(%) NAT-T caveats. Or why it isn't really a problem in general.
If you use NAT-T, then you get UDP encapsulation, and the NAPT assigns RW
A/RW B new port numbers. So, the gateway can see you each as unique
hosts. If the NAT is ESP/IKE aware (i.e. "helpful" aka "IPsec
passthrough"), then this might not happen.

Secondly, odds are you are going to use tunnel mode, and are going to
propose and/or be assigned (by modecfg), a unique inner address, so in
fact the SPD entry for each of you are actually unique.

So, to make this scenario work you'd have to use transport mode, and
the NAPT would have to assign the same port. A proper NAPT won't
reallocate the UDP port number within a reasonable timeout period to
a different client.
The summary is that unless all the gods are aligned against you,
the NAPT won't cause a non-malicious incident. The malicious situation
is still possible.

Nicolas Williams

2006-02-11 09:31:25 UTC

Post by Michael Richardson
Now, relevance to BTNS: BTNS means that *ALL* hosts on the Internet are
possibly able to make connections, not just your set of trusted road
warriors.

As the size of a trust domain approaches the size of the Internet the
difference between BTNS and non-BTNS approaches zero. I'm assuming the
use of wildcard PAD entries and the non-use o iPAddress subject alt
names for "clients" -- a fair assumption for an organization that large!

Post by Michael Richardson
Last time I asked what modes were going to be used, I was told transport
mode, and that this was going to just "work" through NAT (or that NAT wasn't
important). I think that exactly how the gateway deals with NAT (and
therefore what shape it's SPD takes) is going to be relevant.

BTNS is intended (e.g., by yours truly) to be used in end-to-end
communications, not for client<->SG. The point I'm trying to make
(before David Black does :) is that tunnel vs. transport mode isn't as
interesting as whether BTNS is used to protect tunnelled traffic or
end-to-end comms. And this because iSCSI uses tunnel mode, though it
doesn't actually tunnel anything (in the SG sense).

Post by Michael Richardson
We may have to specify one solution as being better than others, or at
least explain how to write the right SPD entries for various NAT-T+transport
combinations.

I think we want to leave tunnelling out of scope for BTNS. That doesn't
simplify things so much though -- we still need connection latching and,
ultimately APIs to inspect what is latched and channel bindings. But
note that IPsec generally needs this, and not because of BTNS -- BTNS is
merely bringing the issue to a head.

Nico
--

Stephen Kent

2006-02-13 21:29:33 UTC

Michael,

I'm getting too old to remember message exchanges 2 months ago :-).

Nonetheless, using your airport lounge example, if Karen gets my old
address, and if she successfully creates a new IKE SA, then she can
have that addresses in parallel with me, in some circumstances. the
addresses we're discussing here are unprotected ones, not the
protected ones inside tunnel headers that are used by RWs to access
SGs back at enterprise HQ. Thus they never are used for access
control purposes, relative to the SPD or SAD. So, in the tunnel mode
case, I think we're OK, even from the DoS concerns you raised. But,
in transport mode (not applicable to the RW scenario), I agree that
there could be DoS problems. Also, if Karen asserts the same inner
address as me, and it is within an address range that is approved for
BTNS use, then we do have a problem.

This seems to be a good reason to be very careful in claiming what
modes and in what contexts BTNS will work, as you suggest.

Steve

Nicolas Williams

2006-02-14 05:56:47 UTC

Post by Stephen Kent
Michael,
I'm getting too old to remember message exchanges 2 months ago :-).
Nonetheless, using your airport lounge example, if Karen gets my old
address, and if she successfully creates a new IKE SA, then she can
have that addresses in parallel with me, in some circumstances. the
addresses we're discussing here are unprotected ones, not the
protected ones inside tunnel headers that are used by RWs to access
SGs back at enterprise HQ. Thus they never are used for access
control purposes, relative to the SPD or SAD. So, in the tunnel mode
case, I think we're OK, even from the DoS concerns you raised. But,
in transport mode (not applicable to the RW scenario), I agree that
there could be DoS problems. Also, if Karen asserts the same inner
address as me, and it is within an address range that is approved for
BTNS use, then we do have a problem.

Yes, the assumption is that Karen could get the same inner address as
you had. Often it's easier to not do static address assignments to
SG users.

Post by Stephen Kent
This seems to be a good reason to be very careful in claiming what
modes and in what contexts BTNS will work, as you suggest.

But you missed the point -- this is a problem with use of wildcards in
PAD entries, not with BTNS; BTNS merely makes the scope wider (from,
e.g., all principals in a given PKI to practically *anyone*; given a
sufficiently large PKI the distinction isn't all that large).

So, yes, document this we must, but more importantly, and particularly
for transport mode, we have to provide one or more of leap-of-faith
(ick), connection latching and/or channel bindings (which, of course,
presume connection latching).

Nico
--

Stephen Kent

2006-02-15 21:27:42 UTC

Yes, the assumption is that Karen could get the same inner address as
you had. Often it's easier to not do static address assignments to
SG users.

sorry, I forgot the context from last year, and it was not explicitly
re-stated in Mike's message.

Post by Stephen Kent
This seems to be a good reason to be very careful in claiming what
modes and in what contexts BTNS will work, as you suggest.

If a sys admin creates a PAD entry with wildcard values for source
addresses, and matches it with an SPD entry that is address (vs.
name) based, then the sys admin is asserting that the entities who
are associated with the PAD entry are all viewed as equivalent for
security purposes. If the PAD and SPD entries are name-based, then
access control should work as expected, but there might still be a
conflict over the inner addresses.

An obvious question is how such addresses are assigned. If they are
static, and the RWs don't modify them, then all should be OK. If they
are DHCP assigned, as is typical for an RW-SG context, again, there
should be non collisions. All of this seems reasonable for non-BTNS
PAD entries.

BTNS makes life complex, because the PAD entries are not being used
for IPsec-level authenticated communication, yet there can be
IPsec-level address conflicts. To me this seems to be an indication
of a problem we are creating for ourselves, by applying security
measures at layer 3 (which use layer 3 IDs, i.e., IP addresses),
while relying on layer 7 to manage authentication.

Steve

Nicolas Williams

2006-02-15 22:42:34 UTC

Post by Nicolas Williams
But you missed the point -- this is a problem with use of wildcards in
PAD entries, not with BTNS; BTNS merely makes the scope wider (from,
e.g., all principals in a given PKI to practically *anyone*; given a
sufficiently large PKI the distinction isn't all that large).

Forget SG usage for a minute and think about end-to-end IPsec.

Q: Why would anyone use wildcard matching?

A: Because as the size and/or dynamism of the network increases it
becomes too difficult to either maintain IPsec configurations or to
maintain host certificates with iPAddress subject alt names.

Alternatives for the security conscious: push network security up the
stack (SSHv2, TLS, etc.) or don't grow your network so large.

Now, for end-to-end network security we have seen network security
pushed up the stack, indeed (if it didn't even just start there).

We should be happy with this state of affairs...

...unless we should find the possibility of off-loading more work onto
NICs attractive (e.g., crypto), which in turn requires pushing at least
session crypto back down the stack. BTNS + connection latching +
channel bindings does just that while leaving principal authentication
where it already is (up the stack).

Post by Stephen Kent
BTNS makes life complex, because the PAD entries are not being used
for IPsec-level authenticated communication, yet there can be
IPsec-level address conflicts. To me this seems to be an indication
of a problem we are creating for ourselves, by applying security
measures at layer 3 (which use layer 3 IDs, i.e., IP addresses),
while relying on layer 7 to manage authentication.

I'll restate: large, dynamic networks and IPsec configuration w/o
wildcards don't mix well. This is not BTNS' fault.

Nico
--

Stephen Kent

2006-02-16 18:12:35 UTC

Nico,

I appreciate your analysis of the issues associated with the problems
we are discussing, but I disagree with several of your assertions and
conclusions.

Network dynamics are more a fact of life today than they were in the
past, which makes use of IP addresses less attractive as identifiers.
Yet, at layer 3, on a per-packet basis, we have only addresses as
end-point IDs, especially for intermediate systems like routers and
firewalls. So,if we choose to enforce access controls at layer three,
we have to be very careful in how we deal with identifiers, to ensure
that we don't make mistakes resulting from cross-layer ambiguities.
What we have done in IPsec and in other protocols is to allow for
higher layer IDs to be used in lieu of addresses (e.g., to
accommodate the dynamics you cite), but then to bind these IDs to
addresses to enable efficient, per-packet access control policy
enforcement for some time interval. An inevitable side effect of this
is the potential to have a mismatch between a higher level ID and the
address, based on unsynchronized management practices between the
layers, e.g., address reassignment.

You suggested that network security is being pushed up the stack. In
some regards that is true, and in others it is not. User
authentication at the application layer is nothing new; it has been a
staple of host security since the days of multi-programming, time
sharing, etc. Is it a network security issue? We have examples of how
to make it more of a network security issue and reduce security,
e.g., the Unix rhost file model. If we use certs to authenticate
users does that make this a network security mechanism? I think not.
On the other hand use of SSL/TLS is certainly an example of moving
security up the stack (from layer 3 to layer 5). For some set of
contexts, an SSL solution may be more appropriate than an IPsec
solution. But, this WG decided to focus on IPsec, and so such
discussions are out of scope here.

There are multiple motivations for imposing security controls at
layer 3. Performance may be important in some instances, as you
suggest, but more often the motivations have to do with assurance and
management. Lower layer controls can be more secure that higher later
controls, given the unfortunate state of OS and application security.
Lower layer controls can be imposed (cleanly) at points other than
end systems, which simplifies management and also may improve
assurance. None of this says that application layer security is
redundant. However, it also does not suggest that trying to split
security services between layer 3 and layer 7, as some BTNS use cases
require, will necessarily work well.

When this WG was chartered I noted that there were multiple
constituencies, each with different goals, all of which hoped to use
the same or similar mechanisms to achieve these disparate goals. What
we are seeing here may be an example of that.

Steve

Nicolas Williams

2006-02-16 20:27:10 UTC

Post by Stephen Kent
Nico,
I appreciate your analysis of the issues associated with the problems
we are discussing, but I disagree with several of your assertions and
conclusions.
Network dynamics are more a fact of life today than they were in the
past, which makes use of IP addresses less attractive as identifiers.
Yet, at layer 3, on a per-packet basis, we have only addresses as
end-point IDs, especially for intermediate systems like routers and
firewalls. So,if we choose to enforce access controls at layer three,
we have to be very careful in how we deal with identifiers, to ensure
that we don't make mistakes resulting from cross-layer ambiguities.
What we have done in IPsec and in other protocols is to allow for
higher layer IDs to be used in lieu of addresses (e.g., to
accommodate the dynamics you cite), but then to bind these IDs to
addresses to enable efficient, per-packet access control policy
enforcement for some time interval. An inevitable side effect of this
is the potential to have a mismatch between a higher level ID and the
address, based on unsynchronized management practices between the
layers, e.g., address reassignment.

In other words: we're in agreement on the significance of wildcard
matching in PAD entries. Cool.

Post by Stephen Kent
You suggested that network security is being pushed up the stack. In
some regards that is true, and in others it is not. User
authentication at the application layer is nothing new; it has been a
staple of host security since the days of multi-programming, time
sharing, etc. Is it a network security issue? We have examples of how
to make it more of a network security issue and reduce security,
e.g., the Unix rhost file model. If we use certs to authenticate
users does that make this a network security mechanism? I think not.
On the other hand use of SSL/TLS is certainly an example of moving
security up the stack (from layer 3 to layer 5). For some set of
contexts, an SSL solution may be more appropriate than an IPsec
solution. But, this WG decided to focus on IPsec, and so such
discussions are out of scope here.

Hmm, no, pushing session protection down the stack is in scope,
indirectly at least.

Post by Stephen Kent
There are multiple motivations for imposing security controls at
layer 3. Performance may be important in some instances, as you
suggest, but more often the motivations have to do with assurance and
management. Lower layer controls can be more secure that higher later
controls, given the unfortunate state of OS and application security.
Lower layer controls can be imposed (cleanly) at points other than
end systems, which simplifies management and also may improve
assurance. None of this says that application layer security is
redundant. However, it also does not suggest that trying to split
security services between layer 3 and layer 7, as some BTNS use cases
require, will necessarily work well.

If channel binding to IPsec channels were not feasible I'd not spend one
more ounce of energy on BTNS. Are you saying that they are not? Please
expand.

Post by Stephen Kent
When this WG was chartered I noted that there were multiple
constituencies, each with different goals, all of which hoped to use
the same or similar mechanisms to achieve these disparate goals. What
we are seeing here may be an example of that.

This past week on this thread we've been discussing a weakness in the
RFC4301 model. This somehow led me to explain, for the nth time, my use
case for BTNS. Now that you're on the record as acknowledging (above)
that use of wildcards in PAD entries represents a significant trade-off
maybe we can move on and discuss other things :)

Nico
--

Stephen Kent

2006-02-17 00:16:44 UTC

Nico,

I'm afraid your interpretation of my comments diverges from my intent
in several places. I'll try to clarify, using some different words
this time, and responding directly to your comments.

#1: do we agree on the "significance" of wildcard matching in the PAD?

Not exactly. What I said is that address-based packet filtering is a
necessary side effect of being able to operate at layer 3, especially
for intermediate systems like SGs. This says nothing about the use
of wildcards in the SPD or in the PAD. If we use only names (vs.
addresses) in the SPD and PAD for specifying entries that trigger SA
creation, we still can encounter problems due to address reuse:

- Alice (at address X) successfully creates an SA with Bob,
authenticating herself and matching a name-based PAD and SPD entry

- Carol comes along, is assigned address X, and tries to
create an SA with Bob, authenticating herself and matching a
different name-based PAD and SPD entry

- if both Alice and Carol connect to the same well-known port
on Bob's computer, and if both happen to choose the same local port,
we would now have two SAs that appear to be identical in terms of all
five traffic selector values. this poses a problem for Bob's IPsec
implementation, when it comes to mapping outbound traffic to the
right SA. (It's not a problem for inbound traffic, since such
traffic is demuxed based on SPI values chosen by Bob's IPsec
implementation). If Bob has a BITW IPsec implementation, and thus no
way to interact with Bob's computer to help resolve this ambiguity,
what should it do? The safe bet is probably to refuse Carol's SA
creation attempt, based on the reuse of X as the source address, to
be safe. This approach to resolving an address reuse problem of this
sort can be used irrespective of the reason that the conflict arises.

Michael's example was different in various details, but focused on
the potential problems caused by address reuse. He argued that there
was no good way to deal with this, since one approach allows for DoS
attacks against existing SAs, and the other discriminates against a
legitimate user who happens to get the same address assignment. I'm
in favor of door #2 here, and if I were the second user, I'd try to
renew my DHCP lease to get a different address.

My point here is that the type of problems we're discussing are not
really specific to the use of wildcards, and probably not specific to
the PAD design.

Because BTNS wants to create SAs for entities who possess no
authentication credentials, we cannot use the same set of criteria to
reject SAs that use addresses that collide with other SAs, as
suggested above. This exacerbates what I think is a relatively minor
issue. I'd call this a BTNS-generated problem.

#2 Did I say that pushing session protection down the stack is out of scope?

No. I explained why I disagreed with your comment that performance
was the motivation for pushing some security measures lower in the
stack, while other factors pushed security measures higher in the
stack. I also said that one could use SSL to address some (though not
all) of the use cases that were put forth as motivations for BTNS,
but that is out of scope for this WG, based on its current charter.

#3. Did I say that channel binding to IPsec SAs is infeasible.

Whether use of IPsec for channel binding is "feasible" is what the
output of this WG will determine. I suggested that when one tries to
split security service offerings between layers, one may create new
problems, problems that may not arise if one avoids crossing layer
boundaries in this fashion. Demonstrating the feasibility of using
IPsec for channel binding is the responsibility of those who propose
such uses.

What we have discussed in the thread that was restarted from last
year, was that under some circumstances, certain choices of PAD and
SPD entries might be problematic, in principle. Michael also noted
that we tend to not see this happening, due to various details of SG
implementations. So, what might be a minor weakness of the 4301
model, in principle, may be a more serious problem for BTNS. I
consider this a challenge for BTNS; I do not think it is a rationale
to make significant changes to IPsec, to accommodate BTNS.

Steve

Nicolas Williams

2006-02-17 02:10:03 UTC

Post by Stephen Kent
Nico,
I'm afraid your interpretation of my comments diverges from my intent
in several places. I'll try to clarify, using some different words
this time, and responding directly to your comments.
#1: do we agree on the "significance" of wildcard matching in the PAD?

I read the following to mean more or less "yes."

[text not quoted.]

Post by Stephen Kent
My point here is that the type of problems we're discussing are not
really specific to the use of wildcards, and probably not specific to
the PAD design.

They are specific to configurations that try to avoid tying specific IDs
to specific IP addresses. Such configurations will typically use
wildcard matching, I assume.

Post by Stephen Kent
Because BTNS wants to create SAs for entities who possess no
authentication credentials, we cannot use the same set of criteria to
reject SAs that use addresses that collide with other SAs, as
suggested above. This exacerbates what I think is a relatively minor
issue. I'd call this a BTNS-generated problem.

Whereas I focus on the "exacerbates" part above. If we disagree then
it's a matter of degree.

Post by Stephen Kent
#2 Did I say that pushing session protection down the stack is out of scope?
No. I explained why I disagreed with your comment that performance
was the motivation for pushing some security measures lower in the
stack, while other factors pushed security measures higher in the
stack.

Was I not clear that this was *my* (as opposed to *the*) motivation?

Post by Stephen Kent
I also said that one could use SSL to address some (though not
all) of the use cases that were put forth as motivations for BTNS,
but that is out of scope for this WG, based on its current charter.

You wrote "[b]ut, this WG decided to focus on IPsec, and so such
discussions are out of scope here." I took this to mean that you meant
that talking about splitting security between layers is out of scope.

Perhaps I read too much into that.

Post by Stephen Kent
#3. Did I say that channel binding to IPsec SAs is infeasible.
Whether use of IPsec for channel binding is "feasible" is what the
output of this WG will determine. I suggested that when one tries to
split security service offerings between layers, one may create new
problems, problems that may not arise if one avoids crossing layer
boundaries in this fashion. Demonstrating the feasibility of using
IPsec for channel binding is the responsibility of those who propose
such uses.

Agreed. I thought perhaps you might have some comments specifically
about the feasibility of channel bindings that you might share with us.

Post by Stephen Kent
What we have discussed in the thread that was restarted from last
year, was that under some circumstances, certain choices of PAD and
SPD entries might be problematic, in principle. Michael also noted
that we tend to not see this happening, due to various details of SG
implementations. So, what might be a minor weakness of the 4301
model, in principle, may be a more serious problem for BTNS. I
consider this a challenge for BTNS; I do not think it is a rationale
to make significant changes to IPsec, to accommodate BTNS.

I do agree that BTNS makes that "minor" weakness in the RFC4301 model
worse (and have said so now several times). I don't agree that that
weakness is so minor. Given a sufficiently large, sufficiently dynamic
network using IPsec (but not BTNS) that weakness approaches the same
severity as in the BTNS case. In so far as when not using BTNS one does
have a choice (strongly tie IDs and IP addresses or don't), this
weakness is minor, but only if said choice is realistic, which, I
suspect, it is not for sufficiently large&dynamic networks.

Again, I read this to mean that we're mostly in agreement.

Stephen Kent

2006-02-21 22:03:57 UTC

Post by Nicolas Williams
...

Post by Stephen Kent
My point here is that the type of problems we're discussing are not
really specific to the use of wildcards, and probably not specific to
the PAD design.

They are specific to configurations that try to avoid tying specific IDs
to specific IP addresses. Such configurations will typically use
wildcard matching, I assume.

I see your point. I was focusing on use of wild cards as indices
into the PAD or SPD, but you are correctly noting that the issues we
are discussing arise even when wild cards are NOT used as indices.
Anyway, I think the messages from Michael and Mohan note that these
sorts of issues are adequately addressed, in the current IPsec
environment, through the use of various ancillary mechanisms, some of
which are needed to deal with mobility, NAT traversal, etc.

Whereas I focus on the "exacerbates" part above. If we disagree then
it's a matter of degree.

yes, it may just be a matter of degree.

Was I not clear that this was *my* (as opposed to *the*) motivation?

no, you were not clear, but I understand now.

yes, I think so.

however, it is fair to say that I worry that the attempt to use layer
7 authentication in conjunction with layer 3 confidentiality,
integrity and access control may a continuing source of problems for
us.

Agreed. I thought perhaps you might have some comments specifically
about the feasibility of channel bindings that you might share with us.

nope, not for now.

I do agree that BTNS makes that "minor" weakness in the RFC4301 model
worse (and have said so now several times). I don't agree that that
weakness is so minor. Given a sufficiently large, sufficiently dynamic
network using IPsec (but not BTNS) that weakness approaches the same
severity as in the BTNS case. In so far as when not using BTNS one does
have a choice (strongly tie IDs and IP addresses or don't), this
weakness is minor, but only if said choice is realistic, which, I
suspect, it is not for sufficiently large&dynamic networks.
Again, I read this to mean that we're mostly in agreement.

We do agree on a number of points. What worries me is that the
possibility that one might look at the issues we have discussed and
use that to justify changing existing features of IPsec in order to
accommodate BTNS functionality. The form of the argument would be
"... the PAD and SPD model don't accommodate some scenarios where
address reuse by peers is a near term possibility, so let's change
them in a way that also addresses problems associated with BTNS ..."

My perspective is that the current PAD/SPD model works for IPsec,
when one looks at the rest of the mechanisms used in IPsec
deployments.

The challenge for the WG is to add BTNS functionality to the existing
IPsec architecture, without undermining the existing IPsec access
control model. It is not to change the architecture for authenticated
IPsec as a side effect of accommodating BTNS functionality.

Steve

Nicolas Williams

2006-02-21 22:14:53 UTC

Post by Nicolas Williams
Whereas I focus on the "exacerbates" part above. If we disagree then
it's a matter of degree.

yes, it may just be a matter of degree.

Yes, I think so.

[...]

Post by Nicolas Williams
Perhaps I read too much into that.

yes, I think so.
however, it is fair to say that I worry that the attempt to use layer
7 authentication in conjunction with layer 3 confidentiality,
integrity and access control may a continuing source of problems for
us.

Hmm, no, the problems we've been discussing in this thread do not arise
from trying to mix authentication at higher layers with session
protection at lower layers. In fact, channel binding is an answer to
those problems :)

Post by Nicolas Williams
Again, I read this to mean that we're mostly in agreement.

I don't recall any such proposals. The argument that I've made is
"these problems existed in the IPsec architecture to begin with, but
they are most significant when BTNS is in the picture..." followed by
"channel binding helps a lot" :)

Post by Stephen Kent
My perspective is that the current PAD/SPD model works for IPsec,
when one looks at the rest of the mechanisms used in IPsec
deployments.

I'm not sure that it does for sufficiently large and dynamic networks; I
have no experience deploying and managing IPsec in such environments, so
it's hard for me to say this authoritatively, but it does seem like a
logical conclusion.

Post by Stephen Kent
The challenge for the WG is to add BTNS functionality to the existing
IPsec architecture, without undermining the existing IPsec access
control model. It is not to change the architecture for authenticated
IPsec as a side effect of accommodating BTNS functionality.

Not only. We should want BTNS not to undermine the existing IPsec
architecture (I believe it does not, conceptually, nor concretely in my
latest I-D), but also ensure that BTNS has certain desirable properties.

BTNS as described in draft-btns-btns-00 is not good enough for my
purposes, nor does it meet the original requirement of protection
against MITM attacks after an initial exchange. But add draft-btns-
connection-latching-00, channel bindings and/or leap-of-faith (ugh) and
then it is good enough for some/most[/all?] of the stated purposes.

Nico
--

Stephen Kent

2006-02-21 23:24:05 UTC

Nico,

Post by Stephen Kent
however, it is fair to say that I worry that the attempt to use layer
7 authentication in conjunction with layer 3 confidentiality,
integrity and access control may a continuing source of problems for
us.

Maybe for end systems, but probably not for intermediate systems.
IPsec tries to offer roughly the same set of services for native
host, BITS, BITW, and SG implementations. That's why we need to not
assume channel binding is a solution for the full range of IPsec
contexts. The BTNS contexts that are the primary focus for you are
ones that can take advantage of native host implementations, and
that's fine. But since the scope of IPsec is much broader, we ought
not assume that we can rely on channel binding in general for Ipsec.

Post by Nicolas Williams
...
I don't recall any such proposals. The argument that I've made is
"these problems existed in the IPsec architecture to begin with, but
they are most significant when BTNS is in the picture..." followed by
"channel binding helps a lot" :)

OK.

Post by Stephen Kent
My perspective is that the current PAD/SPD model works for IPsec,
when one looks at the rest of the mechanisms used in IPsec
deployments.

well, the folks who have experience deploying IPsec today don't seem
to regard the problems we've explored as significant, as evidenced by
a lack of feedback in the IPsec WG as we developed 4301. (These folks
DID provide feedback that caused other changes to the architecture
and that motivated the features set of IKE v2, so they were not
silent.) But, you may argue that the current environment for
deployment is not as dynamic as what you envision, and thus this is
not a good basis for evaluating the adequacy of the current model.
However, the mobile IP folks have been developing solutions based on
4301, in their context, which is very dynamic, so I may disagree with
your conclusion.

Not only. We should want BTNS not to undermine the existing IPsec
architecture (I believe it does not, conceptually, nor concretely in my
latest I-D), but also ensure that BTNS has certain desirable properties.
BTNS as described in draft-btns-btns-00 is not good enough for my
purposes, nor does it meet the original requirement of protection
against MITM attacks after an initial exchange. But add draft-btns-
connection-latching-00, channel bindings and/or leap-of-faith (ugh) and
then it is good enough for some/most[/all?] of the stated purposes.

I was not suggesting that any specific draft on the table has the
problems I allude to above. I was making a general statement about
how the WG ought to proceed when viewing any proposals.

Steve

Joe Touch

2006-02-17 15:43:55 UTC

Stephen Kent wrote:
....

...I also said that one could use SSL to address some (though not
all) of the use cases that were put forth as motivations for BTNS,
but that is out of scope for this WG, based on its current charter.

Since this point has been raised on repeated occasions:

BTNS was motivated by the need to protect the network and transport
headers. Connection-disruption attacks (RST attacks in specific, which
also include ACK and other transport header attacks) were
the primary case, and SSL does not protect against those. The ability to
reuse techniques across different transport and higher layers was also
sought, and for SSL again does not apply.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20060217/e792b240/signature.bin

Stephen Kent

2006-02-21 16:50:09 UTC

Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig684BFD82142EDE85608F2E7E"
....

BTNS was motivated by the need to protect the network and transport
headers. Connection-disruption attacks (RST attacks in specific, which
also include ACK and other transport header attacks) were
the primary case, and SSL does not protect against those. The ability to
reuse techniques across different transport and higher layers was also
sought, and for SSL again does not apply.
Joe

Joe,

As I noted elsewhere in that message from which you extracted the
quote, there are multiple, distinct constituencies for BTNS. Not all
of them have the requirement you cite above re protection against
transport layer attacks. So, it is inappropriate to make a broad
statement about BTNS motivations without acknowledging this diversity.

Also, SSL/TLS now is defined to support UDP, so the traditional
argument about needing to use IPsec to accommodate other than TCP is
no longer valid.

Steve

Nicolas Williams

2006-02-21 19:17:55 UTC

Post by Stephen Kent
Also, SSL/TLS now is defined to support UDP, so the traditional
argument about needing to use IPsec to accommodate other than TCP is
no longer valid.

For the record, I've not made that argument.

Nico
--

Joe Touch

2006-02-21 19:26:41 UTC

Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig684BFD82142EDE85608F2E7E"
....

Whatever BTNS is _now_ motivated by, it WAS motivated by the need for
transport protection in the absence of a-priori keys (infrastructure or
predeployed).

As to the reasons you cited in your original quote:
1- performance
2- security of the software system
3- lower layer can be done elsewhere in the system
3- using BTNS as a place to explore split-layer security

For which of these would SSL address a BTNS use case?

Also, SSL/TLS now is defined to support UDP, so the traditional argument
about needing to use IPsec to accommodate other than TCP is no longer
valid.

There are more transport protocols than just TCP and UDP. See
http://www.iana.org/assignments/protocol-numbers for a complete list ;-)

Joe

Michael Richardson

2006-02-11 00:17:22 UTC

Post by Nicolas Williams
Keep in mind Joe's point that this is a problem for IPsec even without
BTNS in the picture. A PAD entry that allows road warriors access to
dynamically allocated addresses will allow road warriors to steal each
other's traffic in the same way as we've discussed could happen with
BTNS.

Stephen> I don't think this discussion has provided a good example to
Stephen> illustrate the problem in question. I'm guessing that the
Stephen> concern begins with the notion that one needs to dynamically
Stephen> update or create a PAD entry to accommodate road
Stephen> warriors. However, there has been no discussion in IPsec to
Stephen> suggest that dynamic PAD entries are needed to support road
Stephen> warriors.

Stephen> A PAD entry might identify the set of all road warriors for a
Stephen> company by a wild card name, e.g., *@bbn.com. The authorization
Stephen> data for the entry might say that these individuals have certs
Stephen> that can be validated using the CA cert for BBN. The entry would
Stephen> also specify that the IKE ID (not the road warrior's source
Stephen> address) be used for SPD matching. The SPD entry for these folks
Stephen> would be tagged with the name. Section 4.4.1.1 specifically
Stephen> gives the road warrior case as a motivation for the use of names
Stephen> to specify SPD entries, and says how to take the IP address of
Stephen> the road warrior (as the initiator) and use it as the remote
Stephen> address for the SPD entry (in a sort of PFP fashion). This
Stephen> should avoid the hijacking concern alluded to above.

RW A arrives, sets up a tunnel. Let's say it is:
205.150.200.225/32 -> 205.150.200.160/28 => 205.150.200.134/32
leftsubnet rightsubnet gateway

(this is a tunnel that I have up right now. It protects traffic across
my local wireless network destined to the subnet my mail server is on)
I have a policy that says that @marajade.sandelman.ca may connect from
any IP, building a tunnel from that IP to 205.150.200.160/28. (doesn't work
when I'm behind a NAT, because I propose an IP which isn't my outer IP.)

RW B now arrives. It's my colleague. He quickly pulls the battery out of my
laptop while I'm in the washroom. Then he brings up:

205.150.200.225/32 -> 205.150.200.160/28 => 205.150.200.134/32
leftsubnet rightsubnet gateway

he has the same policy as I do, only a different FQDN with a different key
defined. He gets "my" traffic. Well, it's hard to argue who was in the
right.

Stephen> Mike Richardson discussed how 2401 implementations (the PAD
Stephen> concept was not part of the old standard) supported road
Stephen> warriors, in the BTNS meeting at IETF64. Mike, how do you
Stephen> envision using a PAD-equipped IPsec to accommodate road
Stephen> warriors? Do you see a need for dynamic PAD entries?

I don't seem to remember my argument.
Obviously I'm reading this thread some 8 weeks after it was written. Sorry,
life.

In a host-host BTNS system, with IPsec integrated into the stack and
connection latching, the TCP/UDP layer asks "please send this packet with
SA#xxx" and discovers either that the SA is gone, or if not gone, then it
goes out encrypted to RW A, which RW B can't decrypt.

Happens that I'm implementing connection latching for UDP in openswan this
past month, so that we can deal with having two identically numbered l2tp
clients behind two different NATs. (i.e. two windows laptops are both
192.168.1.101 behind their commodity NAPT box).
This is one reason I'm not reading lists.

- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Nicolas Williams

2006-02-11 08:57:41 UTC

Post by Michael Richardson
In a host-host BTNS system, with IPsec integrated into the stack and
connection latching, the TCP/UDP layer asks "please send this packet with
SA#xxx" and discovers either that the SA is gone, or if not gone, then it
goes out encrypted to RW A, which RW B can't decrypt.

Better:

- transport, on output, says "please send this packet protected by an
SA that matches the characteristics of the SA originally used for
latching (this includes crypto algs AND peer IDs).

- on input, IPsec/IP tell the transport "this packet arrived on this
SA" and then the transport checks that the SA matches the latched
characteristics

- the actual latch is constructed from the characteristics of the SA
that protected the first packet sent or received on the given
connection (e.g., the SYN packet, in the case of TCP).

Nico
--

Stephen Kent

2005-12-06 17:51:55 UTC

Post by Joe Touch
...
The details I'm glossing over are the ones I'm presuming exist for
conventional IPsec use.
Otherwise, what prevents the PAD from changing during a connection, and
the resulting authentication for an endpoint from being in flux?
If these details aren't already there, then there is certainly a large
amount of work to be done - but it is not BTNS-specific.
Joe

Joe,

The PAD was designed to fill a gap between the authorization data
that IKE deals with, and the SPD, and to fill in gaps in the
standards dealing with management of IKE authorization data. When I
developed the PAD, in response to discussions in the pki4ipsec WG,
nobody suggested that the PAD would be other than slowly changing. SA
don't last forever, so if we assume a slowly changing PAD (very
static in many contexts), then there was no need to worry about these
issues. Hence no provisions were made to accommodate the implications
of such changes on extant SAs.

Steve

Joe Touch

2005-12-06 18:10:55 UTC

Joe,
The PAD was designed to fill a gap between the authorization data that
IKE deals with, and the SPD, and to fill in gaps in the standards
dealing with management of IKE authorization data. When I developed the
PAD, in response to discussions in the pki4ipsec WG, nobody suggested
that the PAD would be other than slowly changing. SA don't last forever,
so if we assume a slowly changing PAD (very static in many contexts),
then there was no need to worry about these issues. Hence no provisions
were made to accommodate the implications of such changes on extant SAs.
Steve

Hi, Steve,

While I understand an appreciate this, even 'slowly changing' allows for
change, and change allows a new entity with different authoriziation
credentials to affect active SAs.

Is it possible to copy the relevent PAD info used to authorize
establishment of the SA into the SA itself, so that such changes could
not be used maliciously?

Joe

Stephen Kent

2005-12-07 14:49:47 UTC

Joe,

Post by Joe Touch
...

Joe,
The PAD was designed to fill a gap between the authorization data that
IKE deals with, and the SPD, and to fill in gaps in the standards
dealing with management of IKE authorization data. When I developed the
PAD, in response to discussions in the pki4ipsec WG, nobody suggested
that the PAD would be other than slowly changing. SA don't last forever,
so if we assume a slowly changing PAD (very static in many contexts),
then there was no need to worry about these issues. Hence no provisions
were made to accommodate the implications of such changes on extant SAs.
Steve

Hi, Steve,
While I understand an appreciate this, even 'slowly changing' allows for
change, and change allows a new entity with different authoriziation
credentials to affect active SAs.

The 4301 (nee 2401bis) text does not say that the SAD or SPD-S cache
should be searched and affected entries reverified when a PAD entry
changes. This is in contrast to the SPD, where 4.4.1 notes that SPD
changes SHOULD cause a recheck of active SAs and allow an admin to
specify whether affected SAs should persist or be deleted.

In part the different is a result of the fact that changes to PAD
entries can affect attributes of an IKE peer that need not have any
effect on extant SAs. For example, if I change the IKE ID or the
authentication credentials for a peer, or the gateway location info,
that need not imply a need to recheck child SAs created relative to
that peer. Only if the change is to the child SA ID/address
constraints (relative to SPD matching) might it make sense to
consider revalidation of extant SAs.

What if a new PAD entry is created? Because the PAD is ordered, it
could be very complex to determine if a newly created entry affects
extant SAs, or if it were even the intent of the change to affect
them.

These considerations, plus the notion that the PAD is fairly static,
caused us to not include text analogous to the SPD text in 4.4.1.
Section 4.4.3.4 describes when the PAD is consulted. It is consulted
during the initial IKE exchange, in support of IKE peer
authentication and child SA constraints checking. It is also
consulted during subsequent CREATE_CHILD_SA exchanges, for child SA
constraints checking.

If an extant SA needs to be rekeyed, IKE is invoked to effect the
rekey. The PAD should be checked as a side effect of creating a child
SA, and because a rekey creates a new child SA, the (current) PAD
should be checked at that time. So in that sense, a change to the
PAD, in terms of a modification to a PAD entry, has an opportunity to
affect an extant SA (when it is rekeyed).

There is some ambiguity here, in that the text does not say how to
recheck the PAD for subsequent CREATE_CHILD_SA exchanges. If an
implementation maintains a back pointer to the PAD from each IKE SA,
and a back pointer to the IKE SA from each child SA, then rechecking
the PAD for a rekey is easy. But what if the IKE SA has been deleted?
The PAD is not designed to be searched based on traffic selectors for
child SAs, but rather on IKE IDs.

I assume this is the sort of complexity that Sam had in mind when he
said that use of a dynamic PAD requires a lot of thought.

Post by Joe Touch
Is it possible to copy the relevent PAD info used to authorize
establishment of the SA into the SA itself, so that such changes could
not be used maliciously?

Changes to the PAD are made by an authorized admin, just like changes
to the SPD. So I don't think the term "malicious" applies here.

Steve

Pekka Nikander

2005-12-05 13:23:05 UTC

Post by Sam Hartman
It seems like we're going to need something like mini-leap-of-faith in
which we require that the identity of a peer remain constant for
traffic protected by a btns SA.

I agree that such a feature would be very useful.

Post by Sam Hartman
1) Establish some sort of timer for packets going over the SA. If the
connection appears to still be alive, then require that we maintain
the same peer identity.
2) If for some reason we have to drop such an SA, install a temporary
discard rule for some period of time to make sure that we kill off
the connection.
.... At this point though I'd like to hear what people think
about the required behavior in non-native implementations.

What you describe above, with suitable administrative interfaces,
sounds fine to me. But then, personally, I am not that interested
in non-native implementations. Hence, I would also be happy to
see the threats just documented, without requiring that non-native
BTNS provide the equivalent of connection latching.

--Pekka

Stephen Kent

2005-12-05 16:36:27 UTC

I'll just note that 2401bis (soon to be issued as 4301, yeah!)
adopts a processing model that relies on decorrelation to simplify
and speed up processing in SG and BITW implementations. Making
frequent changes to the SPD, as suggested in your message, may be
computationally costly.

Steve

Sam Hartman

2005-12-05 17:13:16 UTC

Stephen> I'll just note that 2401bis (soon to be issued as 4301,
Stephen> yeah!) adopts a processing model that relies on
Stephen> decorrelation to simplify and speed up processing in SG
Stephen> and BITW implementations. Making frequent changes to the
Stephen> SPD, as suggested in your message, may be computationally
Stephen> costly.

noted. do you have any other approaches you think we should look at?

--Sam

Stephen Kent

2005-12-05 18:42:22 UTC

Post by Sam Hartman
Stephen> I'll just note that 2401bis (soon to be issued as 4301,
Stephen> yeah!) adopts a processing model that relies on
Stephen> decorrelation to simplify and speed up processing in SG
Stephen> and BITW implementations. Making frequent changes to the
Stephen> SPD, as suggested in your message, may be computationally
Stephen> costly.
noted. do you have any other approaches you think we should look at?
--Sam

I think David's suggestion, to manage the inactivity timeout via the
SAD, vs. the SPD, might be good.

Steve

Sam Hartman

2005-12-05 21:32:59 UTC

Post by Sam Hartman
noted. do you have any other approaches you think we should
look at?
--Sam

Stephen> I think David's suggestion, to manage the inactivity
Stephen> timeout via the SAD, vs. the SPD, might be good.

Ok. I thought I tried to be clear I was talking about what I wanted
to accomplish not about how we actually accomplish. it. I'd rather
not get stuck on details of where the inactivity timer goes at this
point and I'm sorry I included details that were not required in my
talking peace.

--Sam

Nicolas Williams

2005-12-05 18:36:24 UTC

Post by Stephen Kent
I'll just note that 2401bis (soon to be issued as 4301, yeah!)
adopts a processing model that relies on decorrelation to simplify
and speed up processing in SG and BITW implementations. Making
frequent changes to the SPD, as suggested in your message, may be
computationally costly.

Even when done only on BITS or native implementations?

Sam Hartman

2005-12-05 19:29:42 UTC

Nicolas> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent

I'll just note that 2401bis (soon to be issued as 4301, yeah!)
adopts a processing model that relies on decorrelation to
simplify and speed up processing in SG and BITW
implementations. Making frequent changes to the SPD, as
suggested in your message, may be computationally costly.

Nicolas> Even when done only on BITS or native implementations?

As I understand it, it is an optimization any IPsec implementation may
choose to use. As best I can tell the text is constructed so that it
is purely a performance issue. So, you can choose to do it in your
implementation; lookups get faster and changes get slower.

You could presumably choose to do anything else provided that it was
externally the same.

Stephen Kent

2005-12-05 20:14:09 UTC

Post by Sam Hartman
Nicolas> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent

I'll just note that 2401bis (soon to be issued as 4301, yeah!)
adopts a processing model that relies on decorrelation to
simplify and speed up processing in SG and BITW
implementations. Making frequent changes to the SPD, as
suggested in your message, may be computationally costly.

Nicolas> Even when done only on BITS or native implementations?
As I understand it, it is an optimization any IPsec implementation may
choose to use. As best I can tell the text is constructed so that it
is purely a performance issue. So, you can choose to do it in your
implementation; lookups get faster and changes get slower.
You could presumably choose to do anything else provided that it was
externally the same.

You are correct.

Steve

Stephen Kent

2005-12-05 20:13:04 UTC

Even when done only on BITS or native implementations?

I said SGs and BITW. BITS is also an issue.

Native, end-system implementations, because they can take advantage
of the socket interface info, don't benefit as much from
de-correlations, so I don't see this as an issue in that context.

Steve

Black_David at emc.com ()

2005-12-05 17:28:15 UTC

Steve,

Perhaps this ought to be done via the SAD rather than the SPD?
Using an SAD entry for a "might be dead, but not 100% sure" SA has
some resemblances to what's already necessary to deal with dead peers,
and inflicting temporary discard rules on the SPD is going to make
it significantly harder to check whether the decorrelated SPD that
is being used actually implements the intended policy.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david at emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------

Stephen Kent

2005-12-05 18:07:04 UTC

Post by Black_David at emc.com ()
Steve,

Good suggestion.

Steve

Joe Touch

2005-12-05 23:09:01 UTC

Post by Sam Hartman
Nico has partially described a feature called connection latching that
allows a native mode IPsec implementation to guarantee that the same
peer ID is used for every packet sent over a particular connection.
It seems fairly clear that BTNS benefits significantly from this
technology.
The applicability statement makes the claim that BTNS protects against
on-path attacks after the connection is established. In order to do
that we need to have some form of something like connection latching
even in non-native implementations.
If we do nothing then the SA from one BTNS peer could be replaced by a
SA from another BTNS peer and the traffic on the connection would be
funneled over that SA.

Can't that happen with existing IPsec already? i.e., to replace one SA
with another, signed in different ways? (different CAs, etc.)

Post by Sam Hartman
It seems like we're going to need something like mini-leap-of-faith in
which we require that the identity of a peer remain constant for
traffic protected by a btns SA.

Isn't that a requirement of existing IPsec implementations already, as
per above?

Joe

Sam Hartman

2005-12-05 23:35:27 UTC

Post by Sam Hartman
Nico has partially described a feature called connection
latching that allows a native mode IPsec implementation to
guarantee that the same peer ID is used for every packet sent
over a particular connection. It seems fairly clear that BTNS
benefits significantly from this technology.
The applicability statement makes the claim that BTNS protects
against on-path attacks after the connection is established.
In order to do that we need to have some form of something like
connection latching even in non-native implementations.
If we do nothing then the SA from one BTNS peer could be
replaced by a SA from another BTNS peer and the traffic on the
connection would be funneled over that SA.

Joe> Can't that happen with existing IPsec already? i.e., to
Joe> replace one SA with another, signed in different ways?
Joe> (different CAs, etc.)

Yes, but only when such a replacement is consistent with the PAD.
I.E. in general it needs to be the same peer within the definitions of
same based on trust anchors etc.

Post by Sam Hartman
It seems like we're going to need something like
mini-leap-of-faith in which we require that the identity of a
peer remain constant for traffic protected by a btns SA.

Joe> Isn't that a requirement of existing IPsec implementations
Joe> already, as per above?

No.

basically it can happen with existing IPsec implementations but is not
actually a security problem for anything besides BTNS.

Joe Touch

2005-12-05 23:59:11 UTC

Post by Sam Hartman

Post by Sam Hartman
Nico has partially described a feature called connection
latching that allows a native mode IPsec implementation to
guarantee that the same peer ID is used for every packet sent
over a particular connection. It seems fairly clear that BTNS
benefits significantly from this technology.
The applicability statement makes the claim that BTNS protects
against on-path attacks after the connection is established.
In order to do that we need to have some form of something like
connection latching even in non-native implementations.
If we do nothing then the SA from one BTNS peer could be
replaced by a SA from another BTNS peer and the traffic on the
connection would be funneled over that SA.

Joe> Can't that happen with existing IPsec already? i.e., to
Joe> replace one SA with another, signed in different ways?
Joe> (different CAs, etc.)
Yes, but only when such a replacement is consistent with the PAD.
I.E. in general it needs to be the same peer within the definitions of
same based on trust anchors etc.

The PAD should be established when you connect (i.e., as a result of the
IKE, rather than to verify the IKE), and leave it in place until the
association is explicitly torn down. That entry would then prevent
hijacking as per above the same way as any other PAD entry, right?

Post by Sam Hartman

Post by Sam Hartman
It seems like we're going to need something like
mini-leap-of-faith in which we require that the identity of a
peer remain constant for traffic protected by a btns SA.

Joe> Isn't that a requirement of existing IPsec implementations
Joe> already, as per above?
No.
basically it can happen with existing IPsec implementations but is not
actually a security problem for anything besides BTNS.

The security issue seems to be whether the PAD should be modified while
there are SAs open that are governed by that PAD. I didn't see whether
2401bis addressed that issue, but it seems independent of BTNS at that
point.

Joe

Nicolas Williams

2005-12-06 00:10:47 UTC

Sam> Yes, but only when such a replacement is consistent with the PAD.
Sam> I.E. in general it needs to be the same peer within the
Sam> definitions of same based on trust anchors etc.
The PAD should be established when you connect (i.e., as a result of the
IKE, rather than to verify the IKE), and leave it in place until the
association is explicitly torn down. That entry would then prevent
hijacking as per above the same way as any other PAD entry, right?

The problem lies in "until the association is explicitly torn down."

If that effectively means "forever" or "until someone complains" then
that's not good.

That's what would happen if the peer making the leap-of-faith PAD entry
allows leap-of-faith PAD entries to be made for dynamically addressed
nodes .

No, the SAs might expire due to lack of traffic, but the traffic flows
might continue to exist, logically. Thus allowing the PAD entry to be
removed as a result of SA expiration would be bad.

Problem: How can non-native IPsec implementations know whether the
associated traffic flows continue to exist?

Problem: Given applications that use multiple connections between the
same two peers, how can even native IPsec implementations know
whether the associated traffic flows continue to exist?

Nico
--

Joe Touch

2005-12-06 00:16:59 UTC

The problem lies in "until the association is explicitly torn down."
If that effectively means "forever" or "until someone complains" then
that's not good.
That's what would happen if the peer making the leap-of-faith PAD entry
allows leap-of-faith PAD entries to be made for dynamically addressed
nodes .

No, the SAs might expire due to lack of traffic, but the traffic flows
might continue to exist, logically. Thus allowing the PAD entry to be
removed as a result of SA expiration would be bad.
Problem: How can non-native IPsec implementations know whether the
associated traffic flows continue to exist?
Problem: Given applications that use multiple connections between the
same two peers, how can even native IPsec implementations know
whether the associated traffic flows continue to exist?
Nico

Don't all these problems exist for existing PAD entries?

Or is the PAD assumed static for all time? Any changes to the PAD can
cause similar problems...

Joe

Nicolas Williams

2005-12-06 00:21:28 UTC

Post by Joe Touch
Don't all these problems exist for existing PAD entries?

Maybe for some of them, but certainly not all.

If you have peers asserting IP address type IDs and they have certs with
iPAddress subject alternative names and you can validate said certs to
some trust anchor specified in the PAD entry, then you can have a PAD
entry that matches any peer asserting an IP address ID that won't have
this problem.

Post by Joe Touch
Or is the PAD assumed static for all time? Any changes to the PAD can
cause similar problems...

Yes, changes to the PAD can cause problems.

Connection latching mitigates this, to some extent (i.e., not
necessarily for applications that use many connections between two
peers).

Nico
--

Mohan Parthasarathy

2006-02-17 17:57:38 UTC