Hi Markus,
thanks for your comments, see reply below...
El 04/06/2007, a las 3:41, Markus Stenberg escribió:
Disclaimer: I mostly agree with the need for extra SeND/CGA work;
these comments are the delta that I do not agree with :)
great
do you think of any additional work that do you think would be
interesting to work on and that has not been included in the proposed
charter?
On 2.6.2007, at 0.42, marcelo bagnulo braun wrote:
- Extensions to the IKEv2 protocol to create IPSec SAs associated to
the CGA key. Because of their cryptographic nature, CGAs are
inherently bound to the key pair that was used for their generation.
This is used in existent protocols for proving address ownership.
However, it would be possible also to use this cryptographic material
to create a security association between peers. The key benefit of
such approach is that it allows the creation of a security association
that is cryptographically bound to the IP address of the end points
without dependence on a common trust anchor point, eg. PKI. Such
approach would provide additional protection compared to the
opportunistic approaches. The proposed work will produce an analysis
of this type of solution and the required extensions to CGAs and to
the IKEv2 protocol in order to be able to create IPSec SA using the
CGAs keys.
Maybe it is just a matter of wording, but the additional protection
compared to opportunistic approaches seems slim to me. Certainly, you
have CGA-IP as bound entity as opposed to someone on return-routing
path, but you still don't have faintest idea who is using the IP. And
I thought that (for most part) security authorization issues required
something concrete to be identified (whether it is a machine, or user
of the machine), and not just 'oh, he went through CGA process to get
that IP'.
but, the IP address is the identity at the IP level, right?
I mean, from an architectural point of view, at the IP level what is
needed is to be certain of the identity of the peer at the IP level. So
using the CGAs would exactly provide that, an SA bound to the IP level
identity. This would suppress the leap of faith that is needed in the
opportunistic mode. I mean there are a number of processes and security
filters, ACL, that run based on IP addresses because of this reason, so
making certain that the peer is actually the owner of the IP address it
is claiming to, would provide trust to this applications. It may well
be the case that additional trust is needed because additional
information is needed. But building a generic any to any trust model
that requires no pre arrangement (global PKI or shared secret) is a
very complex task, and i think this is a significant step on this
direction. I mean, nowadays, or either a global PKI is assumed or all
you have is the opportunistic mode with the leap of faith. This work
would take a step further in the deployment of this general any to any
trust relations with no pre arrangement with an extremely reduced cost.
I mean, i would expect that the changes required to support this are
slim, minor extensions to the IKE protocol and the output is the
elimination of the leap of faith in the opportunistic mode.
But you raise a central point in this discussion, what are the
motivations for this work and if they are worth it, so i think this is
what we need to discuss at this stage. Probably it would be nice to
have a draft detailing what are the tradeoffs involved, like what are
the benefits of such approach and the costs and limitations, so that
folks would have a better picture for the discussion.
- DHCP support for CGAs. An analysis of possible approaches to allow
the usage of the DHCP protocol to assign CGAs will be produced. The
output of the analysis will be an informational document describing
the recommended approaches that will be provided as an input to the
DHC working group where the actual DHCP extensions needed for the
recommended approaches will be defined.
DHCP and security shouldn't be mixed
not sure what do you mean here, but considering that CGAs are addresses
and that CGAs are used for security and that some folks may want to use
dhcp for configuring CGAs, then it seems that there should be some
relation here...
- for laughs, look at the current DHCPv6.. It basically assumes that
all network links DHCPv6 is used on are trusted,
that may be a reasonable assumption when current parameters are
configured, but probably this is not a valid assumption when we want to
configure cgas which will be used for security purposes, i guess
and effectively due to that anyone on the server-relay, or
relay-client legs could 'acquire' the CGA information if you really
pushed the address+key tuple that way.
this is certainly a model, but it is not the only one.
I mean, it really depends what are the motivations for using dhcp and
what are the motivations for using CGAs. I mean this model assumes an
underlying trust model, where the node can fully trust not only the
links but also the dhcp server. It may well be the case that the node
doesn't want to dhcp server to have its CGA key or that simply you
cannot trust the underlying links for this purposes.
I don't see a single good reason for standardizing that but multiple
reasons why not to. If someone really cares, I can provide the reasons
off-band :)
please expand on this since seems to be a central point for this
proposed item
Thanks again, marcelo
Cheers,
-Markus
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
