[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identifiers and security

On 29-jun-04, at 14:04, Erik Nordmark wrote:

and whether those IDs are visible to the applications. 

Ah, but that's a very different issue. I think by definition the
identifiers are visible to the application.

My choice of "visible" doesn't capture the distinction I wanted to make. Sorry.
What I mean was whether the applications need to do something
different because there is an ID (versus there just being a plain-old IPv6
address). The IDs can be visible, either by being part of an IPv6 locator,
or by some new mechanism by which the application can ask the stack for the ID,
but that wasn't the point I was trying to make.

Ok.

Taking NOID as an example of with no new ID namespace, the amount of
work (in the form of DNS lookups in forward and reverse maps)
will also result in stronger association between FQDNs and locators
than we have today.

Even if we assume DNSSEC?

Assume DNSSEC for the baseline (current Internet), for NOID, or for both
when comparing them?

Compare NOID without DNSSEC with DNSSEC without NOID. I think the latter provides stronger FQDN -> address and address -> FQDN information although you are right that this isn't the same as FQDN <-> address.

I've received pushback from folks that I wouldn't characterize as
security geeks, that this would be too weak.

I don't think this is universally true. Certainly, this is too weak for
TLS or IPsec sessions that can now be broken by an attacker, unlike
before. But why would this be too weak for talking to Google over
unprotected TCP/IP?

If I recall correctly, the main concern is when attackers and nodes move
around.

In today's if an attacker is on the path it can cause damage to the
communication if the communication isn't protected with something like IPsec
or TLS. But this ability to cause damage is limited to the time period while
the attacker is on the path.

If we add some multihoming signaling whereby an attacker, which was on
the path (e.g., by being on the same WiFi subnet as the victim) for a short
time period, can cause damage by essentially using the state creation
as a way to preserve it's on-path'ness forever, then folks are concerned.

And justifyably so. But wouldn't it be possible to address this in other ways? Such as having per-direction or even per-session state rather than per-address?

But what you brought to the table is that if we can ensure that secured traffic
can not be redirected, by reusing the keys or otherwise "layering" on top of
IPsec or TLS, then at least we would know that secured traffic could never be
redirected by an attacker. So security-wise we'd gain some and loose some.

I think if the redirection problem by attackers that are on-path temporarily is limited to individual unprotected sessions, we are not materially worse off than today as the same attacker could break the sessions today also, and redirecting an unprotected session presumably isn't worse than breaking it as the contents aren't secret.

I'm thinking more along the line of violating layers and modify IPsec/TLS
such that the wedge or modified IP can obtain keys that are exchanged
by modified IPsec/TLS. Something like putting the secret instructions
for the messager in the locked briefcase he's carrying. This works well
except for the first trip of course...

This sounds tricky.

:-)

I guess I don't know enough how the TLS keys (and which
keys; is there some master key used to generate the RC4 key?, etc)
can be exported from TLS.

I don't know the specs by heart but the way I understand it is that you have a public/private keypair for at least one end of the connection. This key pair is used to create a session key which is subsequently used for encryption. The same key or maybe a different one is used for authentication. TLS works with blocks that may span several TCP segments. Since there is significant housekeeping, I'm assuming it would be possible to define a new message type that can be exchanged between the two hosts without getting in the way of existing operation (negotiation or data transfer). All that would need to happen here is for each side to announce a session key that can be used for multihoming to the other side. Since this information is encrypted, signed and delivered over reliable transport, there isn't much more to it. It would of course also be possible to use TLS's own session key, but that's probably dangerous as it may more easily leak and that key is subject to renegotiation.

FWIW Doing the insecure signaling protocol for managing the contexts
is something I can do; a version of such a spec can be created by taking the
NOID spec and removing the places where it verifies things in the DNS.
Saying it is layered above IPsec is also easy to say, but the difficulty
is exploring the interaction with IPsec and IKE, as well as TLS.

Right. What did you think about my IPsec/TLS/DNS musings? This would provide pretty much the above using unmodified NOID. The IPsec/TLS stuff doesn't get easier this way but it's more modular and it also has other benefits (can do TLS when the DNS is down, at least in theory) so it may be easier to get off the ground.