Geoff Huston wrote:
So are there any WG comments related to this security directorate review
please?
Sure.
Will you feed these comments back?
BTW: How old is the secdir review? I had some exchanges with some of the
folks around MOBIKE and address ownership fairly recently, and I don't
know if this review was done before or after that.
---------------------------------
From: Eric Rescorla <ekr@networkresonance.com>
It's also worth noting that if you're using IPsec, you have a lot of
other options that are even better.
Such as? (I didn't think we used IPsec pixie dust arguments any more ;-)
In order use IPsec to get any better security there would have to be a
secure binding between a secret (e.g., a certificate) and the IPv6
address; this is the "address ownership" problem. Only the owner of the
IPv6 address should be authorized to determine to what locators packets
destined to that address should be sent.
The only way I know to securely solve this is to have a PKI where the
subject names are IP addresses or IP address prefixes, and where the
hierarchy in the PKI matches the address allocation hierarchy from the
root down to every host. (Of course, when a host gets a new IP address
it would need a new cert for this purpose.)
MOBIKE didn't try to come up with a general solution to this. BTNS AFAIK
is trying to avoid the problem using channel bindings, but that requires
some care and timers to avoid a host previously using an IP address
preventing the new "owner" of that IP address from using IPsec to
communicate with a particular IP peer. That can certainly be done if you
assume that the host be reachable at its IP address all the time.
Unfortunately that assumption doesn't hold in the case of multihoming.
So I honestly don't see a deployable solution that doesn't depend on
placing a hash in part of the IPv6 address. [Today this means CGA/HBA for
shim6, since we use a routable IP address as the ULID. But in the future
we can have non-routable ULIDs so the hash can approach 128 bits.
Essentially the protection against redirection threats can be isomorphic
between SHIM6 and HIP. But going beyond 128 bits would require redefining
TCP, UDP etc to operate with larger connection identifiers and redefining
the socket API to do likewise.]
------------------------------------------------------------------------------
From: Sam Hartman <hartmans-ietf@mit.edu>
4) You don't want on-path attackers to be able to influence traffic
such that it goes to them and not the original destination.
I.E. if I'm on the path and also have some tunnel address you
woludn't see I should not be able to redirect your traffic to my
tunnel and thus capture it.
RFC 4218 doesn't state that as a requirement.
In general, on path attackers can use other means to funnel the packets
somewhere else.
So, you don't start out with a secret. You can trivially have a
secret from off-path attackers simply by sending the secret over the
connection. (I hesitate to call that a secret, but it would at least
be a quantity unknown by people off-path).
That type of leap-of-faith has a problem with address ownership (and
isn't very secure as you state). The ownership problem is as follows:
- Alice arrives on the IETF terminal room. Is assigned IPv6 address
IP1. Alice communicates with www.example.com and conveys her secret.
www.example.com binds that secret to her current IP address. This means
that Alice can move and signal www.example.com her new IP address using
this secret.
- Alice leaves the IETF terminal room, her DHCP lease expires, but she
continues to communicate with www.example.com (which maintains the secret
they setup)
- Bob arrives in the IETF termincal room. The DHCP server gives him the
IP address IP1. Bob tries to communicate with www.example.com. One of
several things can happen depending on the details of a leap-of-faith
multihoming proposal, but all of them result in failure for Bob to communicate:
- www.example.com drops Bob's packets, since it knows that that
IP address has been relocated to Alice's new IP address.
- www.example.com sends the responses to Bob's packets (the
SYN|ACK) to Alice since it knows that's the new location
- Bob tries to use the leap-of-faith multihoming mechanism to
establish his secret with www.example.com, and the latter rejects this as
an attacker trying to steal the address associated with Alice's secret.
_______________________________________________
From: Jari Arkko <jari.arkko@piuha.net>
I guess the main question is "what association". In
situations where we have actual managed security
relationship, such as in VPNs, we already have IKEv2
and MOBIKE which do more or less the same function
as SHIM6 does, so there's really no need for additional
support in IPv6 for this purpose.
But MOBIKE as specified has no solution to the general issue of address
ownership. Thus it only works for VPNs and where there is a separate
mechanism to authenticate the users before letting them join the VPN.
However, this is not
the only scenario people have. SHIM6 targets more
general Internet usage which does not assume managed
security between corresponding hosts. But I think
we agree on this, the question is on how to achieve
it. The possibilities that come to my mind are
- HBAs
- CGAs
- BTNS
FWIW I don't understand how the BTNS channel binding can avoid the
ownership problem. Unless I've very confused, all the channel bindings do
is transform the "IP address ownership" problem into the "IP,protocol,port
ownership" problem. At best this makes it 64,000 times harder for an
attacker to completely shut off an IP address for use by somebody else.
SHIM6 is taking the approach which uses HBAs or optionally
CGAs. Another possible option would have been to use only
CGAs. I believe the discussions that led to doing HBA related
to computational cost, and IPRs. However, I'm personally
not very convinced about the computational cost problem.
I agree that computational cost and IPR where the issues that were brought
up and that are viewed as differences between HBA and CGA.
For one thing, I think you only need to do the computations
IF you actually end up having a connectivity problem and
have to switch the address.
That isn't the only case (and for simplicity the shim6 specification says
to do it immediately when the locator set is received).
If a locator set has been received during the context establishment, and
later a different locator set arrives in an Update message, then the host
presumably needs to defend itself against one or the other locator set
being spoofed. Perhaps this is something we can gain more experience with
over time.
BTNS would be the other option. However, while
I think BTNS does a good job in the channel binding
case I'm much less convinced that we know what it
should or could do in other cases. In fact, I do not
currently see how to make it work for something like
what SHIM6 wants to do. Maybe we can make it work,
but its really not there today. Getting it done would
be very useful, though, particularly if BTNS+MOBIKE would
give us SHIM6-like functionality but have it also work for v4
and over NATs...
I don't see how this can solve the address ownership issue.
---------------------------------------------
From: Eric Rescorla <ekr@networkresonance.com>
Well, I think I disagree here on philosophical grounds.
I prefer to avoid inventing new mechanisms--especially ones
of new styles--when that can be avoided. The standard primitives
we have for integrity are MACs with shared keys and digital
signatures with known public keys. Why invent something new.
-Ekr
For public keys and a PKI to be useful to prevent IP address redirection
threats, the identities which the PKI uses MUST be IP addresses.
Thus the current deployment for securing applications using identities
that make sense to applications (such as mbox:erik.nordmark@sun.com) do
not help for IP address redirection threats.
Erik