Thanks for your comments. My reply inline.
On 10/23/06, Christian Vogt <chvogt at tm.uka.de> wrote:
Hi Zhen,
I read your draft [1]. You are proposing a combined technique for
address ownership verification and trust management by integrating CGAs
and identity-based cryptosystems. This is interesting, though I have
the three comments/questions further below.
[1] draft-cao-mipshop-ibc-cga-00.txt
For those folks who did not read your draft, here is a brief summary of
your proposal: A node X obtains from a KDC an IBC ID plus a
public/private key pair that is bound to this IBC ID. The node then
generates a CGA from the IBC ID (rather than from the public key, which
is how it is done in RFC 3972). A CGA verifier Y recomputes the CGA,
again based on the IBC ID rather than on the public key, and it verifies
that node X really owns the CGA by verifying a signature supplied by
node X. Y then proceeds to establish a trust relationship with X in
that it inquires at the KDC whether the public key, based on which the
CGA signature was verified, has really been bound to X's IBC ID.
Thanks for your brief summary. But note as well: the public/private key pair is computed from the IBC ID that the node registers on KDC, and the CGA is generated from the public key (same as RFC 3972), in which way we can say the CGA is generated from IBC ID
Three comments/questions:
- Regarding the use of CGAs: In your approach, the KDC gives node X an
IBC ID which is different than an IP address, and node X then goes ahead
and generates a CGA from this IBC ID. But it seems that it would be
more straightforward to just have the KDC directly assign an IP address
(as the IBC ID) to the node, i.e., IBC ID == IP address. In that case,
node Y could inquire at the KBC whether node X's IP address is bound to
the public key based on which node X's signature was verified. If this
is so, then node Y knows that (i) node X really owns the claimed IP
address, and that (ii) it can trust node X based on the knowledge that
the KDC has given node X the right public/private key pair. You don't
need CGAs if you use an identity-based cryptosystem anyway.
If IP address is used as the IBC ID, the node should re-register its ID on the KDC when it has changed its IP address, resulting in changes in the private/public key pair. The IBC ID is a permanent identity which is required by the IBC scheme, so that is not applicable to use the IP address as the IBC ID.
- Regarding the trust relationship between nodes X and Y: For which
purpose do you need this trust relationship? IMO, "trust" is very
application-dependent. E.g., in Mobile IPv6, there is an assumption
that a home agent can trust its mobile nodes that they do not spoof
care-of addresses. But such trust relationship may not be sufficient
for the home agent to let the mobile nodes do other, more critical
things. E.g., if the home agent is responsible for accounting, it would
still collect the accounting information itself rather than asking the
mobile nodes in retrospective how much they did communicate and do the
accounting based on the mobile nodes' reporting. In this respect, it is
also important to consider that the mobile nodes may get compromised, so
they may not be trustworthy even if they get the necessary credentials
from the KDC. I think your draft is missing a statement on the purpose
of the trust that you establish.
Considering the attacker can auto configure a private/public key pair and generates a CGA address, hence cheating CGA verifier to accept it as an valid entity, the trust relationship can be of help. It is the trust relationship's purpose to avoid this kind of attacks somewhat. Yes, as far as compromising problem, IMO, (a) it is still not easy to compromise the mobile node or the private/public key pair. (b) the IBC scheme serves recovery service that the compromised entities can report their compromised ID.
- Regarding mobility: Since you designed your proposed technique for a
Mobile IPv6 environment, but you did not design it for open-ended
deployment, why not avoid route optimization and thereby make mobility
transparent to correspondent nodes? You could use Hierarchical Mobile
IPv6, NETLMM, or tunnel all traffic of mobile nodes through their
standard (local) home agent. In all cases, the mobile node's IP address
does not change from the CN's perspective, so there is no
mobility-related requirement for IP address ownership verification and
CGAs. You could then use a standard identity-based cryptosystem for
establishing trust relationships between mobile and correspondent nodes.
Thanks for your advice. We will put more emphasis on those questions.
Best regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
CAO, ZHEN wrote:
> Hi everybody,
>
> CGA was proposed in RFC3972, and it was originally used in SEND related
> protocols. Recently it has witnessed the proliferation of taking
> advantages of CGA in many protocols such as
> [draft-ietf-mipshop-cga-cba-00.txt ] and
> [draft-haddad-mipshop-hmipv6-security-06.txt
]. But unfortunately, CGA
> was originally designed for SEND related protocols, which means we
> should give more considerations than the original CGA if we apply it in
> other protocols.
>
> Actually it has already been suggested in section
7.4 of RFC3972:
>
> <snip>
>
> Finally, a strong cautionary note has to be made about using CGA
> signatures for purposes other than SEND. First, the other protocols
> MUST include a type tag and the sender address in all signed messages
> in the same way that SEND does. Each protocol MUST define its own
> type tag values as explained in Section 8. Moreover, because of the
> possibility of related-protocol attacks, the public key MUST be used
> only for signing, and it MUST NOT be used for encryption. Second,
> the minimum RSA key length of 384 bits may be too short for many
> applications and the impact of key compromise on the particular
> protocol must be evaluated. Third, CGA-based authorization is
> particularly suitable for securing neighbor discovery [RFC2461] and
> duplicate address detection [RFC2462] because these are network-layer
> signaling protocols for which IPv6 addresses are natural endpoint
> identifiers. In any protocol that uses other identifiers, such as
> DNS names, CGA signatures alone are not a sufficient security
> mechanism. There must also be a secure way of mapping the other
> identifiers to IPv6 addresses. If the goal is not to verify claims
> about IPv6 addresses, CGA signatures are probably not the right
> solution.
>
> <snip>
>
>
>
> I do not think all the drafts meet the requirements above well. [
> draft-haddad-mipshop-hmipv6-security-06.txt] does not include a type tag
> and makes use of the public key to distribute a shared key between MN
> and MAP; [draft-ietf-mipshop-cga-cba-00.txt] does not give any
> consideration on the justification of using this short RSA key. As a
> result, I suggest that the draft using CGA for authentication or
> authorization add a subsection in the Security Consideration section to
> address the problems mentioned above.
>
> What's more, by signing a message with the private key, the address
> owner can assert (a) that somebody owns this address and (b) that the
> message was sent by the address owner. But it cannot assert whether the
> address owner is a trusted entity. An attack can auto-configure a RSA
> public-private key pair and then configure a CGA ipv6 address, cheating
> the receiver to trust him. If the keys are generated and distributed by
> a trusted entity in the network, this problem can be avoided.
> Identity-based Cryptosystem (IBC) does the very thing for private/public
> keys generation binding with an IBC-ID, and it does not introduce a long
> chain of certificates as PKI does. The CGA address is computed with the
> public key of IBC system, so by signing a message with private key, the
> address owner can assert three points: (a)that somebody owns this
> address and (b) that the message was sent by the address owner, and (c)
> the address owner is a trusted entity. This is what we have suggested in
> [ draft-cao-mipshop-ibc-cga-00.txt] and it sounds better than what the
> CGA has guaranteed.
>
>
> Thanks,
> Zhen
