Hi Miika, I don't think we're at a stage where it is feasible to retrofit support for future extensions in the base HIP specifications.
As to the group key pair, it isn't shared on the server. The anycast group controller holds the key pair, and uses it to derive the group anycast HIT, and issue authorization certificates to group members who own their own individual key pairs. SPKI authorization certificates can be used for this purpose. --julien On Sat, Mar 30, 2013 at 12:57 PM, Miika Komu <[email protected]> wrote: > Hi Julien, > > I'll have to the check the reference in more detail. Surely, shared private > keys at the server side are certainly one possibility, but the compromise of > a single host would then compromise the entire group? > > I was originally thinking that the IP address of rendezvous server would > identify the group, but admit this can be somewhat limiting. For instance, > an additional parameter in the I1 could identify the group. Clearly, > multicast is outside of the scope of this WG, but I was considering if the > specifications are future proof with such an approach since now the > opportunistic base exchange is always terminated at the rendezvous server. > > P.S. I'll automatically assume this discussion shouldn't affect the specs at > all if this topic doesn't gather too much discussion (and it's quite a late > in process, anyway). > > > On 03/29/2013 01:36 AM, Julien Laganier wrote: >> >> Hi, >> >> HIP anycast would need a HIT to identify the members of the anycast >> group, wouldn't it? >> >> So why not have a key pair generated for the group, and the HIT >> derived from the public key be the anycast HIT. One could then use the >> group anycast key pair to sign authorization certificates granting >> membership into the group. Similar concept has been explored for IPv6 >> multicast and anycast group in: >> >> CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in >> ipv6 with cryptographically >> generated addresses. In The Eighth IEEE Symposium on Computers and >> Communications >> (ISCC’2003). >> >> --julien >> >> >> On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu <[email protected]> wrote: >>> >>> Hi, >>> >>> opportunistic mode with the help of a rendezvous server could be used for >>> implementing HIP-based anycast. The current RVS specification does not >>> allow >>> this: >>> >>> http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 >>> >>> 4.3.1. Processing Outgoing I1 Packets >>> >>> An initiator SHOULD NOT send an opportunistic I1 with a NULL >>> destination HIT to an IP address that is known to be a rendezvous >>> server address, unless it wants to establish a HIP association with >>> the rendezvous server itself and does not know its HIT. >>> >>> I think we could specify either a flag in the base exchange or >>> alternatively >>> a special HIT encoding for the "NULL" destination HIT in the I1. What do >>> you >>> think? >>> _______________________________________________ >>> Hipsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
