On 4.6.2007, at 19.25, marcelo bagnulo braun wrote:
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.
I think lots of things are nowadays keyed on IP basis mostly due to
layering violations, bad CLIs/configuration models and little else;
they make network renumbering for example intensely painful.
The question I was trying to phrase is this: If I connect to a
network, generate an arbitrary CGA, what value can someone else
derive from the fact that they do opportunistic encryption with me,
with CGA-based auth as opposed to some arbitrary 'uhm, I am someone.
really.' identity scheme?
The difference in the level of trust between return-routability and
actually confirmed IP address (given no other information) seems slim
to me, as I wouldn't trust either of them for about any purpose.
As I see it, you need
- trusted local/global directory/configuration database (for
discussion's sake, DNSSec - although I wouldn't trust any central
authority not under my own control) + CGA-opportunistic-stuff, or
- PKI/something else in IPsec SPD itself that provides the trust.
What is the value of CGA-based authentication without trusted tie-ins
to higher application layers?
Hmmh. Maybe I'm not just seeing the trust value of identifying IP
address for endpoints - I see more point for the routers on the
network path to identify the correct sender of packet for example,
but this won't provide that. Or for a strict DNS-based mapping to
identify, but that won't happen either with DNSSec as it stands..
- 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...
Some folks want strangest of things. However, providing them isn't
always the way to go.
I thought the basic premise of CGA was that they're created on the
host-side, and yes, nothing prevents you from getting extra
parameters from DHCP server, but the whole premise of DHCP RFCs as
they stand seem to not to mandate encryption - adding that would mean
significant rewriting.. As examples, the relay-server IPsec
characteristics are auth-only, there is no encryption framework for
protocol traffic, not to mention chicken-and-egg problem of where to
get the keying material for the DHCP client to start with..
- 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
Yes, that's why I brought it up as an example.
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 can imagine few other 'useful' models, and I can bet there being
more out there; but without confidentiality they all assume that the
path between DHCP client and server is trusted, and that's assumption
even RFC3315 doesn't make (it provides for authentication of traffic,
but no confidentiality due to assuming lack of need of
confidentiality for the traffic).
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.
Indeed. I'm just worried about pushing any combination of insecure
provisioning protocol and security protocols, and offhand the most
useful CGA-oriented DHCP use I can think of is just doing information
request for the configuration information you care about on the host :-)
Cheers,
-Markus
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
