El 04/06/2007, a las 13:08, Markus Stenberg escribió:
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;
Not sure i agree with that. I think that people use the IP address as
identifiers for upper layer because it is the only identifier provided
by the architecture. I mean, today, you identify a node in the network
based on the IP address. In some cases, apps do not want to rely in a
repository to convert an upper layer identifier (like a fqdn) into an
ip address because this would introduce additional failure modes. In
other cases, the IP address is the only identifier contained in the
packet itself (for instance in the router filters).
they make network renumbering for example intensely painful.
yes, this is the price they pay. I guess that the reasons for directly
using IP addresses when the cost is this additional pain in renumbering
must be good and strong ones, if many people are willing to pay the
price.
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?
exactly this is the main question to be answered
with a leap of faith/opportunistic authentication, basically the peers
know that they are communicating with the same node they contacted
initially during the whole lifetime of the communication but they
cannot know who is that node (for any meaning of who)
with a CGA authentication, they can verify that they are communicating
with the owner of the IP address that they are using as the IP level
identifier during the whole communication. This is more than the
previous case, but the question you pose is what can i use this IP
identifier for? i guess this is useful depending on how this IP address
is bind to the actual endpoint that you want to communicate with.
This is useful without any additional tools for applications or
processes that actually use the IP address as identifier for the peer.
such as IP address based ACLs, filters or any app that use the IP
address directly.
However, in other situations this can be part of the trust chain. For
instance consider the case of DNSSec. With DNSSec a peer can verify
that a given IP address is bound to a given IP address. This CGA+IKE
extension can complete the trust chain providing the means to prove
that a the communicating peer is actually the owner of the IP address
contained in the signed RR. By this mean, a peer can verify that the
the fqdn is associated to the IP address using DNSSec and that the
actual communicating peer is associated to the IP address using
CGA+IKE. From an architectural p.o.v. this seems a clean approach,
since the DNSSec proves the binding between fqdn and IP address and the
IP layer proves the binding between the IP address and the
communicating peer. Note that this can also be used without DNSSec,
since in some scenarios it may be easier to intercept the packets
between the nodes than the information returned from the DNS. I mean,
using DNS (not DNSsec) you could establish a not very secure, but
somehow secure binding between the fqdn and the IP address and you
could use the cga+ike to bind the communicating peer with the IP
address obtained by the dns.
In addition to that, another feature provided by this cga+ike approach
is that nobody can impersonate and IP address to perform nasty things.
I mean, with leap of faith/oportunistic schemes, it is possible for an
attacker to create a false IP address and launch an attack from that
address. Oportunistic security doesn't prevent that. However, the
cga+ike scheme would prevent attacker from doing that, since the
attacker will not be able to impersonate a CGA (because it needs the
associated private key). this basically protects the address owner from
attacker having malicious behaviour using other node's identity.
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
i think we should clarify the terminology here.
agree that with DNSsec+CGA IKE stuff you build a complete trust chain,
but this is not the case with other leap of faith oportunistic schemes,
since there is no binding between the IP address and the actual
communicating peer (except from the one provided by the routing system)
- 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?
the points above aim to answer this question...
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.
this is a good observation.
what happens if you are using IPSec tunnel mode and the security
gateway verifies the endpoints based on the IP address? wouldn't CGA
stuff be useful here? I mean, the IPSec gateway will verify that the
communicating peer is the actual owner of the IP address used in the
IPSec SA.
Or for a strict DNS-based mapping to identify, but that won't happen
either with DNSSec as it stands..
Not sure what do you mean here... DNSSec does provide a secure mapping
between a fqdn and an IP address, doesn't it?
- 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.
agree, the question is why would it make sense to use dhcp to configure
CGAs
some use cases can be:
- device with low processing power that want to off load the CGA
generation procedure (consider for instance mobile devices). In this
case, probably the whole processing should be performed in the dhcp
server and then the dhcp server must push the address+CGA parameter
data strucutre+private key to the node. The problem here is that the
dhcp server will know the private key of the node, and needs to
actually transmit it using other secure means, which would imply other
form of trust management.
- another somehow different case, is a node that does actually can
generate his key pair, but doesn't want to share it (because of
security issues) but doesn't have enough processing power to generate
the CGA with a given SEC value. In this case, it wants to offload the
CGA generation process but doesn't want the dhcp server to learn its
private key. In this case the node transmits the publi key to the dhcp
server, the dhcp server generates the cga and returns the CGA plus the
CGA parameter data strucutre.
- a site is using dhcp for centrally manage the site. Addresses used in
the site must be included in the server for management reasons. In this
case, the important thing is that the dhcp server is aware of the CGA,
but it doesn't need to know the CGA parameter data structure, the
client needs to register the CGA address in the dhcp server.
there maybe other use cases that have different requirements, the goal
here is to understand this scenarios and produce a reccomendation ofhow
to manage them and identify if additional modification to the dhcp
protocol are required.
I thought the basic premise of CGA was that they're created on the
host-side,
yes, but this would imply that they are incompatible with sites using
the dhcp server as a IP address management tool and it may be the cse
that some small devices cannot do the cga generation process
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..
this maybe ok, as there maybe options that support some scenarios that
do not exchange keying material, as the example i described above
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..
agree. maybe CGAs could be used for the dhcp server, so that provides
the initial keying material? (i mean, configuring a cga to the dhcp
server itself)
- 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).
funny because probably is SeND that provides that trust, right? Do
probably, for thiss case that we are considering here, the assumption
should be revisited, don't you think?
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
:-)
what cga related information do you think the dhcp server should care
about the host?
Thanks marcelo
Cheers,
-Markus
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
