Claude, [I am not a member in msec or smug, and therefore I don't know if this point has been taken up there already. It may even be that my message is rejected from those list due to my non-membership status.]
I find the idea presented in the draft very refreshing and beautiful. The fact that multicast group IDs are 112 bits (instead of 64 bits) makes it work even better than for basic SUCV/CAM. On the other hand, since I am no expert in multicast and have only a very bad understanding on how you create new multicast groups in the first place, I cannot comment that side. Anyway, in Section 5.3 you write: > 2. The private key, the public key, the counter and the GroupID > are distributed to the (authorized) group members. Note that > private key requires confidentiality because it only has to > be known to the authorized group members. The public key, > the counter and the GroupID can be sent in clear but require > integrity. Now, I was left wondering why to send the private key itself? If we assume that all the hosts in the multicast group have their own public/private key pair (e.g. for basic SUCV or in order to authenticate them for some other reason), wouldn't it be easier just to delegate the right to join the multicast group? That is, instead of sending the private key, you would send an SPKI or KeyNote2 certificate stating that the public key of the host is authorized to join the multicast group represented by the group key? Delegation would make key distribution easier. Instead of sending the private key in a secure channel you just distribute the certificate. You don't even need to authenticate the member host if you know its public key beforehand. The certificate could take care of the integrity of the group public key, the counter and the GroupID, i.e. it would basically be a self-signed certificate. Furthermore, the delegation model would have additional benefits, i.e. it would allow better control of membership. If you add validity time to the certificate, you could control how long the hosts are members of the group. Secondly, if you distribute the private key, any host in the group can leak the private key, and you don't know who it was. In the delegation model, if a host leaks its own private key, you definitely know who it was, and you don't renew that host's certificate when it expires. (I assume, here, of course that the certificates would have relatively short lifetime, e.g. in the order of minutes or hours.) The delegation approach would also help with the replay attack problem (Section 6.3), since it would effectively limit the validity of the reports with the validity of the certificate. I am not so sure about the anycast case, though. My understanding about anycast is that in anycast you want all anycast hosts to behave equally. Therefore they should look the same, and distributing the private key might actually be a good idea. --Pekka Nikander -------------------------------------------------------------------- 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] --------------------------------------------------------------------
