Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs

From: Joe Touch <[email-masked]>
Date: Fri, 01 Aug 2008 12:11:57 -0700

Adam Langley wrote:
| On Wed, Jul 30, 2008 at 4:40 PM, Joe Touch <[email-masked]> wrote:
|> The current TSAD supports only a wildcard source port, which is
|> instantiated for the first connection received that matches. It expects
|> that the KMS installs additional keys as needed.
|
| I was assuming that the TSAD would support wildcards for source IPs
| and ports. I would also suggest that it's not a bad idea, although if
| it didn't happen, that's no problem.

My impression is that the overall system should support what TCP
supports, i.e., LISTEN on ANY in the same places TCP does. However, once
a connection is established, the connection key is fixed. Note that this
means the TSAD might allow wildcards in places the current draft doesn't
describe.

There are two possible solutions to work over NATs then:

1) install keys that are sufficiently wildcarded AND configure those
keys to ignore the addresses and ports

2) require the KMS to determine the appropriate keys to install on the
two ends, and compute the MAC based on the received socket pair

(I had thus far been assuming #2, FWIW)

<IHO>
#1 appears to have a few potential challenges:
	- once we omit the addresses and ports from the MAC,
	we can't assume that each connection's derived key
	is unique (it would depend only on the ISN pair) within
	a host

	- if keys are shared across a number of hosts,
	derived connection keys aren't unique across
	those hosts either. after an area reboot,
	non-randomized ISN generation might be leveraged
	to enable a replay attack

	- support for NATs assumes keys are installed in
	ways that support NATs
		i.e., the wildcards matter just as much
		as the 'ignore socket pair in MAC' setting

	- support for NATs appears to prohibit keys that
	depend on client addr or source ports, i.e., there
	would be no way to have different keys for different
	groups of clients

|> The above appears to require that the KMS deploy the same key for all
|> potentially overlapping NAT'd connections. This adds a requirement to
|> the KMS, but suggests that the pseudoheader is included or excluded for
|> all connections to a host from a given IP address. Is that what is
|> intended, or can you clarify? If that is what is intended, how can the
|> KMS enforce this?
|
| Indeed, something would have to arrange for the pseudoheader to be
| excluded from the MAC input when a packet matches a wildcard source IP
| rule. Also, the same key would indeed be used by many connections.
| Thus the key should rotate based on the time (once a minute would be
| reasonable.)

Key rotations (presumably you're talking about the master key) may
require some synchronization, which seems unlikely in the case of NATs
as well.

There are a few questions that may be useful to address to move forward:

	- is the use of wildcards/ingore addrs/ports compatible with
	the desire for unique per-connection keys?

	- is it OK to require that all NAT'd clients use the same
	key

	- is it OK to require that support for NATs means
	using wildcard'd keys?

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Tue, 5 Aug 2008 18:26:36 -0700

> require some synchronization, which seems unlikely in the case of NATs

A time based key rotation would only require that endpoints have
synchronised clocks to within an arbitrary amount of time. A minute
would seem reasonable.

>        the desire for unique per-connection keys?

Unless the SEQ/ACK randomness is compromised, 64-bits of random data
should be enough I believe. If the randomness *is* compromised, then
adding in the ports and addresses to the calculation does little for
security since those values are known.

>        - is it OK to require that all NAT'd clients use the same

In the cases where people would consider setting things up this way
(when manual/automatic key distribution is too burdensome) then I
would suggest, yes.

>        - is it OK to require that support for NATs means

Again, I would say yes. Noting that this scheme (wildcarding keys)
does not prohibit manual or automatic key distribution. It's simply a
low-setup-cost addition to those schemes.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 19:02:57 -0700

At Tue, 5 Aug 2008 18:26:36 -0700,
> synchronised clocks to within an arbitrary amount of time. A minute

Isn't the whole point of the key-ids to avoid requiring this?

-Ekr

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 6 Aug 2008 17:42:19 -0700

> Isn't the whole point of the key-ids to avoid requiring this?

Well, keyids would be required too. Here's how I see it working.

Define a synchronisation range, R, say 1 minute. We require that the
maximum skew between two clocks is R.

Define a key rotation timespan, T, say 1 minute. Let N be the maximum
number of keys that exist in a timespan of 2R. In our example, this is
two.

Define a function K(master, t) that maps a timestamp to a key derived
from a master key and a keyid in [0, N). For example, F(master, t) =
SHA1(master + uint32be (t/T)) with keyid (t/T) `mod` N.

At any time, a client transmits with key and keyid from F(master,
currentTime). At any time, the server accepts SYN signed with any
keyid and key in a span of 2R centered around the current time.

So one can only connect if one's clock skew is acceptable and one
knows the master key.

The keys for the resulting connection would be connection specific,
probably hashing in the SEQ/ACK numbers, other stuff etc.

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Aug 2008 18:18:12 -0700

At Wed, 6 Aug 2008 17:42:19 -0700,
> probably hashing in the SEQ/ACK numbers, other stuff etc.

I'm sorry, I must be missing something. what problem are you trying to
solve?

-Ekr

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 7 Aug 2008 10:47:30 -0700

> I'm sorry, I must be missing something. what problem are you trying to

The above was an sketch of how a passive open socket would work with
TCP AO such that only clients that knew a master key could connect. If
we wish to support a setup, then wildcard key matching would probably
be needed.

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 11:05:11 -0700

At Thu, 7 Aug 2008 10:47:30 -0700,
> we wish to support a setup, then wildcard key matching would probably

Because the side doing the passive open doesn't know which client
is connecting and it may have multiple instances of the same key-id?
I don't understand the purpose of the time. Just do trial verifications
with each key.

-Ekr

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 7 Aug 2008 11:10:38 -0700

> I don't understand the purpose of the time. Just do trial verifications

I don't believe that there should be multiple instances of the same
keyid. This is for the situation where there is a shared key between
the server and all valid clients. If we wished, we could fine that to
be keyid 0, sign the packets and be done with it.

But since the SEQ/ACK space isn't that large, and a replayed SYN could
still be used to SYN flood a system, I sketched that system to rotate
the keys based on time to limit the scope of replays.

AGL

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 11:14:10 -0700

Eric Rescorla wrote:
| At Thu, 7 Aug 2008 10:47:30 -0700,
| Adam Langley wrote:
|> On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla
<[email-masked]> wrote:
|>> I'm sorry, I must be missing something. what problem are you trying to
|>> solve?
|> The above was an sketch of how a passive open socket would work with
|> TCP AO such that only clients that knew a master key could connect. If
|> we wish to support a setup, then wildcard key matching would probably
|> be needed.
|
| Because the side doing the passive open doesn't know which client
| is connecting and it may have multiple instances of the same key-id?
| I don't understand the purpose of the time. Just do trial verifications
| with each key.

That's a reason we have a keyID, which, together with the socket pair,
should exactly specify what key to use and avoids this sort of trial. If
we can live with trials, we can remove the keyID and things align much
better.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 11:20:04 -0700

At Thu, 07 Aug 2008 11:14:10 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:

Yes, but this only works if you either (1) know the address of 
peers in advance or (2) never assign the same key-id to two
different peers.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 11:21:34 -0700

At Thu, 7 Aug 2008 11:10:38 -0700,
> the keys based on time to limit the scope of replays.

Huh? You're worried about being SYN flooded by people with whom
you share a trust relationship with? That doesn't seem particularly
likely.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 11:35:38 -0700

Eric Rescorla wrote:
...
|> | Because the side doing the passive open doesn't know which client
|> | is connecting and it may have multiple instances of the same key-id?
|> | I don't understand the purpose of the time. Just do trial verifications
|> | with each key.
|>
|> That's a reason we have a keyID, which, together with the socket pair,
|> should exactly specify what key to use and avoids this sort of trial. If
|> we can live with trials, we can remove the keyID and things align much
|> better.
|
| Yes, but this only works if you either (1) know the address of
| peers in advance or (2) never assign the same key-id to two
| different peers.

<indiv hat on>

If we require the socket pair, then the keyID need be unique only within
a connection, and we should never need to test different keys -- even
with key rollover, the key used should be deterministic.

Supporting NATs can be done in two different ways:

1. require the KMS to determine the socket pair as received, and
calculate the hash based on the as-received values

	this does not require testing different keys, but puts
	additional burden on the KMS

2. require a mode where the socket pair is not included in the MAC

	this will require testing different keys,
	it also requires the KMS install keys in certain ways
	(i.e., wildcarded on source port and dest IP addr, at least)

I have not yet seen a reason to support secure transport connections for
NAT'd devices made on this list. If there isn't, perhaps it'd be
preferable to leave the protocol simpler and just not support NAT mode.

Alternately, perhaps we could note that there could be modes where
certain header fields are excluded, but that this would be described in
a separeate extension - i.e., not in this doc.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 11:52:24 -0700

At Thu, 07 Aug 2008 11:35:38 -0700,
> Supporting NATs can be done in two different ways:

I think this is at least potentially an issue even aside from NAT. When
I install keys on my host, you're proposing that I need to configure
both the peer IP address and the key-id. This isn't necessarily
bad, but it does mean that if (for instance) the other side decides
to renumber, nothing will work absent manual reconfiguration. Is
that something people want?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 11:51:34 -0700

Eric Rescorla wrote:
...
|> Supporting NATs can be done in two different ways:
|
| I think this is at least potentially an issue even aside from NAT. When
| I install keys on my host, you're proposing that I need to configure
| both the peer IP address and the key-id. This isn't necessarily
| bad, but it does mean that if (for instance) the other side decides
| to renumber, nothing will work absent manual reconfiguration. Is
| that something people want?

<indiv hat on>
If we ignore source IP addresses, we probably end up needing to go
through a set of possible keys when a SYN arrives. This seems like it
amplifies the impact of a SYN attack - the more keys we have, the more
each falsly-encrypted SYN costs.

Alternately, a good KMS could figure out when these IP addresses
changed, and update the TSAD accordingly. I would prefer this latter
solution...

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 12:09:41 -0700

At Thu, 07 Aug 2008 11:51:34 -0700,
Joe Touch wrote:
> through a set of possible keys when a SYN arrives.

Well, not if you use unique key-ids.

> This seems like it

Well, that's certainly true at some level, but if you use any
randomness at all in key-id assignment, you would expect to have
about N/256 key-ids where N is the number of keys. Unless N is
very large, the number of duplicate key-ids is likely to be high
enough that this doesn't seem like a very impressive attack,
especially since the attacker can force you to compute a MAC with
*every* packet he sends, not just SYNs.

> changed, and update the TSAD accordingly. I would prefer this latter

Yeah, but what does that say about manual key management, which is what
we're going to have for the foreseeable future.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 12:09:49 -0700

Hi, Eric,

<indiv hat on>

Eric Rescorla wrote:
|> <indiv hat on>
|> If we ignore source IP addresses, we probably end up needing to go
|> through a set of possible keys when a SYN arrives.
|
| Well, not if you use unique key-ids.

I've noted before that I don't think it's a good idea to assume
cryptographic properties of fields in the header or option except for
the MAC.

Also, the size of the keyID space is fairly small as it is, and others
have suggested it be even smaller (the few bits actually needed to
rotate keys during a connection).

|> This seems like it
|> amplifies the impact of a SYN attack - the more keys we have, the more
|> each falsly-encrypted SYN costs.
|
| Well, that's certainly true at some level, but if you use any
| randomness at all in key-id assignment, you would expect to have
| about N/256 key-ids where N is the number of keys. Unless N is
| very large, the number of duplicate key-ids is likely to be high
| enough that this doesn't seem like a very impressive attack,
| especially since the attacker can force you to compute a MAC with
| *every* packet he sends, not just SYNs.

N could easily be fairly large, e.g., in peer-to-peer hubs. Note that
this should be an issue only for SYNs; once a connection is made, the
socket pair is already static (by TCP rules), so the appropriate key for
that socket pair (thus determined during the SYN handling) can be
installed - e.g., by a link.

|> Alternately, a good KMS could figure out when these IP addresses
|> changed, and update the TSAD accordingly. I would prefer this latter
|> solution...
|
| Yeah, but what does that say about manual key management, which is what
| we're going to have for the foreseeable future.

It says that renumbering has consequences. Either you need to increase
the burden on your key manager, or weaken your security (by increasing
DOS impact, e.g.).

If I have to pick one, I'd pick increasing the burden on the key manager
in that case for *this* protocol. (where key manager could be a person).

Joe

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 7 Aug 2008 12:18:40 -0700

> you share a trust relationship with? That doesn't seem particularly

I was assuming the attacking party would be replaying valid messages
that they captured on the wire.

While I'm thinking about the topic, I don't know where people are
located, but yourself, Joe and anyone else interested is welcome to
come to Google (SF or Mountain View) for a discussion on this. The
IETF meetings would be the usual forum for such discussions, but I
think that Joe wanted to get this moving faster than that. So, if it
would be helpful, the offer stands.

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 12:45:45 -0700

At Thu, 07 Aug 2008 12:09:49 -0700,
> cryptographic properties of fields in the header or option except for

Well, I don't think of this as a cryptographic property. All that's
required is a relatively even distribution of key-ids. They need
not be secret.

> installed - e.g., by a link.

That just removes the amplification angle. The attacker can still
force the victim to do one MAC computation per transmitted 
packet.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 12:47:09 -0700

At Thu, 7 Aug 2008 12:18:40 -0700,
> that they captured on the wire.

Well, this isn't much of an attack, since the attacker can only
create one SYN state for every individual connection initiation
that it observes. How useful is that?

-Ekr

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 7 Aug 2008 14:46:19 -0700

While we are at this subject ("supporting NAT's") did we answer the
basic questions :-

- Is this a mandatory? Since BGP, LDP and MSDP who are going to be major
users of this option, NAT is not going to be in picture.

- Ok, assume you are deciding to support NAT, where do you draw the
line? Are you also talking about embedded IP addr in the payload (ALG)?
Or we don't care?

I haven't heard concrete responses (if any) to these above questions.
Not meant to derail the crypto focus that is currently prevailing in
this thread.

-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Thursday, August 07, 2008 11:52 AM
> To: Joe Touch
> Cc: Adam Langley; [email-masked]
> Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
> 
> > |> | I don't understand the purpose of the time. Just do trial 
> > |> | verifications with each key.
> > |>
> > |> That's a reason we have a keyID, which, together with the socket 
> > |> pair, should exactly specify what key to use and avoids 
> this sort 
> > |> of trial. If we can live with trials, we can remove the 
> keyID and 
> > |> things align much better.
> > |
> > | Yes, but this only works if you either (1) know the 
> address of peers 
> > | in advance or (2) never assign the same key-id to two different 
> > | peers.
> > 
> > <indiv hat on>
> > 
> > If we require the socket pair, then the keyID need be unique only 
> > within a connection, and we should never need to test 
> different keys 
> > -- even with key rollover, the key used should be deterministic.
> > 
> I think this is at least potentially an issue even aside from 
> NAT. When I install keys on my host, you're proposing that I 
> need to configure both the peer IP address and the key-id. 
> This isn't necessarily bad, but it does mean that if (for 
> instance) the other side decides to renumber, nothing will 
> work absent manual reconfiguration. Is that something people want?
> 
> -Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Aug 2008 18:46:24 -0700

> Yeah, but what does that say about manual key management, 
> which is what we're going to have for the foreseeable future.

I agree with Eric.  

Using IP addresses as identifiers seems ill-advised now-a-days.  Ignoring
NATs, the same device can legitimately acquire different IP addresses
throughout one day (roaming from wireless access point to wireless access
point).  It might be a reasonable optimization, or a useful additional
security property, to require or to expect a key-id to come from the same IP
address it came from last time -- but I don't think it should be necessary
that the key-id come from the same IP address.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Aug 2008 18:46:28 -0700

> Behalf Of Anantha Ramaiah (ananth)
> Sent: Thursday, August 07, 2008 2:46 PM
> To: Eric Rescorla; Joe Touch
> - Is this a mandatory? Since BGP, LDP and MSDP who are going 
> to be major users of this option, NAT is not going to be in picture.

Those are going to be the major consumers now, but if we aren't
able to keep ahead of various out-of-window TCP attacks, it would
be reasonable for other applications to want to use TCP AO.  I
believe a TLS-over-TCP connection can be destroyed with a bogus
in-window packet; preventing such an attack with TCP AO would be 
valuable if such attacks become easier in the future.

> line? Are you also talking about embedded IP addr in the 
> payload (ALG)? Or we don't care?

No ALGs.

-d

---

From: Ron Bonica <[email-masked]>
Date: Mon, 11 Aug 2008 14:19:01 -0400

> should exactly specify what key to use and avoids this sort of trial.

Amen!

  If
> we can live with trials, we can remove the keyID and things align much

But we can't!

             Ron

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Aug 2008 11:42:14 -0700

At Mon, 11 Aug 2008 14:19:01 -0400,
> > we can live with trials, we can remove the keyID and things align much

If we can't ever have trial authentication than there must be a unique
key for each (key-id, remote addr) pair. As a practical matter,
this implies either that:

- Key-ids must be globally unique.
- You need to know the other side's IP address, even if you're doing
  a passive open.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Aug 2008 12:32:41 -0700

> - You need to know the other side's IP address, even if you're doing

Adding 32 bits to the key-id would create the same global uniqueness
that using the source IPv4 addresses accomplishes.

But it's only necessary to have a globally unique key-id when a new
connection arrives:  after that, you can use the source IP address
and TCP port.  A reasonable optimization could involve using a 
shorter key-id after the TCP session is established.

-d

---

From: Ted Faber <[email-masked]>
Date: Mon, 11 Aug 2008 16:46:26 -0700

> that using the source IPv4 addresses accomplishes.

There's a little more to a establishing a global namespace than
allocating the bits.  Using the IP address is capitalizing on the IP
address allocation authorities and routing systems to keep those
addresses unique at any given time (and "unique" is somewhat approximate
even with those mechanisms).

One can establish a global namespace here if needed, but there's more to
do than allocate the field space.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Aug 2008 18:53:54 -0700

> From: Ted Faber [mailto:[email-masked]] 
> Sent: Monday, August 11, 2008 4:46 PM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Ron Bonica'; 'Adam Langley'; 
> [email-masked]; 'Joe Touch'
> addresses unique at any given time (and "unique" is somewhat 
> approximate even with those mechanisms).
> 

So you want something exceeding "the same global uniqueness" of a v4 address.

-d

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Aug 2008 13:03:09 -0700

Hi, all,

<indiv hat on>

I think the discussion on the issue of keyID uniqueness and the size of
the keyID space indicates a deeper issue about keyIDs, as well as the
TCP-AO option.

The keyID is currently only an *intra-connection* identifier. It's sole
purpose is to avoid testing multiple concurrent keys and configurations
on a single connection, as would occur during rekeying. The primary
security association identifier for a connection is the socket pair
(addr/port pair).

The TCP-AO option provides authentication; it does not provide automated
~ key or parameter negotiation. IMO, that is better left to an automated
KMS.

- ---

There are certainly a number of issues that all appear to require more
than simple, static keying in TCP-AO can handle:
	- dynamic endpoint address assignment
	- NATs
	- passive open with floating source IP address

IMO, these can - and should - be handled more easily by an automated
KMS. This would leave TCP-AO much simpler and easier to validate. The
alternatives are problematic:
	- create and manage our own unique connection ID space
	- test all concurrently overlapping keys/configurations
	until each connection is resolved

I thus feel that it's OK to say that the simplest static key
configuration of TCP-AO solves some problems and not others. The
problems we can solve (or have already solved) are:

	- unique per-connection keys (based on ISNs)
	- replay prevention using automated key rollover
	- passive open with floating source port only

Solving NATs, dynamic IP address assignments, and full passive opens for
statically configured keys will, AFAICT, require relaxing authentication
to the point where we will end up developing an in-band KMS in the SYN
packet, which I feel is complexity we can avoid.

Joe