Subject: [MSEC] Comments to draft-castelluccia-sgmv6-00.txt

From: Pekka Nikander <[email-masked]>
Date: Tue, 04 Dec 2001 17:00:25 +0200

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

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 07 Dec 2001 13:46:58 -0800

I can't find this draft on Internet Drafts.

thanks, Mark