Ok Julien, no actions needed then. Thanks! On 01/04/13 04:17, Julien Laganier wrote: > 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
