Subject: [anonsec] SAB without connection latching

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 10 Feb 2006 19:17:22 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:
    >> 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., [email-masked]. 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"); [

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 10 Feb 2006 20:03:54 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:
    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.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat, 11 Feb 2006 02:57:41 -0600

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat, 11 Feb 2006 03:31:25 -0600

> possibly able to make connections, not just your set of trusted road

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!

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

> least explain how to write the right SPD entries for various NAT-T+transport

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

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 13 Feb 2006 16:29:33 -0500

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 13 Feb 2006 23:56:47 -0600

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

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

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 15 Feb 2006 16:27:42 -0500

>you had.  Often it's easier to not do static address assignments to

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

>sufficiently large PKI the distinction isn't all that large).

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 15 Feb 2006 16:42:34 -0600

On Wed, Feb 15, 2006 at 04:27:42PM -0500, Stephen Kent wrote:
> An obvious question is how such addresses are assigned.  [...]

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

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

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 16 Feb 2006 13:12:35 -0500

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 16 Feb 2006 14:27:10 -0600

> layers, e.g., address reassignment.

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

> discussions are out of scope here.

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

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

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

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 16 Feb 2006 19:16:44 -0500

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 16 Feb 2006 20:10:03 -0600

> #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.]

> really specific to the use of wildcards, and probably not specific to 

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.

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

> stack.

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

>        I also said that one could use SSL to address some (though not 

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.

> IPsec for channel binding is the responsibility of those who propose 

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

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 17 Feb 2006 07:43:55 -0800

Stephen Kent wrote:
....
> ...I also said that one could use SSL to address some (though not 

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

---

From: mohanp at sbcglobal.net (Mohan Parthasarathy)
Date: Fri, 17 Feb 2006 09:57:38 -0800 (PST)

>   Does it refuse? Which is correct?
This was extensively discussed in MOBIKE (check the
archives
and also the appendix of the protocol draft). As you
mentioned
above, you need to handle this because of NAT where
the SG
sees the same address for two hosts behind the NAT. 
Some implementations (e.g. linux) may not work well
today.
But if you support NAT traversal, you better support
this i.e
both hosts should be able to create the SAs. Note that
the hosts get different "inner" addresses.

-mohan

> _______________________________________________
>

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 21 Feb 2006 11:50:09 -0500

At 7:43 AM -0800 2/17/06, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig684BFD82142EDE85608F2E7E"
>
>
>
>Stephen Kent wrote:
>....

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Feb 2006 13:17:55 -0600

> argument about needing to use IPsec to accommodate other than TCP is 

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

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 21 Feb 2006 11:26:41 -0800

Stephen Kent wrote:
> 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.

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

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 21 Feb 2006 17:03:57 -0500

At 8:10 PM -0600 2/16/06, Nicolas Williams wrote:
>...

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

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.

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

>about the feasibility of channel bindings that you might share with us.

nope, not for now.

>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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Feb 2006 16:14:53 -0600

> yes, it may just be a matter of degree.

Yes, I think so.

[...]
> integrity and access control may a continuing source of problems for 

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

> them in a way that also addresses problems associated with BTNS ..."

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" :)

> when one looks at the rest of the mechanisms used in IPsec 

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.

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

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 21 Feb 2006 18:24:05 -0500

Nico,

>protection at lower layers.  In fact, channel binding is an answer to

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.

>"channel binding helps a lot" :)

OK.

>it's hard for me to say this authoritatively, but it does seem like a

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.

>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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Feb 2006 18:00:51 -0600

> Maybe for end systems, but probably not for intermediate systems. 

BTNS for SG use is out of scope, as I recall...

...but even if it is in scope, connection latching[*] (though there is
no ULP connection to speak of) can still work, as can channel binding.

[*]  See draft-btns-connection-latching-00, when it appears in the I-D
     directory.

Think of having a layer 7 protocol for authenticating to the SG and the
SG enabling packet forwarding only once the client is authenticated;
conversely the tunnel (and latch) are to be torn down only when the
client agrees or a sufficiently long inactivity timer expires.  The
latch and inactivity timer prevent theft of a client's packet flows (the
attack that Michael described a few days ago).

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 22 Feb 2006 17:03:26 -0500

>BTNS for SG use is out of scope, as I recall...

I really don't recall, and I'm too lazy to check the charter right 
now :-).  But IF one were to suggest changes to IPsec that are 
designed to address problems other than those induced by BTNS 
functionality, THEN such changes must be considered in the context of 
all IPsec deployment options as defined in 4301, i.e., native host, 
BITW, BITS, and SG.

>attack that Michael described a few days ago).

This almost sounds like a MIDCOM-style solution. I think this would 
be a very big change to the current IPsec architecture, probably out 
of scope for this WG.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 22 Feb 2006 17:04:42 -0500

Joe,

>transport protection in the absence of a-priori keys (infrastructure or

I agree that was your motivation, and you explained that clearly. But 
we now have a WG with a broader set of goals, and thus the original 
motivation you cite is not the only one.

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

There are a number of outboard, SSL accelerator products that clearly 
support #1 above. The use of such outboard accelerators could improve 
crypto security relative to the application layer, although that 
depends on the crypto options available to the application. The fact 
that these accelerators are analogous to BITW IPsec implementations 
also allows them to avoid some of the OS security pitfalls that 
accrue to an application running on the most popular OS, which also 
supports #2 above. Although it is an awful protocol layering 
violation, outboard accelerators for SSL are regularly placed as 
intermediate systems, just like IPsec SG, consistent with (the first) 
#3 above.  The second bullet #3 above is NOT something I cited as a 
motivation for layer 3 security, so it seems out of place on your 
list.

>http://www.iana.org/assignments/protocol-numbers for a complete list ;-)

The vast majority of the protocols on that list are rarely used or 
obsolete (a limiting case of rarely used).  For example, when do you 
think the last packet radio measurement packet (#21) was sent :-)? 
This is not a very relevant list for purposes of our discussion, 
although I admit there are transport protocols other than TCP and 
UDP. The relevant question is which ones are of interest to the 
potential set of BTNS users.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 22 Feb 2006 14:47:04 -0800

> be a very big change to the current IPsec architecture, probably out 

I agree, however I wonder if that sort of issue was already present in
the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving
 on different links with the same IP address didn't collide on SPI
allocations).

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 22 Feb 2006 14:52:40 -0800

Stephen Kent wrote:
> I agree that was your motivation, and you explained that clearly. But we
> now have a WG with a broader set of goals, and thus the original

Steve,

AOK; it'd be useful clarify the broader set since it relates to the P&AS.

> crypto security relative to the application layer, although that depends
> on the crypto options available to the application. The fact that these
> accelerators are analogous to BITW IPsec implementations also allows
> them to avoid some of the OS security pitfalls that accrue to an
> application running on the most popular OS, which also supports #2
> above. Although it is an awful protocol layering violation, outboard
> accelerators for SSL are regularly placed as intermediate systems, just
> like IPsec SG, consistent with (the first) #3 above.  The second bullet
> #3 above is NOT something I cited as a motivation for layer 3 security,
> so it seems out of place on your list.

It wasn't my list; it was a summary of yours (with my misnumbering):
(note that the 4th one, the second #3 above, was listed in the negative
in your list):

- -- quoted from original mail, "*" inserted to highlight the items above:

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.

- --

None of these are solved by SSL; SSL has corresponding solutions for the
first three, but in no case does it protect the transport connection.

I.e., what is the motivation for BTNS that does not include - if not
focus - on transport protection?

>> argument
> think the last packet radio measurement packet (#21) was sent :-)? This
> is not a very relevant list for purposes of our discussion, although I
> admit there are transport protocols other than TCP and UDP. The relevant
> question is which ones are of interest to the potential set of BTNS users.

RTP is used for VoIP, which is becoming more common, as we hope will be
DCCP and SCTP. Then there are infrastructure protocols, like
ISIS-over-IP. i.e., not all of these are as likely to be used as others,
but there are more than 2.

However, SSL/TLS is a red-herring here anyway; it doesn't protect the
transport layer. TCP/MD5 is the comparable protocol for potential BTNS
users; there is no equivalent for UDP, and we'd need to reinvent it for
every other transport protocol in use (at least the handful above) as well.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 22 Feb 2006 16:56:06 -0600

> be a very big change to the current IPsec architecture, probably out 

'Change' is probably not the right word here; perhaps 'addition' would
be more appropriate.  But let's leave this out of scope, if it isn't
already.

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 23 Feb 2006 18:07:01 -0500

Joe,

>  on different links with the same IP address didn't collide on SPI

This might be a problem if each interface had a distinct IPsec 
implementation, not just a distinct SPD. However, I know of no such 
devices, and thus no instances of problems of this sort. With just 
one SAD for a BITW device, SPI assignment is centralized and thus the 
problem you cite is avoided.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 23 Feb 2006 15:10:41 -0800

Stephen Kent wrote:
> devices, and thus no instances of problems of this sort. With just one
> SAD for a BITW device, SPI assignment is centralized and thus the

Just curious - without diving into 4301 myself - is that spec'd in 4301?

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 23 Feb 2006 18:18:23 -0500

Joe,

>(note that the 4th one, the second #3 above, was listed in the negative

OK, the reversed polarity of the last item was confusing to me.

>first three, but in no case does it protect the transport connection.

You are right that SSL/TLS does not protect the transport layer, but 
that was not what you asked me to address via that list.

>focus - on transport protection?

Channel binding functionality does not explicitly demand transport 
layer protection.

>but there are more than 2.

And RTP users developed SRTP as an alternative to using IPsec, so ...

>every other transport protocol in use (at least the handful above) as well.

I agree that the TCP/MD5 hack offers transport layer integrity, but 
that does not make it comparable to either IPsec or SSL/TLS.

My recollection from the BOF was that only some of the cited 
motivations for BTNS explicitly cite transport layer protection. When 
applications want to use lower layer security mechanisms to enable 
higher performance via off-loading crypto to a different processor, 
that can be achieved via SSL/TLS, for example.

I think the crux of our possible disagreement is that you see every 
BTNS motivation as demanding protection for the transport layer 
protocol, whole I see only one of cited motivations as emphasizing 
this requirement.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 23 Feb 2006 18:23:03 -0500

At 3:10 PM -0800 2/23/06, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Stephen Kent wrote:
>>  Joe,
>>
>>>  ...
>>>   >
>>>
>>>>

4301 allows wither implementation approach, but warns folks that if 
each interface has a distinct SAD, then it will not generally be 
possible to treat the different interfaces as multi-homed instances 
of the same entity.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 23 Feb 2006 15:28:04 -0800

Stephen Kent wrote:
...
> Channel binding functionality does not explicitly demand transport layer
> protection.

Channel binding isn't a motivation for BTNS. BTNS is a place where we
are exploring it.

> And RTP users developed SRTP as an alternative to using IPsec, so ...

That's what I'd like to avoid by encouraging using a cross-transport
solution, e.g., at the network layer.

> I agree that the TCP/MD5 hack offers transport layer integrity, but that
> does not make it comparable to either IPsec or SSL/TLS.

We have been talking about BTNS use cases; as I noted before, one (the
original one, and at least one of the current ones) is to protect the
transport layer.

I *fully* agree with the fact that TCP/MD5 doesn't offer the same
protection as IPsec, but it does protect the transport layer. That
differentiates it from TLS.

> My recollection from the BOF was that only some of the cited motivations
> for BTNS explicitly cite transport layer protection. When applications
> want to use lower layer security mechanisms to enable higher performance
> via off-loading crypto to a different processor, that can be achieved
> via SSL/TLS, for example.

Performance issues were taken off the table at the BOF altogether. I
agree with the rest of the conclusion above, though, but it doesn't seem
relevant to BTNS.

> I think the crux of our possible disagreement is that you see every BTNS
> motivation as demanding protection for the transport layer protocol,
> whole I see only one of cited motivations as emphasizing this requirement.
> 
> Steve

I agree completely; I'm still trying to understand a motivation that
doesn't include that requirement, though. The only ones above that seem
to be put forth (correct if wrong, please) are:

	- performance offloading
		but performance was taken off the table for BTNS
		during the BOF

	- channel binding
		which could be useful with or without BTNS, i.e.,
		it binds an application identity to a network identity
		(but the latter need not be ephemeral)

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 24 Feb 2006 11:45:55 -0600

> that was not what you asked me to address via that list.

It's session protection, but it's meant to seem like transport
protection.

> Channel binding functionality does not explicitly demand transport 

Channel binding demans channels to bind to.  Such channels must: a)
provide adequate (for the cb app) protection for data sent over it, b)
provide a way to cryptographically bind to it.

> that can be achieved via SSL/TLS, for example.

Yes, that's my motivation.

> protocol, whole I see only one of cited motivations as emphasizing 

We must be converging -- your disagreements with either Joe or myself
are more and more matters of degree :)

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 24 Feb 2006 10:00:08 -0800

...
> Yes, that's my motivation.

We probably agree on that, but it's not a motivation for BTNS. BTNS is a
good place to develop a particular channel binding variant, but that
doesn't seem like a motivation.

> are more and more matters of degree :)

Agreed on the last point, but it would be useful to understand these
just a bit further, again as they may need to be incorporated into the P&AS.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 24 Feb 2006 12:23:40 -0600

> doesn't seem like a motivation.

Oh no, channel binding certainly is a motivation for BTNS, if
round-about: because implied in channel binding is that you already have
an authentication infrastructure deployed that you can use at layer 7,
but you want secure channels at lower layers where you don't care what
is used for authentication, and having to deploy a separate
authentication infrastructure just to get such channels is lame.

I first posted to the old IPsec WG list about something like BTNS long
before the ANONSEC BoF.  And the motivation for channel binding to IPsec
and unauthenticated IPsec goes back to March 2003 when a bunch of people
at Connectathon sat down to work out a proposal from Mike Eisler going
back to December 2002.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 24 Feb 2006 11:30:32 -0800

> authentication infrastructure just to get such channels is lame.

Why wouldn't channel binding be useful in the context of conventional
IPsec? The network identity (i.e., as used by IKE) need not have
anything to do with the application identity. It seems like it'd still
be useful to combine the two.

I.e., I'm suggesting that channel binding is definitely useful for some
variants of BTNS, but isn't really a motivation for the work itself
(even if it predated it, which I appreciate). That's a bit of a split
hair, though, so I'll keep that in mind for the (hopefully nearing
final) next update of the P&AS.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 24 Feb 2006 14:32:38 -0600

> be useful to combine the two.

Because you might have the authenticatoin infrastructure for IPsec
deployed.  BTNS requires zero authentication infrastructure deployment.

> final) next update of the P&AS.

So, it's been my motivation for pursuing BTNS since sometime soon after
March 2003.  I think at least one list member here was at the meeting
where we conceived of using channel bindings to IPsec to resolve the
issues that Mike Eisler was looking to resolve in NFSv4.  The others who
were there are also participants at the IETF, so if you want
confirmation of this motivation, I assure you I can get it :)