[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [secdir]Comments on draft-ietf-shim6-hba-01
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