[I changed the subject since the topic was changed.]
James,
You are reading that I were saying more than I am,
probably since the word "security" is so ill defined.
I even catch myself using it in different meanings,
and it is sometimes very hard to unambiguosly understand
the exact meaning.
>>Thus, this all is really about zero-configuration security. Such
>>security, by nature, is never "strong" by the strict definition of
>>strong, but it can be *much* stronger than the current no-security
>>situation. Basically, such security can provide quite a lot of
>>defence against various DoS attacks.
>
> I think you are making too strong a claim here.
It looks like you are reading my statement somehow
differently than I am.
> All that CGA does is allow a node to know that
> a packet came from a node claiming to possess
> a certain public key. The packet could have been
> rewritten in transit, or the public key may not
> come from a reliable source, etc.
Right, in a way. But maybe wrong, in another way.
To be more precise, <CGA + self signed certificate
that contains the CGA address> shows that somebody
has, once but maybe 10 years ago, taken the effort
to create a public key pair, an CGA address based
on the public key, and signed a statement containing
the CGA address using the private key corresponding
to the public key. The security of this statement
relies on cryptographic primitives, i.e. public key
crypto and the hardness of reversing even around
60 bit one-way-function. Thus, the security here is
an *economic* function, a function of the fact that
creating such a stament for any *given* address would
be prohibitively costly for most if not all organizations.
To say anything more than that, you have to
a) define exact semantics for the self-signed cert, and
b) run a cryptographic challenge-response protocol
that provides a timeliness proof about the
availability of the private key.
That allows you to do more, but it certainly does not allow
you to do "end-to-end security" for many meanings of that
phrase.
> Real end to end security requires being able to authenticate that the packet
> contents were not modified in transit, i.e. a digital signature, and
> that the public key can be trusted. If a signature is used, then
> Diffie-Hellman or another protocol is required, and both sides must
> agree on the protocol and the parameters, e.g. p and g if Diffie-Hellman
> is used, and that the public key came from a trusted source.
I am not quite sure what you are exactly saying, but to
the extend I understand I think that we agree. That is,
I think that you are basically saying that CGA as such
is not enough, but we need a cryptographic protocol on
the top of that. That I agree with. What comes to
"trusted source", I am not sure. Trust and trusted are
also terms that are a lot misused in security literature.
Indeed, the crusial issue here is trust. However, trust
is *not* a binary, non-qualified thing. It is a quite
complex phenomenon both in technical and psyco/sociological
sense, but let's not go there. For now it is sufficient
to understand that Alice trusts Bob for some things but
not for others.
The issue here is that you can *choose* to trust public keys
for *certain* purposes, just based on the belief that it would
be sufficiently hard for an attacker to break the assumed
cryptographic scenario, e.g. CGA.
> I think CGA is a good solution to the MIPv6 BU security problem, and
> maybe for ND security as well, but I think it is prudent to not
> overstate the case.
I did not mean to overstate. I am sorry that my original
sayings about zero-conf security could be read so.
Generic zero-conf end-to-end confidentiality and integrity
does not exist, since the *application* that requires
confidentiality and integrity has application level
access control and authorization requirements.
On the other hand, it seems to be possible to create
zero-conf security for certain signalling tasks, such
as mobility and maybe ND. BTW, MIPv6 CGA is not the
best example of zero-conf mobility security, HIP is
a much better one.
--Pekka
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
