Subject: [anonsec] 3401 and highjacking

From: kent at bbn.com (Stephen Kent)
Date: Wed, 1 Mar 2006 20:22:58 -0500

At 3:28 PM -0800 2/23/06, Joe Touch wrote:
>...
>Channel binding isn't a motivation for BTNS. BTNS is a place where we
>are exploring it.

Sorry. I though it was one of the cited motivations.  I'll have to 
read the latest problem statement I-D.

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

The reasons that they chose to not use Ipsec are based on per-packet 
overhead, for the very small RTP packets. Nothing we do in BTNS is 
going to address that concern.

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

The original one you cited, yes, but that has not been the primary 
focus of most of the more recent discussion, I think.

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

it offers some protection, but to say that it "protects" the layer 
might surprise folks who think confidentiality is important :-).

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 01 Mar 2006 21:50:16 -0800

Stephen Kent wrote:
> Sorry. I though it was one of the cited motivations.  I'll have to read
> the latest problem statement I-D.

I saw Nico's post on this; I'll recheck the latest PS doc to see whether
this needs to be updated on this.

> overhead, for the very small RTP packets. Nothing we do in BTNS is going
> to address that concern.

Their per-packet processing overhead can't be all that different; they
use AES and HMAC-SHA1. The key difference is that SRTP allows "good
enough" key lengths that are less than full-sized, which helps keep the
bandwidth overhead down and packet expansion constrained, but which
forces the session keys to have a shorter lifetime. That logic is
equally valid for IPsec.

> The original one you cited, yes, but that has not been the primary focus
> of most of the more recent discussion, I think.

Many of those discussions were raised in the context of connection
binding; while BTNS is a place where that issue is being raised, it is
not unique to BTNS.

> it offers some protection, but to say that it "protects" the layer might
> surprise folks who think confidentiality is important :-).

The same is true for an IPsec SA based on MD5. The point wasn't privacy
vs. authentication; it's transport vs. non-transport.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Mar 2006 01:04:45 -0500

>forces the session keys to have a shorter lifetime. That logic is

It's communication overhead, not processing overhead, that motivates 
use of SRTP. the headers for SRTP are very small, even compared to 
transport mode ESP.

>vs. authentication; it's transport vs. non-transport.

First, there are no SAs that are protected via MD5, per se, although 
we can have SAs that make use of HMAC-MD5. But, ESP (which is a more 
efficient way to offer integrity and authentication that AH), also 
offers confidentiality, if desired. Thus it can "protect" a 
connection to whatever extent a user wishes, depending on selection 
of appropriate options, unlike the limited forms of protection 
offered by the TCP-MD5 checksum option.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 01 Mar 2006 22:15:03 -0800

Stephen Kent wrote:
...
>>> might
> First, there are no SAs that are protected via MD5, per se, although we
> can have SAs that make use of HMAC-MD5.

I never knew that HMAC-MD5 was not based on MD5. ;-)

> But, ESP (which is a more
> offers confidentiality, if desired. Thus it can "protect" a connection
> to whatever extent a user wishes, depending on selection of appropriate
> options, unlike the limited forms of protection offered by the TCP-MD5
> checksum option.

I never knew there was a way to use ESP with an algorithm based on MD5
(e.g., HMAC-MD5-96, as per RFC4305) that afforded confidentiality either.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Mar 2006 01:23:44 -0500

>I never knew that HMAC-MD5 was not based on MD5. ;-)

if there were not a significant difference between MD5 and HMAC-MD5, 
we would not bother using the latter, given the additional 
processing. thus it makes sense to be precise in discussing which 
integrity algorithm we're using.

>(e.g., HMAC-MD5-96, as per RFC4305) that afforded confidentiality either.

nor did I say so. again, precision and clarity in our communication 
is its own reward.

>Joe

it's probably best if we stop arguing over who is and is not 
communicating clearly, given the outcome of previous arguments on 
this topic.

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri, 10 Mar 2006 17:19:04 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:

    Stephen> It's communication overhead, not processing overhead,
    Stephen> that motivates use of SRTP. the headers for SRTP are very
    Stephen> small, even compared to transport mode ESP.

You should be aware that there is a proposal being discussed at AVT in
Dallas to use DTLS as an alternative to secure RTP instead of SRTP.
There are problems with keying SRTP that have caused some to question
whether perhaps the key establishment should happen as part of the RTP
stream establishment instead of part of the session setup layer.

If this proposal is viewed favorably, it casts doubt on claims about
SRTP being different from other protocols in terms of overhead
requirements.

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri, 10 Mar 2006 17:21:40 -0500

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

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

CB has been one of two motivations that made me very interested in
BTNS as an AD.

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 10 Mar 2006 18:12:13 -0500

>SRTP being different from other protocols in terms of overhead

Yes, IF the proposal is accepted, then it signals a change of heart 
by the folks who created SRTP and cited per-packet bandwidth as the 
rationale.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 10 Mar 2006 17:28:37 -0600

> by the folks who created SRTP and cited per-packet bandwidth as the 

If you want data authentication then you have to have some overhead and
that will be comparable in home-grown solutions, AH and DTLS.

So, if you want data authentication and the overhead thereof is too much
then either give up on data authentication or throw better networks
(more money) at the problem.

Case closed :)

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 13 Mar 2006 10:41:56 -0500

>(more money) at the problem.
Not quite that simple :-).

What SRTP did was to add integrity and confidentially to RTP in a 
very careful, space-efficient fashion. In so doing, they reduced 
overhead well below what one could achieve via use of DTLS or ESP or 
AH.  This is not a practice I encourage for application in general, 
because the costs of custom designs of this sort are very high, and 
for most apps the bandwidth savings will not justify these costs. 
Also, as Joe noted, the likelihood of introducing security problems 
in such designs (and in implementations) is also very high.

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 13 Mar 2006 14:08:15 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:

    Stephen> What SRTP did was to add integrity and confidentially to
    Stephen> RTP in a very careful, space-efficient fashion. In so
    Stephen> doing, they reduced overhead well below what one could
    Stephen> achieve via use of DTLS or ESP or AH.  This is not a
    Stephen> practice I encourage for application in general, because
    Stephen> the costs of custom designs of this sort are very high,
    Stephen> and for most apps the bandwidth savings will not justify
    Stephen> these costs. Also, as Joe noted, the likelihood of
    Stephen> introducing security problems in such designs (and in
    Stephen> implementations) is also very high.

The multimedia application also has a number of other special
requirements.  I think that multimedia streams over cellular networks
are one of the few cases I've seen where confidentiality without
integrity may be reasonable.

Humans will know if an attacker significantly corrupts a voice or
video stream.  However the cost of lost packets do to corruption of a
MAC may be unacceptable given radio error rates.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 13 Mar 2006 13:14:16 -0600

> MAC may be unacceptable given radio error rates.

Although authentication can still help at least provide feedback to the
user as to the quality of reception (100% vs. not 100% :)

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sun, 19 Mar 2006 11:11:45 -0600

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060319/1daca5df/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 19 Mar 2006 16:23:22 -0600

On Sun, Mar 19, 2006 at 11:11:45AM -0600, Michael Richardson wrote:
>     Nicolas> On Fri, Feb 10, 2006 at 07:17:22PM -0500, Michael Richardson
>     Nicolas> wrote:
>     >> 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.
> 
>     Nicolas> Better:
> 
>     Nicolas>  - transport, on output, says "please send this packet protected
>     Nicolas> by an SA that matches the characteristics of the SA originally
>     Nicolas> used for latching (this includes crypto algs AND peer IDs).
> 
>   It's really a lot of thinking to distribute around the place (and for
> connectionless procotols, it winds up in the application), and I'd rather let
> the key manager deal with determining what is "equal"

The ULP doesn't have to concern itself with the details of latching.

One way to architect this in software: for inbound packets let IPsec
pass packets up with a reference to the SA used to protect it, then let
ULPs call generic IPsec functions to either obtain a latch corresponding
to a given SA or determine whether a given SA matches a given latch; on
output ULPs should pass down a reference to a latch and IPsec just has
to find or establish an SA that matches the given latch.

For connectionless ULPs the application doesn't have to do the latching
as long as it can hold on to a "handle" for a particular 5-tuple and
corresponding latch.  In BSD socket terms, for sending a UDP datagram it
suffices to connect() a UDP socket before sending; for receiving you'd
have to do something where you accept() on UDP unconnected sockets to
get a "connected" UDP socket whenever a datagram comes in that doesn't
match the 5-tuple of an existing connected socket (or more).

>     Nicolas>  - the actual latch is constructed from the characteristics of
>     Nicolas> the SA that protected the first packet sent or received on the
>     Nicolas> given connection (e.g., the SYN packet, in the case of TCP).
> 
>   I thought a lot about doing that, but I decided simplify the life of the
> ULP.  I'm very concerned about BTNS work through NATs.

The ULP need not know the details of how to do this, see above.

All you need are generic IPsec functions of this form:

    sa2latch(sa#) -> latch

    sa_matches_latch_p(sa#, latch) -> true/false

plus let IPsec label incoming protected packets with the SA# used to
protect them and let ULPs label outgoing packets with a latch.

There may be other ways to design your implementation of connection
latching, of course.  My point here is that where ULPs are implemented
separately from layer 3 the ULPs need not know the details of IPsec
connection latching.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 21 Mar 2006 13:29:48 -0600

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060321/e1b89679/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Mar 2006 14:07:47 -0600

On Tue, Mar 21, 2006 at 01:29:48PM -0600, Michael Richardson wrote:
>   So, there is some significant difference between:
>    a)   A:1234/32 <-> B:80/32 (transport mode)
>   and
>    b)   A[A:1234/32] <-> B[B:80/32] (tunnel mode)
> 
>   when a NAT is involved.  From the point of view of the gateway, these
> become:
>         
>    a)   N:4567/32 <-> B:80/32   (%)  
>    a'   A:1234/32 <-> B:80/32 
> 
>    b)   N:4576[A:1234/32] <-> B[B:80/32] (host-to-host tunnel mode)
> 
>   Where N:4567 is outer IP of NAT, and 4567 is outer UDP port. 
> 
>   (%) Yes, there are some systems that let transport mode change TCP (or SCTP)
>       connections into UDP connections... they are broken. Openswan KLIPS 
>       was such a system until recently.  

Yes, I see now (actually, I saw yesterday :)

Now, we could leave NAT out of scope :) or we could do what you
suggested yesterday, namely, to use connection latching as part of the
packet inbound dispatch/outbound SA/tunnel (or NAT address) selection
process.

I don't mind leaving NAT in scope because your solution seems obvious
enough and seems not to do too much violence to IP/IPsec.  That said, I
would insist on this being optional, or even a separate document
altogether.

>   Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE
> connection latching, and BITS and BITW just can't work easily.
> 
>   If you have b), then guess what... *A* is not UNIQUE.
>   Note that (b) is morally equivalent to gateway mode, from a policy point of
> view. 

BTW, is there a potential argument here that connection latching SHOULD
or MUST be used with tunnel mode only because it makes (I assume, for
this argument) implementation of this sort of NAT traversal easier?

>     Nicolas> I think we want to leave tunnelling out of scope for BTNS.  That
>     Nicolas> doesn't simplify things so much though -- we still need
>     Nicolas> connection latching and, ultimately APIs to inspect what is
>     Nicolas> latched and channel bindings.  But note that IPsec generally
>     Nicolas> needs this, and not because of BTNS -- BTNS is merely bringing
>     Nicolas> the issue to a head.
> 
>   I agree. 
>   I don't think you can reasonably do BTNS through a NAT without connection
> latching.   
> 
>   I also don't think you can do it using the language of the RFC2401/4301
> SPD, because the indirection level introduced by that mechanism means that
> you can't seperate two SAs or SPDs that leads to the same "identifier"
> (rfc1918) address. 

But not because of BTNS.  End-to-end IPsec NAT traversal has this same
problem, no?

>   In this context I have been pondering what to do with Opportunistic
> encryption through NATs. Originally, we thought that the problem was policy
> and authorization. We figured out how to solve this. 
> 
>   Since OE uses host /32<->/32 tunnels, we need something unique for the host
> to use as it's "identifier" for the inside. We considered the subset of
> people like the developers, who have unique identifiers we can allocate
> already. (road.marajade.sandelman.ca, 205.150.200.163 is an IP for my laptop
> that I use only on the inside of a tunnel).
>   
>   I then realized that we had a problem. Our outgoing TCP connection was
> going to try to send a packet from:
>       192.168.1.101 -> 205.150.200.178   (my web site)
> 
>   and I was hen going to want to try to match it to an SPD that said:
>       205.150.200.163/32 -> 0.0.0.0/0   => try OE.
> 
>   Worse, if I managed to do this, I would then, after having established a
> tunnel, want to *change* the IP from 192.168.1.101 to 205.150.200.163!
> 
>   Then I thought about people who don't have that unique IP, and wondered, as
> long as I'm violating several layers of software stack, why not change the IP
> >From a v4 to a v6 underneath the application. In the case of Linux<->Linux, I
> can reasonably guarantee that there is v6 at the remote end, and I can use
> IPv4-mapped IPv6 addresses at the remote...
> 
>   Ooops. Maybe transport (BTNS) and/or BEET mode would be better at the lower
> levels, but it may be that I still want to do this.
>   HIP pushes the problem that I have described up to the application layer,
> giving it these HIT's in the form of IPv6 (and now IPv4, I'm told) addresses.

Which the application could use for channel binding and/or LoF?

I remember conversations about how HIP and BTNS were working on the same
problem from different directions.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 21 Mar 2006 14:40:44 -0600

>> (%) Yes, there are some systems that let transport mode change
    >> TCP (or SCTP) connections into UDP connections... they are
    >> broken. Openswan KLIPS was such a system until recently.

    Nicolas> Yes, I see now (actually, I saw yesterday :)

  Sorry... I wrote that on airplane, but it didn't go out until I
noticed it pushed. I'm a newbie to using GNUS+agent to read gmane.org.

    Nicolas> Now, we could leave NAT out of scope :) or we could do what
    Nicolas> you suggested yesterday, namely, to use connection latching
    Nicolas> as part of the packet inbound dispatch/outbound SA/tunnel
    Nicolas> (or NAT address) selection process.

    Nicolas> I don't mind leaving NAT in scope because your solution
    Nicolas> seems obvious enough and seems not to do too much violence
    Nicolas> to IP/IPsec.  That said, I would insist on this being
    Nicolas> optional, or even a separate document altogether.

  I don't see use cases for BTNS (particularly when it was an enabler
for channel binding) that do not involve NAT-traversal. Except for
securing BGP.......
  We are talking to customers who want to build various kinds of NFSv4
NAS things that live centrally and talk to widely distributed
clients (naturally, NAT'ed out the wazoo). The load/power-considerations
on the NAS device is such that they hardware acceleration is
cost-effective, and this favours IPsec rather than GSSAPI for doing the
encryption.  

    >> If you have b), then guess what... *A* is not UNIQUE.  Note that
    >> (b) is morally equivalent to gateway mode, from a policy point of
    >> view.

    Nicolas> BTW, is there a potential argument here that connection
    Nicolas> latching SHOULD or MUST be used with tunnel mode only
    Nicolas> because it makes (I assume, for this argument)
    Nicolas> implementation of this sort of NAT traversal easier?

  I'm not sure I agree.

    Nicolas> But not because of BTNS.  End-to-end IPsec NAT traversal
    Nicolas> has this same problem, no?

  Yes. But like everything else, BTNS makes IPsec use more ubiquitous...

    Nicolas> I remember conversations about how HIP and BTNS were
    Nicolas> working on the same problem from different directions.

  Now that I understand shim6, I wonder if we are wasting our time, and
should just switch to shim6-upgrade-to-hip.

- -- 
]       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: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Mar 2006 17:03:32 -0600

> cost-effective, and this favours IPsec rather than GSSAPI for doing the

So, I envisioned NFSv4 use of BTNS (w/ channel bindings) as a way to
push session crypto down the stack for performance wins that I expect to
be primarily useful in intranet environments.  HOWEVER, I can certainly
see that running NFSv4 over TLS/SSHv2/whatever across NATs will be
important, so I think this should stay in scope.

My only question is: what I-D should deal with the NAT issue?  I'm happy
with the connection latching I-D containing this, but I can also see it
as a separate I-D.

>     Nicolas> implementation of this sort of NAT traversal easier?

OK, just checking :)

>   Yes. But like everything else, BTNS makes IPsec use more ubiquitous...

Indeed.

> should just switch to shim6-upgrade-to-hip.

Heh.  I don't understand shim6 yet -- I haven't looked at it.  It's
entirely possible that for some uses of BTNS we are wasting our time.
But for my original use case I think BTNS w/ connection latching and
channel binding is the simplest solution to implement and deploy.

Nico
--